Gözlemlenebilirlik desenleri

Tavsiye

Bu içerik, .NET Docs veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Azure için Bulut Yerel .NET Uygulamaları Tasarlama adlı e-Kitap'tan bir alıntıdır.

PDF'i indirin

Azure eKitap kapak küçük resmi için Buluta Özel .NET uygulamaları.

Uygulamalarda kod düzenine yardımcı olacak desenler geliştirildiği gibi, uygulamaların güvenilir bir şekilde çalıştırılmasına yönelik desenler de vardır. Uygulamaların bakımını yapma konusunda üç yararlı desen ortaya çıktı: günlüğe kaydetme, izleme ve uyarılar.

Günlük kaydı ne zaman kullanılmalı?

Ne kadar dikkatli olursak olun, uygulamalar neredeyse her zaman üretimde beklenmedik şekilde davranır. Kullanıcılar bir uygulamayla ilgili sorunlar bildirdiğinde, sorun oluştuğunda uygulamada neler olduğunu görebilmek yararlı olur. Bir uygulamanın çalışırken ne yaptığı hakkında bilgi yakalamanın en çok denenen ve gerçek yollarından biri, uygulamanın ne yaptığını yazmasını sağlamaktır. Bu işlem kayıt tutma olarak bilinir. Üretim ortamında her hata veya sorun oluştuğunda hedef, hataların oluştuğu koşulları üretim dışı bir ortamda yeniden oluşturmak olmalıdır. İyi bir kayıt tutma özelliği, geliştiricilerin test edilebilen ve denenebilen bir ortamdaki sorunları tekrar oluşturmak için izlemesi gereken bir yol haritası sağlar.

Bulutta yerel uygulamalarla günlük tutma zorlukları

Geleneksel uygulamalarda günlük dosyaları genellikle yerel makinede depolanır. Aslında, Unix benzeri işletim sistemlerinde genellikle /var/log altında herhangi bir günlük kaydı tutmak için tanımlanmış bir klasör yapısı vardır.

Şekil 7-1. Monolitik bir uygulamada bir dosyaya oturum açma.

Tek bir makinedeki düz bir dosyaya günlüğe kaydetmenin kullanışlılığı, bulut ortamında büyük ölçüde azalır. Günlükleri üreten uygulamaların yerel diske erişimi olmayabilir veya kapsayıcılar fiziksel makinelerin çevresinde karıştırıldığından yerel disk son derece geçici olabilir. Monolitik uygulamaların çoklu düğümde basit bir şekilde ölçeklenmesi bile doğru dosya tabanlı günlük dosyasını bulmayı zorlaştırabilir.

Şekil 7-2. Ölçeklendirilmiş bir monolitik uygulamada dosyalara günlük kaydı.

Mikro hizmet mimarisi kullanılarak geliştirilen buluta özel uygulamalar da dosya tabanlı günlükçüler için bazı zorluklar doğurmaktadır. Kullanıcı istekleri artık farklı makinelerde çalışan birden çok hizmete yayılabilir ve yerel dosya sistemine hiç erişimi olmayan sunucusuz işlevler içerebilir. Bu kadar çok hizmet ve makine arasında bir kullanıcıdan veya oturumdan gelen günlükleri ilişkilendirmek çok zor olabilir.

Şekil 7-3. Mikro hizmetler uygulamasında yerel dosyalarda günlüğe kaydetme.

Son olarak, bazı buluta özel uygulamalarda kullanıcı sayısı yüksektir. Her kullanıcının bir uygulamada oturum açtığında yüz satır günlük iletisi oluşturduğunu düşünün. Tek başına düşünüldüğünde bu yönetilebilir, ancak 100.000 kullanıcı üzerinde çoğaltıldığında, günlüklerin hacmi, günlüklerin etkili kullanımını desteklemek için özel araçlara ihtiyaç duyulacak kadar büyük hale gelir.

Bulutta yerel uygulamalarda günlüğe kaydetme

Her programlama dilinin günlükleri yazmaya izin veren araçları vardır ve genellikle bu günlükleri yazmanın yükü düşüktür. Günlükleme kütüphanelerinin çoğu, çalışma sırasında ayarlanabilen farklı kritiklik seviyelerinde günlükleme yapmayı sağlar. Örneğin, .NET için popüler bir yapılandırılmış günlükleme kitaplığı olan Serilog kitaplığı, aşağıdaki loglama seviyelerini sunar:

• Ağır dilli
• Hata ayıklama
• Bilgi
• Uyarı
• Hata
• Ölümcül

Bu farklı günlük düzeyleri, günlük kaydında ayrıntılı bilgi sağlar. Uygulama üretimde düzgün çalıştığında, yalnızca önemli iletileri günlüğe kaydedecek şekilde yapılandırılabilir. Uygulama hatalı çalıştığında, daha ayrıntılı günlüklerin elde edilmesi için günlük seviyesi artırılabilir. Bu, performansı hata ayıklama kolaylığına karşı dengeler.

Günlüğe kaydetme araçlarının yüksek performansı ve detay ayarlanabilirliği, geliştiricileri sık sık günlüğe kaydetmeye teşvik etmelidir. Çoğu, her yöntemin giriş ve çıkışını günlüğe kaydetme desenini destekler. Bu yaklaşım fazlalık gibi görünebilir, ancak geliştiricilerin daha az günlük kaydı istemesi seyrek görülen bir yaklaşımdır. Aslında, yalnızca sorunlu bir yöntemin etrafına günlük kaydı eklemek amacıyla dağıtımlar gerçekleştirmek yaygın bir durumdur. Yanlışlıkla çok az değil, çok fazla günlüğe kaydetme tarafında olun. Bazı araçlar bu tür günlükleri otomatik olarak sağlamak için kullanılabilir.

Buluta özel uygulamalarda dosya tabanlı günlükleri kullanmayla ilgili zorluklar nedeniyle merkezi günlükler tercih edilir. Günlükler uygulamalar tarafından toplanır ve günlükleri dizinleyen ve depolayan merkezi bir günlüğe kaydetme uygulamasına gönderilir. Bu sistem türü her gün onlarca gigabayt günlük işleyebilir.

Çünkü birçok hizmeti kapsayan günlük oluştururken bazı standart uygulamaları izlemek de faydalıdır. Örneğin, uzun bir etkileşimin başlangıcında bir korelasyon kimliği oluşturmak ve ardından bu etkileşimle ilgili her iletide bu kimliği günlüğe kaydetmek, tüm ilgili iletileri aramayı kolaylaştırır. Tek yapmanız gereken, sadece bir mesaj bulmak ve tüm ilgili mesajları bulmak için korelasyon kimliğini çıkarmaktır. Bir diğer örnek de günlük biçiminin kullandığı dil veya günlük kitaplığı ne olursa olsun her hizmet için aynı olmasını sağlamaktır. Bu standartlaştırma günlükleri okumayı çok daha kolay hale getirir. Şekil 7-4,mikro hizmet mimarisinin iş akışının bir parçası olarak merkezi günlük kaydından nasıl yararlanabileceğini göstermektedir.

Şekil 7-4. Çeşitli kaynaklardan gelen günlükler merkezi bir günlük deposuna aktarılır.

Olası uygulama sağlık sorunlarını tespit etme ve yanıtlamayla ilgili zorluklar

Bazı uygulamalar görev açısından kritik değildir. Belki yalnızca şirket içinde kullanılırlar ve bir sorun oluştuğunda kullanıcı sorumlu ekiple iletişim kurabilir ve uygulama yeniden başlatılabilir. Ancak müşterilerin genellikle tükettiği uygulamalardan beklentileri daha yüksektir. Kullanıcılardan önce veya kullanıcılar sizi bilgilendirmeden önce uygulamanızla ilgili sorunlar oluştuğunda bunu bilmeniz gerekir. Aksi takdirde, bir sorun hakkında ilk bilgiyi, uygulamanızı veya kuruluşunuzu aşağılayan sosyal medya gönderilerinin kızgın bir seliyle karşılaştığınızda öğrenebilirsiniz.

Göz önünde bulundurmanız gereken bazı senaryolar şunlardır:

• Uygulamanızdaki bir hizmet başarısız oluyor ve yeniden başlatılmaya devam ediyor ve bu da aralıklı yavaş yanıtlara neden oluyor.
• Günün bazı saatlerinde uygulamanızın yanıt süresi yavaştır.
• Yakın bir dağıtımdan sonra veritabanına yükleme üç katına çıktı.

Düzgün bir şekilde uygulanan izleme, sorunlara yol açacak koşullar hakkında sizi haberdar edebilir ve önemli bir kullanıcı etkisine yol açmadan önce temel koşulları ele almanıza olanak tanır.

Bulutta yerel uygulamaları izleme

Bazı merkezi günlüğe kaydetme sistemleri, salt günlüklerin dışında telemetri toplamak için ek bir rol üstleniyor. Veritabanı sorgusu çalıştırma süresi, bir web sunucusundan ortalama yanıt süresi ve hatta işletim sistemi tarafından bildirilen CPU yük ortalamaları ve bellek baskısı gibi ölçümleri toplayabilirler. Günlüklerle birlikte, bu sistemler sistemdeki düğümlerin ve uygulamanın bir bütün olarak sistem durumunun bütünsel bir görünümünü sağlayabilir.

İzleme araçlarının ölçüm toplama özellikleri, uygulamanın içinden el ile de beslenebilir. Özellikle ilgi çekici olan yeni kullanıcılara kaydolma veya siparişler gibi iş akışları, merkezi izleme sistemindeki bir sayacı artıracak şekilde ayarlanabilir. Bu özellik, izleme araçlarının yalnızca uygulamanın durumunu değil, işletmenin durumunu da izlemesini sağlar.

Sorgular, belirli istatistikleri veya kalıpları aramak ve daha sonra özel panolarda grafik biçiminde görüntülemek amacıyla log toplama araçlarında oluşturulabilir. Ekipler genellikle bir uygulamayla ilgili istatistikler aracılığıyla dönen, duvara monte edilmiş büyük ekranlara yatırım yapar. Bu şekilde, sorunları oluştukları anda görmek kolaydır.

Bulutta yerel izleme araçları, tek işlemli monolitik uygulamalar veya dağıtılmış mikro hizmet mimarileri olmasına bakılmaksızın uygulamalar hakkında gerçek zamanlı telemetri ve içgörü sağlar. Bunlar, uygulamadan veri toplamaya olanak sağlayan araçların yanı sıra uygulamanın durumuyla ilgili bilgileri sorgulamaya ve görüntülemeye yönelik araçlar içerir.

Buluta özel uygulamalarda kritik sorunlara tepki vermeyle ilgili zorluklar

Uygulamanızla ilgili sorunlara yanıt vermeniz gerekiyorsa, doğru personeli uyarmanın bir yolu olması gerekir. Bu, üçüncü bulut tabanlı uygulama gözlemlenebilirlik modelidir ve günlüğe kaydetme ve izlemeye dayanır. Sorunların tanılanması ve bazı durumlarda izleme araçlarına ilerlemesi için uygulamanızın oturum açması gerekir. Uygulama ölçümlerini ve sistem durumu verilerini tek bir yerde toplamak için izlenmesi gerekir. Bu oluşturulduktan sonra, belirli ölçümler kabul edilebilir düzeylerin dışına çıktığında uyarıları tetikleyecek kurallar oluşturulabilir.

Genellikle, belirli koşulların ekip üyelerine acil sorunları bildirmek için uygun uyarıları tetiklemesi için izleme üzerine uyarılar katmanlanır. Uyarı gerektirebilecek bazı senaryolar şunlardır:

• Uygulamanızın hizmetlerinden biri 1 dakikalık kapalı kalma süresinden sonra yanıt vermiyor.
• Uygulamanız 1%'den fazla isteğe başarısız HTTP yanıtları döndürmektedir.
• Uygulamanızın anahtar uç noktaları için ortalama yanıt süresi 2000 ms'yi aşıyor.

Bulutta yerel uygulamalarda uyarılar

Bilinen hata koşullarını aramak için izleme araçlarına yönelik sorgular oluşturabilirsiniz. Örneğin, sorgular gelen günlüklerde HTTP durum kodu 500'ün belirtisini arayabilir, bu da web sunucusunda bir sorun olduğunu gösterir. Bunlardan biri algılanır algılanmaz, kaynak hizmetin sahibine araştırmaya başlayabilen bir e-posta veya SMS gönderilebilir.

Ancak genellikle tek bir 500 hatası bir sorunun oluştuğuna karar vermek için yeterli değildir. Bu, kullanıcının parolasını yanlış yazdığını veya hatalı biçimlendirilmiş veriler girdiği anlamına gelebilir. Uyarı sorguları yalnızca ortalama 500'den fazla hata algılandığında tetiklenecek şekilde oluşturulabilir.

Uyarı vermedeki en zararlı modellerden biri, insanların araştırması için çok fazla sayıda uyarı tetiklemektir. Hizmet sahipleri, daha önce araştırdıkları ve zararsız buldukları hatalara karşı hızla duyarsızlaşır. Ardından, gerçek hatalar oluştuğunda yüzlerce hatalı pozitifin gürültüsünde kaybolurlar. Kurt Ağlayan Çocuk'un kıssası, çocuklara bu tehlike konusunda onları uyarmaları sık sık söylenmektedir. Verilen uyarıların gerçek bir sorunun göstergesi olduğundan emin olmak önemlidir.

ÖncekiSonraki