Bölgeler arasında paket kaybını ve gecikmeyi izlemek için, kullanıcılarınızın bulunduğu yerleri yansıtan birkaç konumdan aynı hedeflere karşı aynı yoklamaları çalıştırır ve ardından her bölgeyi tek bir küresel sayı yerine kendi temel çizgisiyle karşılaştırırsınız. Ortalamalar yerine yüzdelikleri ve jitter'ı takip edin, kaybı anlamlı şekilde ölçmek için kontrol başına yeterli sayıda paket gönderin ve yalnızca bir desen yoklayıcılar genelinde geçerli olduğunda veya zaman içinde sürdüğünde alarm verin.
Kullanıcılarınızla Eşleşen Yoklama Bölgeleri Seçin
Bir haritayla değil, trafik verileriyle başlayın. Oturumların çoğu Batı Avrupa'dan, ABD Doğu Kıyısı'ndan ve Güneydoğu Asya'dan geliyorsa, bunlar birincil yoklama bölgelerinizdir; sözleşmeye dayalı SLA'larınızın bulunduğu yerlere ikincil bölgeler ekleyin. Her büyük pazar için en az iki yoklayıcı kullanın; böylece bir yoklayıcının yerel sorunu asla bir bölgesel kesinti gibi görünmez.
Veri merkezi yoklayıcılarının konut veya mobil bağlantılara göre daha temiz yollar gördüğünü unutmayın; bu nedenle onları en iyi durum görünümü olarak değerlendirin.
Fizik Kurallarına Dayalı Bölge Bazında Temel Çizgiler Belirleyin
Fiber içindeki ışık milisaniyede yaklaşık 200 km yol alır; bu nedenle her 100 km kablo, kuyruklanmadan önce gidiş-dönüş süresine yaklaşık 1 ms ekler. Gerçek rotalar düz çizgilerden daha uzundur; dolayısıyla tipik aralıklar şöyle görünür:
| Yol | Tipik RTT |
|---|---|
| Aynı şehir veya bulut bölgesi | 1–5 ms |
| Batı Avrupa içi | 10–30 ms |
| ABD Doğu'dan ABD Batı'ya | 60–75 ms |
| ABD Doğu'dan Batı Avrupa'ya | 75–95 ms |
| Batı Avrupa'dan Singapur'a | 150–190 ms |
| Batı Avrupa'dan Sidney'e | 250–300 ms |
Singapur'dan bir Frankfurt sunucusuna 180 ms'lik bir ölçüm normaldir; aynı ölçümün Amsterdam'dan gelmesi ise bir olaydır. Temel çizgileri her bölge için en az bir haftalık veriden oluşturun ve sapmalarda alarm verin; örneğin p95'in yedi günlük normalinin yüzde 30–50 üzerine çıkması gibi.
Kaybı ve Gecikmeyi İstatistiksel Özenle Ölçün
Üç ping gönderen bir kontrol yalnızca yüzde 0, 33, 67 veya 100 kayıp raporlayabilir; bu, TCP verimine zaten zarar veren yüzde 1–2'lik kaybı görmek için fazla kabadır. Pratik öneriler:
- Kontrol başına 10–20 paket gönderin veya kaybı hesaplamadan önce birkaç kontrolü beş dakikalık kayan bir pencerede birleştirin.
- Tipik deneyim için p50'yi, kullanıcıların şikâyet ettiği kuyruk kısmı için ise p95'i raporlayın. Ortalamalar ani artışları gizler.
- Ardışık RTT örnekleri arasındaki değişim olan jitter'ı takip edin. Yaklaşık 20–30 ms'nin üzerindeki jitter, gecikme sağlıklı görünse bile gerçek zamanlı trafiği bozar.
- ICMP'yi servis portu üzerindeki TCP kontrolleriyle eşleştirin; çünkü bazı yönlendiriciler ICMP'yi hız sınırlamasına tabi tutar ve uygulama trafiğinin hiç görmediği kayıpları gösterir.
UpScanX ping izleme hizmeti, 15'ten fazla küresel konumdan ICMP, TCP ve UDP kontrollerini destekler; böylece her bölge için aynı yoklamaları çalıştırıp bunları yan yana karşılaştırabilirsiniz.
Nedeni Ayırt Etmek İçin Bölgeleri Karşılaştırın
Bölgeler arası karşılaştırma, bir sorunun nerede olduğunu daraltmanın en hızlı yoludur:
- Tüm bölgeler birlikte bozuluyor: Sorun büyük olasılıkla kaynak sunucuda (origin) veya onun üst akış sağlayıcısındadır.
- Bir bölge bozuluyor, diğerleri sorunsuz: O yol üzerindeki bir transit sağlayıcısından, bir eşleşme (peering) noktasından veya bölgesel bir İSS'den şüphelenin.
- Bir bölgede yalnızca CDN arkasındaki uç noktalar bozuluyor: Kaynak sunucunuz yerine o bölgeye hizmet veren uç (edge) konumunu kontrol edin.
- Kayıp yalnızca ICMP'de görünüyor: Büyük olasılıkla ara bir yönlendiricideki hız sınırlamasıdır, gerçek bir kullanıcı etkisi değildir.
Bir bölge bozulduğunda, o yoklayıcıdan bir traceroute veya MTR çalıştırın ve bunu sağlıklı bir bölgenin rotasıyla karşılaştırın. Gecikmenin nerede sıçradığına ve sonraki her atlamada (hop) yüksek kalıp kalmadığına bakın; ortadaki bir atlamada görülüp aşağı akışta kaybolan bir artış genellikle yalnızca yanıtlara düşük öncelik veren bir yönlendiricidir. Yolun nerede bozulduğunu bir sağlayıcıya gösterebilmek için izleri olaya ekleyin.
Çoğunluğa Göre Alarm Verin, Bölgeye Göre Raporlayın
Tek yoklayıcılı alarmlar gürültü üretir. Bir bölgedeki en az iki yoklayıcı veya bölgelerin çoğunluğu iki ya da üç ardışık kontrol boyunca eşiği aştığında alarm verin. Etkilenen tek bir pazar için uyarı, birden fazla bölge hemfikir olduğunda ise kritik alarm kullanın ve bunları Slack, Microsoft Teams, E-posta, Telegram veya bir webhook'a yönlendirin.
Raporlama için bölge bazında p95 gecikmesini, kaybı ve jitter'ı çalışma süresi (uptime) ile birlikte yayınlayın. UpScanX yapay zekâ raporları anomalileri işaretler, ilgili alarmları ilişkilendirir ve zamanlanmış e-posta özetleri gönderir. RTT ve eşik tasarımına daha ayrıntılı bir bakış için ağ gecikmesi izleme rehberimize göz atın.
Önemli Çıkarımlar
- Yoklayıcıları kullanıcılarınızın bulunduğu yerlere, her büyük pazar için en az iki tane olacak şekilde yerleştirin.
- Her bölge için ayrı temel çizgi oluşturun; mesafe, gecikme için fiziksel bir alt sınır belirler.
- Kontrol başına yeterli paket kullanın ve ortalamalar yerine p95 ile jitter'ı takip edin.
- Kaynak sunucu, İSS ve CDN sorunlarını ayırmak için bölgeleri karşılaştırın ve rotaları izleyin.
- Çoğunluk ve süreklilik esasına göre alarm verin, metrikleri bölge bazında raporlayın.