Google SRE Bölüm 6 — Monitoring Distributed Systems

Error budget'ı ölçmek, toil'i azaltmak, sorunları erken görmek; bunların hepsi tek bir katmana dayanıyor: Monitoring. Chapter 6 tam olarak bunu, dağıtık sistemlerde izlemenin nasıl yapılması gerektiğini konu alıyor.

Neden İzliyoruz?

Google Monitoring'in birkaç ayrı amacı olduğunu net bir şekilde ortaya koyuyor: Uzun vadeli trend analizi, zaman içi karşılaştırma, alerting, dashboard'lar ve olay sonrası debugging. Bu ayrım önemli, çünkü tek bir monitoring sistemi bu amaçların hepsini aynı anda iyi karşılamaya çalışırsa genelde hiçbirini iyi karşılayamıyor.

Dört Altın Sinyal

Bölümün en çok alıntılanan, en pratik kısmı burası. Google, bir servisi izlerken odaklanılması gereken dört temel metrik öneriyor.

Latency, isteklerin ne kadar sürede işlendiği. Kritik nüans şu: başarılı isteklerin gecikmesini başarısız isteklerin gecikmesinden ayırmak gerekiyor, çünkü bir hata çok hızlı dönebilir ama bu iyi bir şey değil.

Traffic, sisteme gelen talep miktarı; saniyede istek, saniyede işlem gibi.

Errors, başarısız isteklerin oranı.

Saturation, sistemin kaynaklarının (CPU, bellek, disk I/O) ne kadar dolu olduğu. Bir sistem doygunluğa yaklaştıkça performans genelde önce yavaşça, sonra aniden bozuluyor.

Google'ın önerisi net: sadece dört metriği izleyebiliyorsan, bunları izle.

Alerting Felsefesi: Sayfaya Değer mi?

Bölüm, monitoring sistemlerinin en büyük tuzağına dikkat çekiyor: alert yorgunluğu. Çok fazla, çok hassas alert kurmak, insanları önemli olanı önemsiz olandan ayırt edemez hale getiriyor. Google'ın kuralı sert: bir alert, sadece insan müdahalesi gerektiren, acil ve aksiyon alınabilir bir durum için kurulmalı; aksi halde bu bir dashboard metriği olmalı, sayfa değil.

Üç kategori öneriliyor: alerts (anında müdahale gerektiren), tickets (acil değil ama birilerinin bakması gereken) ve logging (sadece kayıt altına alınması gereken).

Semptom vs Neden

Google, alert'lerin semptomlara göre kurulmasını, olası nedenlere göre kurulmaması gerektiğini öneriyor. "Disk doluluğu %90'ı geçti" yerine "kullanıcılar hata alıyor" gibi semptom bazlı bir alert daha değerli; çünkü kök neden değişebilir ama semptom, yani kullanıcının etkilenmesi, her zaman gerçek soruna işaret ediyor.

Sonuç

Chapter 6, monitoring'i felsefi bir çerçeveye oturtuyor: neyi, neden izlediğini bilmek, alert yorgunluğundan kaçınmak, semptom odaklı düşünmek. Bu prensipler, kitabın ilerleyen bölümlerindeki troubleshooting ve incident management konularının da temelini oluşturuyor.

2026 Merceğinden: Dört Sinyal Endüstri Standardı Oldu, Peki AI Ne Değiştirdi?

Bu bölümü bugün okurken en çarpıcı şey, "Four Golden Signals" fikrinin nasıl kendi türevlerini doğurduğunu görmek. Bugün RED metodolojisi (Rate, Errors, Duration) ve USE metodolojisi (Utilization, Saturation, Errors) gibi çerçeveler, aslında bu dört sinyalin farklı servis türlerine (request-driven vs resource-driven) göre uyarlanmış versiyonları. LGTM stack ile (Loki, Grafana, Tempo, Prometheus) günlük çalışan biri olarak, bu dört sinyalin bugün hâlâ her dashboard'un iskeletini oluşturduğunu rahatlıkla söyleyebilirim.

Asıl ilginç gerilim, kitabın "basit threshold'lar genelde daha güvenilir" tavsiyesiyle bugünün AI destekli anomali tespiti arasında. On yıl önce bir alert kurmak demek, sabit bir eşik belirlemek demekti: "CPU %80'i geçerse uyar." Bugün pek çok gözlemlenebilirlik platformu, sabit eşik yerine dinamik bir baseline öğrenip, o baseline'dan sapmaları anomali olarak işaretliyor. Bu, kitabın "basit her zaman daha iyidir" tezine doğrudan meydan okuyor gibi görünüyor; ama bence aslında çelişmiyor, sadece "basitliğin" tanımı değişti. Kitap, karmaşık iç içe koşullardan (nested conditionals) kaçınmayı öneriyordu, çünkü bunlar kırılgan ve bakımı zor oluyordu. AI tabanlı anomali tespiti de aslında operatöre karmaşık koşul yazdırmıyor; karmaşıklığı modelin içine gizliyor. Yani ilke aynı kalıyor sadece bunu yapmanın aracı değişti.

Bir uyarı da eklemem gerek: AI tabanlı anomali tespiti, "neden" sorusuna kitabın önerdiği kadar net cevap vermeyebiliyor. Semptom bazlı alerting'in gücü, nedenini bilmesen bile "kullanıcı etkileniyor" diyebilmesindeydi. AI modelinin "bu anormal" demesi bazen aynı netliği vermiyor; bu yüzden AI tabanlı sistemleri semptom odaklı, insan tarafından anlaşılabilir alert'lerle birlikte kullanmak hâlâ en sağlıklısı.

Sıradaki durakta Chapter 7'ye geçiyoruz: The Evolution of Automation at Google. Teşekkür ederim.