Sayılar nasıl hesaplanır

Orbtrace'in gösterdiği her sayı telemetrinizden hesaplanır — sihir yok. Bu sayfa, her birinin gerçekte ne anlama geldiğinin referansıdır; böylece asla tahmin etmek zorunda kalmazsınız. Bir sayının yanlış okunması kolaysa, bunu açıkça söylüyoruz.

Trafik, hatalar, kullanılabilirlik (RED)

Bir servisteki bu üç "altın sinyal", servisin seçili pencerede işlediği gelen-istek span'leri üzerinden hesaplanır — SERVER span'leri (sunduğu senkron istekler) artı CONSUMER span'leri (aldığı mesaj-temelli iş). Servisin kendi giden çağrıları (CLIENT) ve iç işi (INTERNAL) kasıtlı olarak hariç tutulur, böylece bu sayılar etiketlerinin söylediği şeyi ifade eder — tam olarak Google SRE altın-sinyalleri ve Datadog/OTel'in tanımladığı gibi.

Hiç gelen istek sunmayan bir servisin (saf background worker, cron, saf client) tanımı gereği istek trafiği yoktur, dolayısıyla iç span'lerinden uydurulmuş bir sayı yerine boş bir RED gösterir.

Percentile'lar (p50 / p95 / p99)

Gecikme percentile'ları, gelen-istek span sürelerinden (yukarıdaki RED sinyalleriyle aynı SERVER + CONSUMER span'leri) yaklaşık-quantile bir sketch ile (ham span'lerde Doris percentile_approx ya da rollup tablolarında eşdeğer quantile-union) sabit 2048 sıkıştırmada hesaplanır. Her yerde aynı taban ve sıkıştırma kullanılır — servis listesi, detay sayfası, şelale baseline'ları, SLO/burn-rate motoru ve sabah-brief metrikleri — böylece bir servis için gördüğünüz her p95 uyuşur. Buradaki p95, servisin sunduğu isteklerin gecikme dağılımıdır; iç/giden span'lerinin değil.

Sağlık (servis-başına renk)

Sağlık etiketi, bu kademe içinde yukarıdan aşağı ilk eşleşmedir. Eşikler servis/katman bazında ayarlanabilir; varsayılanlar gösteriliyor.

SLO hedefi ve severity

Her servisin, hiç ayarlamasanız bile bir etkin SLO'su vardır; şu sırayla çözülür: açık servis-başına sözleşme → namespace-katman varsayılanı → global varsayılan. Kaynak satırda gösterilir (açık bir sözleşme "(varsayılan)" olandan farklı okunur).

Severity = mevcut p95 ÷ hedef p95. 1.0 üstü, p95'in hedefin üstünde olduğu demektir (ör. 1.5 = %50 üstünde). Severity bir gecikme-aşım oranıdır — burn rate ya da hata bütçesiyle aynı şey değildir, ve her zaman bir global varsayılan hedef olduğundan, yoğun bir servis açıkça ayarlamadığınız bir varsayılana karşı BURNING görünebilir. Bu sizi şaşırtıyorsa açık bir SLO sabitleyin.

Burn rate (çok-pencereli)

Burn rate "hata bütçemi ne hızla harcıyorum?" sorusunu yanıtlar. Her pencere için:

aşım oranı = (p95 SLO hedefinden yavaş istekler) ÷ (penceredeki istekler)
burn rate  = aşım oranı ÷ 0.05

0.05, %95 hedefin ima ettiği hata bütçesidir — yani 1× burn, bütçeyi tam izin verilen hızda harcadığınız; 2× 30 günlük bütçeyi 15 günde; 14.4× ~2 günde bitirir. Dört pencere şu eşiklerde tetiklenir: 5dk ve 1sa → 14.4× (hızlı), 30dk ve 6sa → 6× (yavaş). 1sa ve 5dk birlikte tetiklenince bir page atar; 6sa ve 30dk birlikte tetiklenince bir ticket (çift-pencere kombosu tek-pencere yanlış pozitifleri bastırır — Google SRE Workbook deseni).

Bilinmesi gereken bir uyarı: 0.05 bütçesi %95 (p95) hedefe sabittir, dolayısıyla bir p99 da ayarlamış olsanız bile burn rate her zaman p95 hedefinize karşı ölçülür.

Hata-bütçesi runway'i ("6.1g bütçe kaldı")

Runway, mevcut hızda kaç gün bütçe kaldığını tahmin eder; kabaca pencere ÷ burn rate olarak hesaplanır ve 365 günle sınırlanır. Yalnızca ihlal eden servisler için gösterilir. Orbtrace verinizin desteklediği en hassas modeli kullanır — mümkünse son 30 günlük dağılımdan bir kalan-bütçe modeli, yoksa daha basit bir tam-pencere modeli, canlı aşım örneği yoksa doğrusal bir 30 ÷ (severity − 1) sezgisel yöntemi. Geri-düşüşler biraz farklı sayılar verebilir, o yüzden runway'i kesin bir geri sayım değil, yönsel bir sinyal ("saatler" vs "haftalar") olarak okuyun.

Apdex

Apdex 0–1 arası bir kullanıcı-memnuniyeti skorudur:

Apdex = (memnun + tolere / 2) ÷ toplam

pencere boyunca; bir istek ≤ T'de memnun, T ile 4T arasında tolere, 4T üstünde hayal kırıklığı. Bantlar: ≥0.94 mükemmel, ≥0.85 iyi, ≥0.70 orta, ≥0.50 zayıf, altı kabul edilemez.

Önemli ayrıntı: Orbtrace T = p95 SLO hedefiniz olarak ayarlar, ayrı seçilmiş bir Apdex eşiği değil. Yani buradaki Apdex SLO'nuza sıkıca bağlıdır — sağlıklı bir servis yapısı gereği skalanın tepesine yakın oturur ve açık SLO'su olmayan bir servis, geçerli olan varsayılan p95'e karşı puanlanır. Apdex'i bağımsız bir kıyas değil, "p95 SLO'nuza göre memnuniyet" olarak okuyun.

Doygunluk (CPU / bellek)

Doygunluk, uygulamalarınızın yaydığı process/runtime kaynak metriklerini okur ve şu sırayla ilk mevcut kaynağı seçer: container → Kubernetes pod → process → dil runtime'ı → host. Gösterge, bir limit metriği varsa (container/pod katmanları) kullanım ÷ limit'tir. Runtime katmanlarının (JVM heap, Go bellek, …) genelde eşlik eden limiti yoktur, dolayısıyla bunlar doygunluk yüzdesi olmadan kullanımı gösterir. Panel hangi kaynaktan çözüldüğünü gösterir — aynı "bellek" göstergesi, servisin ne yaydığına bağlı olarak bir serviste kullanım/limit, diğerinde çıplak kullanım anlamına gelebilir. CPU bir oran (utilization katmanları) ya da çekirdek (counter-türevli katmanlar) olarak gösterilir.

"Sapma" vs anomali alarmları

İki farklı sistem "anomali" sözcüğünü kullanır — aynı şey değildirler:

• Servis-listesindeki DEVIATING rozeti basit bir oran kontrolünden gelir: son 60 dakika vs önceki 24 saatlik baseline; latency-p95 ya da istek-hızı ≥ 2× (sıçrama) veya ≤ 0.5× (düşüş) olduğunda işaretlenir. Kasıtlı olarak kabadır ve normal günlük rampalarda da tetiklenebilir.
• RCA ve alarmı besleyen anomali motoru ayrı bir z-skoru / mevsimsel modeldir (|gözlem − ortalama| ÷ stddev). Daha titizdir ve Olaylar'ı ve anomali alarmlarını süren odur.

Yani "DEVIATING" bir servis mutlaka istatistiksel bir anomali değildir — sadece düne göre çok hareket etmiştir.

"Nines" üzerine bir not

Kullanılabilirlik fazladan ondalıkla gösterildiğinde (%99.95), bu bir gösterim-hassasiyeti kuralıdır, bir durum eşiği değil — gizli bir "üç dokuz" kararı yoktur. Ve yukarıdaki RED'den hatırlayın: bu kullanılabilirlik, pencere boyunca istek-başarısıdır, zaman-temelli uptime değil.