Bloga geri dön

Çok bölgeli izleme: yanlış pozitif kesintiler nasıl ortadan kaldırılır

· 6 dk okuma

Yanlış alarmlar ekibe uyarıları görmezden gelmeyi öğretir. Çok bölgeli çapraz kontrol, bir kesintiyi yalnızca birkaç bağımsız sonda doğruladığında işaretler.

Çok bölgeli izleme: yanlış pozitif kesintiler nasıl ortadan kaldırılır

Tek bölgeli izleme neden yanıltır

Klasik izlemenin tek bir gözlem noktası vardır (tek bir sunucu ya da bir bulut bölgesi). Bu sonda yanıt alamadığında bir kesinti bildirir. Oysa nedeni aşağıdakilerden herhangi biri olabilir:

  • Sondanın kendi ağındaki bir sorun (route flap, sağlayıcısındaki bir peering sorunu)
  • Sonda tarafında kısa süreli bir DNS aksaklığı
  • Coğrafi olarak sınırlı bir kesinti (bir ülkedeki CDN edge düştü)
  • Altyapınızın tarafında rate limiting ya da bir IP engeli

Gerçek kullanıcıların gözünden site tamamen sağlam olabilir - sadece belirli bir izleme sunucusu için erişilemez durumdadır.

Sonuç: alert fatigue

Haftada 3 "kesinti" bildirimi alan ve bunların 2'si yanlış alarm (yanlış pozitif) olan bir ekip, zamanla tepki vermeyi bırakır. Sonra gerçek bir kesinti geldiğinde tepki gecikir ya da kimse fark etmez. Bu olguya alert fatigue (uyarı yorgunluğu) denir ve devops literatüründe iyi belgelenmiştir.

Amaç mümkün olan en iyi sinyal-gürültü oranıdır (signal-to-noise ratio). Her zaman gerçek olan ayda 1 bildirim almak, 7'si gürültü olan 10 bildirimden iyidir.

Çok bölgeli desen: N sondadan konsensüs

İlke:

  1. 3 şehirde 3 worker düğümünüz var (primary Liptovský Hrádok'ta, eu2 Liptovský Mikuláš'ta, eu1 Bratislava'da). Varsayılan eşik = 3'te 2, bu da gerçek bir konsensüs verir (oybirliği değil). Mimari herhangi bir sayıda düğümü destekler; genişletirken bunlar mevcut konsensüs mekanizmasına eklenir.
  2. Her aralıkta tüm sondalar endpoint'i paralel olarak test eder.
  3. Sonucu birleştirirsiniz: bir kesinti, N sondadan M tanesi bildirirse doğrulanmış olur (tipik olarak M = 2 veya daha fazla).
  4. Tek bir sondanın başarısızlığı alarm tetiklemez - bir sonda "down" bildirirken diğerleri "up" bildiriyorsa, sistem UP durumunda kalır.

Bu, Raft veya Paxos'a benzer consensus algorithm (konsensüs algoritması) denen şeydir - karar oy çokluğuyla verilir.

Pratik kurulum

ePulz.io yönetici panelinde çok bölgeli izleme tek bir anahtarla açılır ve şunlar üzerinden yapılandırılır:

  • Aktif bölgeler - worker listesi, tipik olarak 3-5
  • Konsensüs eşiği - kaç bölgenin DOWN demesi gerektiği (varsayılan: 2)
  • Worker token - doğrulama için ana sunucu ile worker'lar arasında paylaşılan bir gizli anahtar (shared secret)

Her kontrolde ana sunucu, HTTP API üzerinden tüm worker'lara paralel olarak ulaşır. Bir worker yerel bir HTTP, TCP veya ping testi yürütür ve sonucu döndürür. Ana sunucu konsensüsü değerlendirir ve uyarıyı yalnızca eşik aşıldığında yükseltir.

Ödünleşimler

Artılar:

  • Çok daha az yanlış alarm
  • Coğrafi görselleştirme - sitenin hangi bölgelerden çalışmadığını görürsünüz
  • Bölgesel kesintilerin tespiti (bir Cloudflare PoP sorunu, bir ISP'de hatalı yönlendirme)

Eksiler:

  • Gerçek kesinti ile uyarı arasında biraz daha uzun gecikme (birden fazla kaynaktan konsensüs beklenir)
  • Daha yüksek altyapı gereksinimleri ve daha yüksek bir fiyat planı
  • Worker erişilebilirliği - worker'ların yarısı kendisi de erişilemez durumdaysa eşik ulaşılamaz olabilir (çözüm, dinamik eşik = şu anda canlı olan sondalardan M'dir)

Konsensüs hesaplaması örneği

Gerçekten dağıtılmış 3 worker düğümünün yapılandırması: primary Liptovský Hrádok'ta (SK), eu2 Liptovský Mikuláš'ta (SK), eu1 Bratislava'da (SK), eşik = 2.

Senaryo primary (Liptov) eu1 (Bratislava) eu2 (Liptov) Uyarı?
Her şey OK UP UP UP Hayır
Liptov ile hosting'iniz arasında BGP flap DOWN UP UP Hayır (3'te 1)
primary makinenin HW arızası DOWN UP DOWN Evet (3'te 2)
Sunucunuzun gerçek kesintisi DOWN DOWN DOWN Evet

Kendi worker'larınızı nasıl dağıtırsınız

Worker, HTTPS üzerinden kontrol görevleri alan, testi çalıştıran ve sonucu döndüren basit bir servistir. ePulz.io, bir WireGuard tüneli üzerinden özel worker'ları destekler; böylece bunlar genel IP'si olmayan herhangi bir VPS'te çalışabilir ve ana sunucuyla şifreli bir tünel üzerinden iletişim kurabilir.

Tek bir worker'ı yapılandırmak pratikte yaklaşık 10 dakika sürer (apt install wireguard, peer config'i kopyalama, systemctl enable). Böylece coğrafi çeşitliliği (farklı şehirler) donanım yedekliliğiyle (aynı şehirde farklı makineler) birleştiren gerçekten bağımsız gözlem noktaları elde edersiniz.

Sonuç

Çok bölgeli izleme yalnızca bir pazarlama klişesi değildir. İzlemeyi "bir ağ konumunun gördüğünü görüyorum" düzeyinden "internetin gördüğünü görüyorum" düzeyine taşıyan somut bir mühendislik desenidir (çoğunluk, yani konsensüs). Kritik iş uygulamaları için bugün standart budur.

Yanlış pozitif uyarıları ortadan kaldırın

Temel planlarda çok bölgeli çapraz kontrol (merkezi olarak yönetilir). 7 gün ücretsiz.

İzlemeyi başlat →

İlgili

Paylaş: Bağlantı kopyalandı

ePulz.io'yu ücretsiz deneyin - 7 gün, kredi kartı gerekmez.

Hesap oluştur