Ping izleme, yalnızca bir ana bilgisayarın yanıt verip vermediğini değil; gecikmenin, titreşimin (jitter), paket kaybının ve TTL değerinin zaman içinde nasıl davrandığını takip ederek ağ sorunlarını erkenden tespit eder. Arızaların çoğu kademeli olarak gelişir ve bu değişimler, kullanıcılar destek talebi açmadan dakikalar, hatta saatler önce ping verilerinde görünür. Birkaç konumdan yoklama yapmak ve eğilimlere göre uyarı vermek, bu verileri bir erken uyarı sistemine dönüştürür.
Kesintiler Nadiren Habersiz Gelir
Bağlantılar nadiren tek adımda kusursuz durumdan tamamen kopuk duruma geçer. Tıkanmış bir üst bağlantı (uplink) arabelleklerini doldurur ve gidiş-dönüş süresi tırmanır. Arızalanmaya başlayan bir optik modül, paketlerin küçük bir kısmını düşürmeye başlar. Bir yönlendirme değişikliği trafiği daha uzun bir yola kaydırır. Bunların her biri, yük onları sınırın ötesine itene kadar kullanıcıların algılayabileceği düzeyin altında kalır.
Sayfalar takılmaya veya API istekleri zaman aşımına uğramaya başladığında, sorun çoğu zaman bir süredir birikmektedir. Önemli ana bilgisayarlar için genellikle 30 ila 60 saniyede bir yapılan sürekli ping kontrolleri, bu birikimi veri olarak yakalar.
İzlemeye Değer Erken Uyarı Sinyalleri
Taban çizgisine göre gecikme artışı
Normalden sapma, mutlak sayılardan daha önemlidir. Genellikle 18 ms'de yanıt veren ve şimdi ortalama 45 ms'de yanıt veren bir ana bilgisayar size bir şey söylüyordur; 45 ms tek başına sağlıklı görünse bile. Medyan ve p95 gecikmesini, örneğin önceki haftanın aynı saati gibi kayan bir taban çizgisiyle karşılaştırın ve yüzde 50 ila 100 arasındaki süregelen artışları işaretleyin.
Titreşim (jitter)
Titreşim, ardışık gidiş-dönüş süreleri arasındaki farktır. Artan titreşim çoğu zaman tıkanmış bir bağlantıda kuyruklanmaya veya son kilometre (last-mile) sorununa işaret eder. Sesli iletişim ve gerçek zamanlı uygulamalar, ortalama gecikme alarm verici görünmeden çok önce, titreşim yaklaşık 20 ila 30 ms'yi aştığında sorun yaşamaya başlar.
Aralıklı paket kaybı
Yüzde 0,5 ila 2 arasındaki bir kaybı göz ardı etmek kolaydır, ancak TCP yeniden iletimleri bunu ciddi bir yavaşlık gibi hissettirir. Patlamalar hâlinde veya yalnızca günün belirli saatlerinde görülen kayıplar genellikle tıkanıklığa veya bozulmakta olan donanıma işaret eder.
TTL ve rota değişiklikleri
Bir ping yanıtındaki TTL, paketin kaç atlama (hop) geçtiğini yansıtır; dolayısıyla ani bir değişiklik, yolun değiştiği anlamına gelir. Bu planlı bir yük devretme (failover) olabileceği gibi, bir sağlayıcının trafiği daha yavaş bir yola yönlendirmesi de olabilir. TTL değişimlerini gecikme sıçramalarıyla ilişkilendirmek, “bizim tarafımızda hiçbir şey değişmedi” denen pek çok olayı açıklar.
Yerel mi, Küresel mi? Birden Fazla Konum Kullanın
Tek bir yoklayıcı, bir sunucu sorununu bir İSS (internet servis sağlayıcısı) veya bölgesel sorundan ayırt edemez. Birkaç konumdan yapılan kontroller bu soruyu hızla yanıtlar:
| Gördüğünüz durum | Olası neden |
|---|---|
| Bir konum bozulmuş, diğerleri normal | Bölgesel İSS, eşleme (peering) veya transit sorunu |
| Tüm konumlar birlikte bozulmuş | Ana bilgisayar, veri merkezi üst bağlantısı veya üst akış sağlayıcısı |
| Gecikme yalnızca tek bir kıtadan artmış | Yönlendirme değişikliği veya tıkanmış uluslararası yol |
UpScanX ping izleme, 15'ten fazla küresel konumdan ICMP, TCP ve UDP kontrolleri çalıştırır; böylece bir sağlayıcıya destek talebi açmadan önce sorunun kapsamını doğrulayabilirsiniz.
Tekil Arızalarda Değil, Eğilimlerde Uyarı Verin
Kaybolan tek bir ping gürültüdür ve bunun için uyarı vermek, ekipleri bildirimleri görmezden gelmeye alıştırır. Daha iyi kurallar süreyi, büyüklüğü ve konumlar arası mutabakatı bir araya getirir:
- Bir ana bilgisayarı çalışmıyor ilan etmeden önce art arda üç başarısızlık gibi ardışık başarısızlıklar şart koşun.
- p95 gecikmesi 10 dakika boyunca taban çizgisinin iki katının üzerinde kaldığında uyarı verin.
- 15 dakikalık bir pencere boyunca yüzde 2'nin üzerindeki paket kaybında uyarı verin.
- Sorunu küresel olarak değerlendirmeden önce en az iki konumdan doğrulama şart koşun.
- Erken uyarıları daha düşük aciliyetli bir kanala yönlendirin ve yüksek öncelikli kanalları doğrulanmış kesintiler için ayırın.
UpScanX uyarıları e-posta, Slack, Telegram, Microsoft Teams veya Webhook üzerinden gönderir; yapay zekâ raporları ise sabit eşiklerin kaçırdığı yavaş kaymaları yakalamak için anomali tespiti ekler. Eşiklerle ilgili rehberlik için ağ gecikmesi izleme rehberimize göz atın.
Gerçekçi Bir Örnek Zaman Çizelgesi
Avrupa'dan normalde yaklaşık 22 ms'de yanıt veren bir API ağ geçidini düşünün:
- 09:10 - Frankfurt ve Amsterdam'dan ölçülen p95 gecikmesi 38 ms'ye yükselir ve titreşim iki katına çıkar. Henüz kullanıcı etkisi yoktur.
- 09:25 - Her iki konumdan da yaklaşık yüzde 1'lik paket kaybı görülür. Slack'e bir eğilim uyarısı düşer.
- 09:31 - Dönen TTL değeri iki azalır; bu, üst akış sağlayıcısında bir yol değişikliğine işaret eder.
- 09:40 - Bir mühendis diğer konumların etkilenmediğini doğrular ve zaman damgaları ile yol kanıtlarıyla transit sağlayıcısına başvurur.
- 10:05 - Trafik normal yola, gecikme de taban çizgisine geri döner.
Eğilim tabanlı uyarılar olmasaydı, ilk sinyal büyük olasılıkla saat 10:00 civarında gelen müşteri şikâyetleri olurdu.
Temel Çıkarımlar
- Bozulma genellikle kesintilerden önce gelir ve ping verileri bunu yakalar.
- Yalnızca çalışıyor ya da çalışmıyor durumunu değil; taban çizgisine göre gecikmeyi, titreşimi, aralıklı kaybı ve TTL değişikliklerini izleyin.
- Çok konumlu kontroller, yerel sorunları küresel olanlardan dakikalar içinde ayırır.
- Süregelen eğilimlere ve konumlar arası mutabakata göre uyarı vermek, erken işaretleri kaçırmadan gürültüyü azaltır.