Sistem Durumu Uç Nokta İzleme düzeni

Uygulamaların ve hizmetlerin doğru performans sergilediğini doğrulamak için Sistem Durumu Uç Noktası İzleme desenini kullanabilirsiniz. Bu düzen, bir uygulamada işlevsel denetimlerin kullanımını belirtir. Dış araçlar, kullanıma sunulan uç noktalar aracılığıyla düzenli aralıklarla bu denetimlere erişebilir.

Bağlam ve sorun

Web uygulamalarını ve arka uç hizmetlerini izlemek iyi bir uygulamadır. İzleme, uygulamaların ve hizmetlerin kullanılabilir ve doğru performans göstermesini sağlamaya yardımcı olur. İş gereksinimleri genellikle izlemeyi içerir.

Bulut hizmetlerini izlemek bazen şirket içi hizmetlerden daha zordur. Bunun bir nedeni, barındırma ortamı için tam denetime sahip olmamanızdır. Bir diğeri, hizmetlerin genellikle platform satıcılarının ve diğerlerinin sağladığı diğer hizmetlere bağlı olmasıdır.

Bulutta barındırılan uygulamaları etkileyen birçok faktör vardır. Örnek olarak ağ gecikme süresi, temel alınan işlem ve depolama sistemlerinin performansı ve kullanılabilirliği ile bunlar arasındaki ağ bant genişliği verilebilir. Bu faktörlerden herhangi biri nedeniyle bir hizmet tamamen veya kısmen başarısız olabilir. Gerekli kullanılabilirlik düzeyini sağlamak için, düzenli aralıklarla hizmetinizin doğru performans sergilediğini doğrulamanız gerekir. Hizmet düzeyi sözleşmeniz (SLA) karşılamanız gereken düzeyi belirtebilir.

Çözüm

Uygulamanızdaki bir uç noktaya istek göndererek sistem durumu izlemeyi uygulayın. Uygulamanın gerekli denetimleri gerçekleştirmesi ve ardından durumunun bir göstergesini döndürmesi gerekir.

Sistem durumu izleme denetimi genellikle iki faktörü bir araya getirir:

• Uygulamanın veya hizmetin sistem durumu doğrulama uç noktasına yönelik isteğe yanıt olarak gerçekleştirdiği denetimler (varsa)
• Sistem durumu doğrulama denetimini gerçekleştiren araç veya çerçeve tarafından sonuçların analizi

Yanıt kodu, uygulamanın durumunu gösterir. İsteğe bağlı olarak, yanıt kodu uygulamanın kullandığı bileşenlerin ve hizmetlerin durumunu da sağlar. İzleme aracı veya çerçevesi gecikme süresi veya yanıt süresi denetimini gerçekleştirir.

Aşağıdaki şekilde desene genel bir bakış sağlanır.

Uygulamadaki sistem durumu izleme kodu, aşağıdakileri belirlemek için başka denetimler de çalıştırabilir:

• Bulut depolama veya veritabanının kullanılabilirlik ve yanıt süresi.
• Uygulamanın kullandığı diğer kaynakların veya hizmetlerin durumu. Bu kaynaklar ve hizmetler uygulamada veya uygulamanın dışında olabilir.

Yapılandırılabilir bir uç nokta kümesine istek göndererek web uygulamalarını izleyen hizmetler ve araçlar kullanılabilir. Bu hizmetler ve araçlar daha sonra sonuçları yapılandırılabilir kurallar kümesine göre değerlendirir. Yalnızca bir sistemde bazı işlevsel testler gerçekleştirmek amacıyla bir hizmet uç noktası oluşturmak oldukça kolaydır.

İzleme araçlarının gerçekleştirdiği tipik denetimler şunlardır:

• Yanıt kodunu doğrulama. Örneğin, bir HTTP yanıtının 200 (Tamam) olması uygulamanın hatasız yanıt verdiğini belirtir. İzleme sistemi, daha kapsamlı sonuçlar vermek için diğer yanıt kodlarını da denetleyebilir.
• Durum kodu 200 (Tamam) olduğunda bile hataları algılamak için yanıtın içeriğini denetleme. İçeriği denetleyerek, döndürülen web sayfasının veya hizmet yanıtının yalnızca bir bölümünü etkileyen hataları algılayabilirsiniz. Örneğin, bir sayfanın başlığını denetleyebilir veya uygulamanın doğru sayfayı döndürdüğünü belirten belirli bir tümceciği arayabilirsiniz.
• Yanıt süresini ölçme. Değeri, ağ gecikme süresini ve uygulamanın isteğin verilmesi için geçen süreyi içerir. Artan bir değer, uygulama veya ağda ortaya çıkacak bir sorunu gösterebilir.
• Uygulamanın dışında bulunan kaynakları veya hizmetleri denetleme. Örneğin, uygulamanın genel önbelleklerden içerik teslim etmek için kullandığı bir içerik teslim ağıdır.
• TLS sertifikalarının süre sonu denetleniyor.
• Uygulamanın URL'si için DNS aramasının yanıt süresini ölçme. Bu denetim, DNS gecikme süresini ve DNS hatalarını ölçer.
• DNS aramasının döndürdüğü URL'yi doğrulama. Doğrulayarak, girdilerin doğru olduğundan emin olabilirsiniz. Ayrıca, DNS sunucunuzda bir saldırıdan sonra ortaya çıkan kötü amaçlı istek yeniden yönlendirmesini önlemeye de yardımcı olabilirsiniz.

Mümkün olduğunda, bu denetimleri farklı şirket içi veya barındırılan konumlardan çalıştırmak ve ardından yanıt sürelerini karşılaştırmak da yararlıdır. İdeal olarak, uygulamaları müşterilere yakın konumlardan izlemeniz gerekir. Ardından her konumdan performansın doğru bir görünümünü elde edersiniz. Bu uygulama daha sağlam bir denetim mekanizması sağlar. Sonuçlar aşağıdaki kararları vermenize de yardımcı olabilir:

• Uygulamanızın dağıtılacağı yer
• Birden fazla veri merkezinde dağıtılıp dağıtılmayacağı

Uygulamanızın tüm müşteriler için düzgün çalıştığından emin olmak için, müşterilerin kullandığı tüm hizmet örneklerinde testler çalıştırın. Örneğin, müşteri depolama alanı birden fazla depolama hesabına yayılmışsa izleme işlemi her hesabı denetlemelidir.

Sorunlar ve dikkat edilmesi gerekenler

Bu deseni nasıl uygulayabileceğinize karar vermek için aşağıdaki noktaları göz önünde bulundurun:

• Yanıtı doğrulamayı düşünün. Örneğin, uygulamanın düzgün çalıştığını doğrulamak için 200 (Tamam) durum kodunun yeterli olup olmadığını belirleyin. Durum kodunu denetlemek, bu düzenin en düşük uygulamasıdır. Durum kodu, uygulama kullanılabilirliğine yönelik temel bir ölçü sağlar. Ancak kod, uygulamadaki işlemler, eğilimler ve olası yaklaşan sorunlar hakkında çok az bilgi sağlar.

• Bir uygulama için kullanıma sunma uç noktası sayısını belirleyin. Bir yaklaşım, uygulamanın kullandığı temel hizmetler için en az bir uç nokta, düşük öncelikli hizmetler için de başka bir uç nokta göstermektir. Bu yaklaşımla, her izleme sonucuna farklı önem düzeyleri atayabilirsiniz. Ayrıca ek uç noktaları da ortaya çıkarmanız gerekir. İzleme ayrıntı düzeyini artırmak için her çekirdek hizmet için bir tane kullanıma sağlayabilirsiniz. Örneğin, sistem durumu doğrulama denetimi veritabanını, depolama alanını ve bir uygulamanın kullandığı bir dış coğrafi kodlama hizmetini denetleyebilir. Her biri farklı bir çalışma süresi ve yanıt süresi düzeyi gerektirebilir. Coğrafi kodlama hizmeti veya başka bir arka plan görevi birkaç dakika boyunca kullanılamayabilir. Ancak uygulama yine de iyi durumda olabilir.

• İzleme ve genel erişim için aynı uç noktayı kullanıp kullanmayacağınız konusunda karar verin. Her ikisi için de aynı uç noktayı kullanabilirsiniz, ancak sistem durumu doğrulama denetimleri için belirli bir yol tasarlayabilirsiniz. Örneğin, genel erişim uç noktasında /health kullanabilirsiniz. Bu yaklaşımla izleme araçları uygulamada bazı işlevsel testler çalıştırabilir. Örnek olarak yeni kullanıcı kaydetme, oturum açma ve test siparişi verme verilebilir. Aynı zamanda, genel erişim uç noktasının kullanılabilir olduğunu da doğrulayabilirsiniz.

• İzleme isteklerine yanıt olarak hizmette toplayacak bilgi türünü belirleyin. Ayrıca bu bilgilerin nasıl döndürüleceğini de belirlemeniz gerekir. Pek çok mevcut araç ve çerçeve, yalnızca uç noktanın döndürdüğü HTTP durum koduna bakar. Dönüp ek bilgileri doğrulamak için bir özel izleme yardımcı programı veya hizmeti oluşturmanız gerekebilir.

• Ne kadar bilgi toplayacağınız hakkında bilgi edinme. Denetim sırasında aşırı işlem gerçekleştirmek uygulamayı aşırı yükleyip diğer kullanıcıları etkileyebilir. İşlem süresi, izleme sisteminin zaman aşımını da aşabilir. Sonuç olarak, sistem uygulamayı kullanılamıyor olarak işaretleyebilir. Uygulamaların çoğu hata işleyicileri ve performans sayaçları gibi izlemeler içerir. Bu araçlar performansı ve ayrıntılı hata bilgilerini günlüğe kaydedebilir ve bu da yeterli olabilir. Sistem durumu doğrulama denetiminden ek bilgi döndürmek yerine bu verileri kullanmayı göz önünde bulundurun.

• Uç nokta durumunu önbelleğe almayı göz önünde bulundurun. Sistem durumu denetimini sık sık çalıştırmak pahalı olabilir. Örneğin, sistem durumu bir pano aracılığıyla bildirilirse, panoya yapılan her isteğin sistem durumu denetimini tetiklemesini istemezsiniz. Bunun yerine, sistem durumunu düzenli aralıklarla denetleyin ve durumu önbelleğe alın. Önbelleğe alınan durumu döndüren bir uç noktayı kullanıma sunma.

• İzleme uç noktaları için güvenliği yapılandırmayı planlayın. Güvenliği yapılandırarak uç noktaların genel erişimden korunmasına yardımcı olabilirsiniz; bu da şunları yapabilir:

  • Uygulamayı kötü amaçlı saldırılara maruz bırakma.
  • Hassas bilgilerin açığa çıkmasına neden olma riski.
  • Hizmet reddi (DoS) saldırılarını çekme.

  Genellikle, uygulama yapılandırmasında güvenliği yapılandırabilirsiniz. Ardından uygulamayı yeniden başlatmadan ayarları kolayca güncelleştirebilirsiniz. Aşağıdaki tekniklerden bir veya daha fazlasını kullanmayı düşünebilirsiniz:

  • Kimlik doğrulaması gerektirerek uç noktanın güvenliğini sağlama. İzleme hizmeti veya aracı kimlik doğrulamasını destekliyorsa, istek üst bilgisinde bir kimlik doğrulama güvenlik anahtarı kullanabilirsiniz. Kimlik bilgilerini istekle birlikte de geçirebilirsiniz. Kimlik doğrulamasını kullanırken sistem durumu denetimi uç noktalarınıza nasıl eriştiğinizi göz önünde bulundurun. Örneğin, Azure Uygulaması Hizmeti'nin App Service kimlik doğrulaması ve yetkilendirme özellikleriyle tümleşen yerleşik bir sistem durumu denetimi vardır.

  • Belirsiz veya gizli bir uç noktası kullanma. Örneğin, uç noktayı varsayılan uygulama URL'sinin kullandığı ip adresinden farklı bir IP adresinde kullanıma sunun. Uç noktayı standart olmayan bir HTTP bağlantı noktasında yapılandırın. Ayrıca, test sayfanıza karmaşık bir yol kullanmayı da göz önünde bulundurun. Uygulama yapılandırmasında genellikle ek uç nokta adresleri ve bağlantı noktaları belirtebilirsiniz. Gerekirse, DNS sunucusuna bu uç noktalar için girdiler ekleyebilirsiniz. Ardından IP adresini doğrudan belirtmek zorunda kalmamak gerekir.

  • Bir anahtar değeri veya bir işlem modu değeri gibi bir parametre kabul eden bir uç noktada bir yöntem kullanıma sunma. bir istek geldiğinde, kod parametrenin değerine bağlı olan belirli testleri çalıştırabilir. Kod, parametre değerini tanımıyorsa 404 (Bulunamadı) hatası döndürebilir. Uygulama yapılandırmasında parametre değerlerini tanımlamayı mümkün hale getirin.

  • Uygulamanın işleminden ödün vermeden temel işlevsel testler gerçekleştiren ayrı bir uç nokta kullanın. Bu yaklaşımla DoS saldırısının etkisini azaltmaya yardımcı olabilirsiniz. İdeal olarak, hassas bilgilerin açığa çıkmasına neden olabilecek bir test kullanmaktan kaçının. Bazen bir saldırgan için yararlı olabilecek bilgileri döndürmeniz gerekir. Bu durumda uç noktayı ve verileri yetkisiz erişime karşı korumayı göz önünde bulundurun. Belirsizliğe güvenmek yeterli değildir. Bu yaklaşım sunucudaki yükü artırsa da, https bağlantısı kullanmayı ve hassas verileri şifrelemeyi de göz önünde bulundurun.

• İzleme aracısının doğru şekilde çalıştığından nasıl emin oluneceğine karar verin. Yaklaşımlardan biri, uygulama yapılandırmasından bir değer döndüren bir uç noktayı veya aracıyı test etmek için kullanabileceğiniz rastgele bir değeri kullanıma sunmadır. Ayrıca izleme sisteminin kendi üzerinde denetimler gerçekleştirdiğinden emin olun. İzleme sisteminin hatalı pozitif sonuçlar vermesini önlemek için kendi kendine test veya yerleşik test kullanabilirsiniz.

Bu düzenin kullanılacağı durumlar

Bu düzen aşağıdakiler için kullanışlıdır:

• Kullanılabilirliğini doğrulamak için web sitelerini ve web uygulamalarını izleme.
• Doğru işlediklerinden emin olmak için web sitelerini ve web uygulamalarını izleme.
• Diğer uygulamaları kesintiye uğratabilecek hataları algılamak ve yalıtmak için orta katman veya paylaşılan hizmetleri izleme.
• Uygulamada, performans sayaçları ve hata işleyicileri gibi mevcut araçların eksiklerini tamamlama. Sistem durumu doğrulama denetimi, günlüğe kaydetme ve denetim için uygulama gereksinimlerini değiştirmez. İzleme, hatalar ve diğer sorunları algılama amacıyla sayaçları ve hata günlüklerini izleyen mevcut bir çerçeve için değerli bilgiler sağlayabilir. Ancak bir uygulama kullanılamıyorsa izleme bilgileri sağlayamaz.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için iş yükünün tasarımında Sistem Durumu Uç Noktası İzleme düzeninin nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.

Örnek

Uygulama altyapısı bileşenlerinin sistem durumunu raporlamak için ASP.NET sistem durumu denetimleri ara yazılımını ve kitaplıkları kullanabilirsiniz. Bu çerçeve, sistem durumu denetimlerini tutarlı bir şekilde raporlamak için bir yol sağlar. Bu makalede açıklanan uygulamaların birçoğu uygulanır. Örneğin, ASP.NET sistem durumu denetimleri veritabanı bağlantısı gibi dış denetimleri ve canlılık ve hazırlık yoklamaları gibi belirli kavramları içerir.

ASP.NET sistem durumu denetimlerini kullanan çeşitli örnek uygulamalar GitHub'da kullanılabilir.

Azure tarafından barındırılan uygulamalarda uç noktaları izleme

Azure uygulamalarında uç noktaları izleme seçenekleri şunlardır:

• Azure İzleyici gibi Azure'ın yerleşik izleme özelliklerini kullanın.
• Üçüncü taraf bir hizmet veya Microsoft System Center Operations Manager gibi bir çerçeve kullanın.
• Kendi sunucunuzda veya barındırılan bir sunucuda çalışan özel bir yardımcı program veya hizmet oluşturun.

Azure kapsamlı izleme seçenekleri sağlasa da ek bilgi sağlamak için ek hizmetleri ve araçları kullanabilirsiniz. İzleyici'nin bir özelliği olan Uygulama Analizler, geliştirme ekipleri için tasarlanmıştır. Bu özellik, uygulamanızın performansını ve nasıl kullanıldığını anlamanıza yardımcı olur. Uygulama Analizler istek oranlarını, yanıt sürelerini, hata oranlarını ve bağımlılık oranlarını izler. Dış hizmetlerin sizi yavaşlatıp yavaşlatmadığını belirlemenize yardımcı olabilir.

İzleyebileceğiniz koşullar, uygulamanız için seçtiğiniz barındırma mekanizmasına bağlıdır. Bu bölümdeki tüm seçenekler uyarı kurallarını destekler. Uyarı kuralı, hizmetinizin ayarlarında belirttiğiniz bir web uç noktasını kullanır. Uyarı sisteminin uygulamanın düzgün çalıştığını algılayabilmesi için bu uç noktanın zamanında yanıt vermesi gerekir. Daha fazla bilgi için bkz . Yeni uyarı kuralı oluşturma.

Büyük bir kesinti varsa, istemci trafiği diğer bölgelerde veya bölgelerde kullanılabilen bir uygulama dağıtımına yönlendirilebilir olmalıdır. Bu durum, şirket içi bağlantılar ve genel yük dengeleme için iyi bir durumdur. Seçim, uygulamanın iç mi yoksa dış mı olduğuna bağlıdır. Azure Front Door, Azure Traffic Manager veya içerik teslim ağları gibi hizmetler, sistem durumu yoklamalarının sağladığı verilere göre trafiği bölgeler arasında yönlendirebilir.

Traffic Manager bir yönlendirme ve yük dengeleme hizmetidir. İstekleri uygulamanızın belirli örneklerine dağıtmak için bir dizi kural ve ayar kullanabilir. Traffic Manager, yönlendirme isteklerinin yanı sıra bir URL, bağlantı noktası ve göreli yola düzenli olarak ping gönderebilir. Ping hedeflerini, uygulamanızın hangi örneklerinin etkin olduğunu ve isteklere yanıt verdiğini belirleme hedefiyle belirtirsiniz. Traffic Manager 200 (Tamam) durum kodu algılarsa, uygulamayı kullanılabilir olarak işaretler. Diğer durum kodları Traffic Manager’ın uygulamayı çevrimdışı olarak işaretlemesine neden olur. Traffic Manager konsolu her uygulamanın durumunu görüntüler. Her kuralı, istekleri yanıtlayan diğer uygulama örneklerine yeniden yönlendirecek şekilde yapılandırabilirsiniz.

Traffic Manager, izleme URL'sinden yanıt almak için belirli bir süre bekler. Sistem durumu doğrulama kodunuzun bu süre içinde çalıştığından emin olun. Traffic Manager'dan uygulamanıza gidiş dönüş ve geri dönüş için ağ gecikmesine izin verin.

Sonraki adımlar

Aşağıdaki kılavuz, bu düzeni uygulamak için yararlıdır:

• Mikro hizmet tabanlı uygulamalarda sistem durumu izleme kılavuzu
• Azure İyi Tasarlanmış Çerçeve'nin bir parçası olan güvenilirlik için uygulama durumunu izleme
• Yeni uyarı kuralı oluşturma

İlgili kaynaklar

• Dış Yapılandırma Deposu düzeni
• Devre Kesici düzeni
• Ağ Geçidi Yönlendirme düzeni
• Ağ Geçidi Denetleyicisi düzeni