Uygulama Metrikleri: Kendi Sayaclarinizi Uretmek ve Izlemek

Uygulama Metrikleri: Kendi Sayaçlarınızı Üretmek ve İzlemek

Sunucunuzun işlemci ve bellek kullanımını görüyorsunuz. Ama kaç siparişin ödeme adımında takıldığını, hangi kuyruğun büyüdüğünü veya kaç kullanıcının hata aldığını göremiyorsunuz. Sistem metrikleri sağlığı ölçer, iş metrikleri anlamı ölçer.

Bu yazı, uygulama içinden metrik üretmeyi ele alıyor.

Sistem ve Uygulama Metrikleri

Üçüncü satır farkı en iyi gösterir: ödeme sağlayıcınız arızalandığında işlemci ve bellek tamamen normal görünür — sistem metrikleri hiçbir uyarı vermez ama başarısız ödeme oranı anında fırlar.

Bu tür arızalar yalnızca uygulama metrikleriyle görülür.

İkinci satır ise birikmeyi erken yakalar. Kuyruk uzunluğu artıyorsa, işleyici tarafında bir sorun var demektir.

Bu, kullanıcı şikayeti gelmeden fark edilir.

Metrik Türleri

• Sayaç yalnızca artar.
• Gösterge iner ve çıkar.
• Dağılım değer aralıklarını sayar.

Birinci madde en yaygın türdür ve doğru kullanımı önemlidir: sayaç asla sıfırlanmaz, sürekli artar — anlam kazanması için değeri değil, zaman içindeki artış hızı okunur.

Toplam istek sayısı tek başına bir şey söylemez.

Ama dakikada kaç arttığı, o anki yükü verir.

Üçüncü madde ise yanıt süreleri için vazgeçilmezdir; ortalamanın gizlediği yavaş istekleri ortaya çıkarır.

Ortalamanın Yalanı

1. Doksan istek 50 milisaniye sürer.
2. On istek 5 saniye sürer.
3. Ortalama 545 milisaniyedir.

Üçüncü satırdaki sayı hiçbir kullanıcının yaşadığı deneyimi tarif etmez: ortalama yanıt süresi, ne hızlı isteklerin ne de yavaş isteklerin gerçeğini gösterir — kimse 545 milisaniye beklememiştir ama rapor bunu söyler.

Yüzdelik dilimler bu sorunu çözer.

Yüzde doksan beşlik dilim, en yavaş yüzde beşin sınırını verir ve gerçek sorunu görünür kılar.

İzlemede ortalama yerine yüzdelik dilim kullanmak temel bir kuraldır.

Etiketleme

Üçüncü ve dördüncü satırlar izleme sistemini çökertebilir: her benzersiz etiket değeri ayrı bir zaman serisi üretir — kullanıcı kimliğini etiket yaparsanız, kullanıcı sayınız kadar seri oluşur ve izleme sistemi belleği tükenir.

Buna kardinalite patlaması denir.

Etiketler yalnızca sınırlı sayıda değer alabilen alanlar olmalıdır.

Tam URL yerine yol şablonu kullanmak doğru yaklaşımdır.

Nereye Yerleştirmeli

• İş mantığının sınırlarına.
• Dış servis çağrılarının etrafına.
• Kuyruk giriş ve çıkışına.

İkinci madde en yüksek getiriyi sağlar: her dış servis çağrısının süresini ve sonucunu ölçmek, arızanın sizde mi karşı tarafta mı olduğunu tartışmasız biçimde belirler.

Bu ölçüm olmadan sorumluluk tespiti tahmine dayanır.

Üçüncü madde ise kuyruk sağlığını verir. Giriş hızı çıkış hızını aşıyorsa birikme başlamıştır.

Bu iki sayacın farkı, kuyruğun geleceğini gösterir.

Ölçüm Maliyeti

1. Sayaç artırmak neredeyse bedavadır.
2. Dağılım biraz daha pahalıdır.
3. Yüksek kardinalite pahalıdır.

Birinci madde çoğu endişeyi ortadan kaldırır: bellekteki bir sayacı artırmak mikrosaniyeler alır — metrik toplamanın uygulamayı yavaşlatacağı korkusu, doğru uygulandığında yersizdir.

Gerçek maliyet, metriklerin toplanmasında ve saklanmasında ortaya çıkar.

Üçüncü madde ise gerçek risktir ve etiket disiplini ile kontrol edilir.

Ölçüm sıklığını da makul tutmak gerekir; saniyede bir toplama çoğu durum için fazlasıyla yeterlidir.

Uyarı Kurma

Üçüncü satırdaki fark, uyarı kalitesinin özüdür: sabit bir eşik yerine eğilime bakan uyarı, hem gereksiz alarmı önler hem de gerçek sorunda daha erken haber verir — disk yüzde yetmişte kalıcı olarak duruyorsa sorun yoktur, hızla doluyorsa vardır.

Sol sütundaki uyarılar zamanla görmezden gelinir.

Sağ sütundakiler ise her tetiklendiğinde bir eylem gerektirir.

Eylem gerektirmeyen uyarı, uyarı değil gürültüdür.

Saklama Süresi

• Ayrıntılı veri kısa süre saklanır.
• Özet veri uzun süre saklanır.
• Karşılaştırma için geçmiş gerekir.

Üçüncü madde sıkça atlanır ve sonradan pişmanlık üretir: bugünkü yükün anormal olup olmadığını anlamanın tek yolu geçen haftanın aynı günüyle karşılaştırmaktır — geçmiş veri saklamıyorsanız normalin ne olduğunu bilemezsiniz.

Bu nedenle en az birkaç aylık özet veri tutulmalıdır.

Birinci madde ise disk maliyetini kontrol eder. Saniyelik veri birkaç gün, dakikalık özet aylarca saklanabilir.

Bu kademeli saklama, hem ayrıntı hem geçmiş sağlar.

Metrik toplama ve saklama için kalıcı disk alanı ve sürekli çalışan bir süreç gerekir; sanal sunucu hizmet paketleri ile izleme altyapınızı kendi sunucunuzda barındırabilirsiniz.

Sonuç

Sistem metrikleri sağlığı ölçer ama anlamı ölçmez: ödeme sağlayıcınız arızalandığında işlemci ve bellek tamamen normal görünür. Uygulama metrikleri bu boşluğu doldurur. Ölçerken ortalamadan kaçının — ortalama yanıt süresi, ne hızlı ne de yavaş isteklerin gerçeğini gösterir — ve etiket disiplinine uyun, çünkü her benzersiz etiket değeri ayrı bir zaman serisi üretir.

Sıkça Sorulan Sorular (SSS)

Sistem metrikleri yetmez mi?

Yetmez. Ödeme sağlayıcınız arızalandığında işlemci ve bellek tamamen normal görünür; sistem metrikleri hiçbir uyarı vermez ama başarısız ödeme oranı anında fırlar. Bu tür arızalar yalnızca uygulama metrikleriyle görülür.

Ortalama yanıt süresi neden yanıltıcı?

Doksan istek 50 milisaniye, on istek 5 saniye sürerse ortalama 545 milisaniyedir — kimse bu süreyi beklememiştir. Yüzdelik dilimler bu sorunu çözer; yüzde doksan beşlik dilim en yavaş yüzde beşin sınırını verir ve gerçek sorunu görünür kılar.

Metriklere hangi etiketleri eklemeliyim?

Yalnızca sınırlı sayıda değer alabilenleri: uç nokta adı, durum kodu gibi. Kullanıcı kimliği veya tam URL tehlikelidir çünkü her benzersiz değer ayrı bir zaman serisi üretir ve izleme sisteminin belleğini tüketir. Buna kardinalite patlaması denir.

Metrik toplamak uygulamayı yavaşlatır mı?

Doğru uygulandığında hayır. Bellekteki bir sayacı artırmak mikrosaniyeler alır. Gerçek maliyet metriklerin toplanmasında ve saklanmasında ortaya çıkar; asıl risk yüksek kardinaliteli etiketlerdir, ölçümün kendisi değil.