Bir servis çalışıyor olabilir; peki iyi çalışıyor mu?
Dört temel sinyal, kuyruk gecikmesi ve SLO üzerinden servis sağlığını kullanıcıya verilen hizmetle birlikte okumak.
Bir HTTP isteğine cevap alabilmek yararlı bir kontrol. Kullanıcıya zamanında ve doğru cevap verildiğini anlamak için daha fazlasına ihtiyaç var.
Bu yazı, Google SRE ve Prometheus belgelerine dayanan bir giriş. Örnek sayılar kavramları açıklamak için seçildi; bir serviste ölçülmüş yük testi sonuçları değil.
Dört soruyla başlamak
Google’ın SRE kitabındaki dört temel sinyal, bir servisi izlemeye başlamak için kullanışlı bir çerçeve:
| Sinyal | Sorduğu soru | Örnek gösterge |
|---|---|---|
| Latency | İstek ne kadar sürede sonuçlanıyor? | Başarılı ve başarısız isteklerin süre dağılımları. |
| Traffic | Sisteme ne kadar iş geliyor? | Saniyedeki istek sayısı. |
| Errors | Ne kadar iş başarısız oluyor? | Hatalı yanıt veya beklenen içeriği üretmeyen yanıt oranı. |
| Saturation | Sınırlayıcı kaynak ne kadar dolu? | CPU, bağlantı havuzu veya kuyruktaki doluluk. |
Bu göstergeleri birlikte okumak gerekir. Trafik yükselirken kuyruk büyüyorsa ve yanıt süreleri uzuyorsa, “servis ayakta” bilgisi kullanıcı deneyimini tek başına anlatmaz. Hızlı dönen hatalar da genel gecikme ortalamasını iyileşmiş gibi gösterebilir; başarı ve hata sürelerini ayırmak bu yüzden yararlıdır.
Ortalama hangi istekleri saklıyor?
Tamamen varsayımsal 100 isteklik bir örnek düşünelim:
- 95 istek 20 ms’de tamamlanıyor.
- 5 istek 2.000 ms’de tamamlanıyor.
Ortalama 119 ms. Ancak beş kullanıcı iki saniye bekliyor. Tek bir ortalama, bu dağılımın şeklini göstermiyor.
p99, gözlemlerin yaklaşık yüzde 99’unun altında kaldığı gecikme seviyesini anlatır. Bu örneğin p99 değeri 2.000 ms seviyesindedir. Ölçüm penceresi ve örnek sayısı da belirtilmeli; seyrek trafikte kısa bir pencerenin p99’u kararsız olabilir.
Prometheus’ta histogramlar, bu tür dağılımları izlemek için kullanılabilir. Quantile hesabı bir tahmindir; çözünürlük ve klasik histogramlarda bucket sınırları hata payını etkiler. Ayrıca ayrı sunucuların p99 değerlerinin ortalamasını almak, bütün isteklerin p99’unu vermez. Uygun histogram verisi birleştirilip quantile bunun üzerinden hesaplanır. Ayrıntılar histogram ve summary rehberinde yer alıyor.
Başarıyı bir hedefe bağlamak
Bir SLI (service level indicator), sunulan hizmetin ölçülen göstergesidir. SLO (service level objective) ise bu gösterge için hedef koyar. Google SRE Workbook, birçok SLI’yı “iyi olay sayısı / toplam uygun olay sayısı” biçiminde tanımlamayı öneriyor.
Örnek bir hedef şöyle kurulabilir: “Son 30 günde kapsama alınan isteklerin yüzde 99,9’u hem başarılı olsun hem de 300 ms altında tamamlanmış olsun.” Bu, anlatım için seçilmiş bir hedef; mevcut bir hizmet taahhüdü değil.
Burada hangi isteklerin kapsama girdiği, başarının ne olduğu ve zamanlamanın nereden başladığı açık olmalı. İstemci hataları, iptaller ve timeout’lar için karar verilmeden pay ve paydayı yorumlamak zorlaşır.
Bu örnekte hata bütçesi yüzde 0,1 olur. Tam bir milyon uygun istek varsa, 1.000 kötü olaylık bütçe anlamına gelir. Kullanıcı ihtiyacına göre hedef ve pencere değişir; evrensel bir doğru yüzde yoktur. Kavramların ilişkisi Implementing SLOs bölümünde anlatılıyor.
Bir grafikten nedene nasıl yaklaşılır?
Yüksek gecikme bir belirtidir. Bunun veritabanı, bağlantı bekleme, CPU işi veya başka bir aşamadan geldiğini söylemek için ilgili aşamaları gözlemlemek gerekir.
Bir inceleme sorusunu şöyle daraltabiliriz: “Trafik aynıyken bağlantı bekleme süresi artıyor mu?” Ardından istek gecikmesini, havuzdaki bekleyenleri ve bağımlılık sürelerini aynı zaman aralığında karşılaştırırız. Birlikte değişmeleri aday bir açıklama sunar; neden-sonuç ilişkisi için kontrollü bir karşılaştırma gerekebilir.
Amaç çok sayıda grafik biriktirmekten önce şu cümleyi cevaplayabilmek: Kullanıcı hangi hizmeti alıyor ve hangi gözlem bu değerlendirmeyi destekliyor?
Small experiments. Honest notes.