Çok Bölgeli Sağlık Kontrolü Toplayıcısı İnşa Etmek
São Paulo'daki bir kullanıcı çalışmayan bir uç düğüme (edge node) denk gelir. Hata raporu oluşturmaz. Sekmeyi kapatır ve başka bir şey izlemeye başlar.
Normal bir çalışma süresi (uptime) monitörü bunu kaçırır. Çoğu monitör tek bir konumdan sorgulama yapar. O tek noktadan bakıldığında her şey yolunda (yeşil) görünür.
Gerçek kullanıcılar zaman aşımı (timeout) yaşarken, durum sayfamız %100 çalışma süresi gösteriyordu. Tek bir küresel sağlık kontrolü bize yalan söylüyordu.
İşte gerçeği söyleyen bir sistemi nasıl inşa ettiğimiz.
Sorun: Örnekleme Yanlılığı (Sampling Bias)
Eğer monitörünüz tek bir veri merkezindeyse, sadece tek bir gerçekliği görür. Singapur ve São Paulo uç noktalarınız bağlantıları koparıyor olsa bile durumu "yeşil" olarak raporlayabilirsiniz.
Video trafiği bunu daha da kötüleştirir. Yaygın bölgesel hatalar şunları içerir:
- Bir kıtayı etkileyen hatalı BGP rotaları.
- Yavaş kaynak (origin) geri dönüşlerine (fallback) neden olan önbellek tahliyeleri (cache evictions).
- TLS el sıkışma (handshake) zaman aşımlarına neden olan disk hataları.
- Belirli yerel çözücülerdeki (resolvers) DNS sorunları.
Tek bir "200 OK" yanıtı size neredeyse hiçbir şey söylemez.
Sağlık İçin Üç Kuralımız:
Durum kodlarının ötesine geçtik. Sağlığı üç metrik kullanarak tanımlıyoruz:
- Erişilebilirlik: TCP ve TLS el sıkışmaları 800ms içinde tamamlanmalıdır.
- Gecikme (Latency): p95 İlk Bayt Süresini (TTFB) takip ediyoruz. Ortalamalar, kullanıcıları rahatsız eden yavaş uç değerleri (slow tail) gizler.
- Doğruluk: Yanıt gövdesi beklenen bir işareti içermelidir. Bir hata sayfası döndüren 200 OK bir başarısızlıktır.
Çözüm: Çok Bölgeli Sorgulama (Multi-Region Probing)
Tek bir büyük monitör kullanmayı bıraktık. Bunun yerine, ucuz bölgesel VPS örneklerine küçük Go ikili dosyaları (binaries) dağıtıyoruz.
Her sorgulayıcı (prober):
- Uç noktaları yerel bir bakış açısından kontrol eder.
- Gerçek TTFB verilerini almak için
httptracekullanır. - Sonuçları merkezi bir toplayıcıya (aggregator) gönderir.
Depolama için SQLite kullanıyoruz. Basittir ve iş yükümüzü sıfır ek yükle (overhead) yönetir. Önceden toplanmış veriler yerine ham örnekleri saklıyoruz. Bu, geçmişi yeniden puanlamamıza veya daha sonra belirli hataları ayıklamamıza (debug) olanak tanır.
Sır: Çoğunluk (Quorum)
Ağlar gürültülüdür. Tek bir düşen paket bir kesinti (outage) değildir.
Yanlış alarmları önlemek için bir çoğunluk (quorum) sistemi kullanıyoruz. Bir uç noktayı yalnızca birden fazla bölge hemfikir olduğunda "çevrimdışı" (down) olarak bildiriyoruz. Eğer bir bölge bir hata görüyor ancak diğerleri görmüyorsa, ekibe sayfa (page) göndermiyoruz. Bu tasarım tercihi, yanlış alarmlarımızın %90'ını ortadan kaldırdı.
Temel Dersler:
- Kullanıcıların ulaştığı şeyi sorgulayın, sentetik bir yolu değil.
- Ortalamaları değil, uç gecikmeyi (p95) takip edin.
- Birçok bölgede tek kullanımlık, ucuz sorgulayıcılar kullanın.
- Sayfa yorgunluğunu (pager fatigue) önlemek için çoğunluk (quorum) kullanın.
- Depolama yığınınızı (storage stack) basit tutun.
Ağır bir gözlemlenebilirlik platformuna ihtiyacınız yok. Yerel problara, ham veriye ve gürültü karşısında paniklemeyi reddeden bir kurala ihtiyacınız var.