Ping izleme, bir ana makineye tekrar tekrar küçük yoklama paketleri gönderir ve makinenin yanıt verip vermediğini, gidiş-dönüş süresinin ne kadar sürdüğünü ve kaç paketin kaybolduğunu kaydeder. Size bir makinenin ağ üzerinde erişilebilir olup olmadığını söyler; üzerinde çalışan uygulamanın çalışıp çalışmadığını değil. Web uç noktası olmayan cihazlar ve hizmetler için ping'i, önemsediğiniz şey bir sayfa veya API yanıtı olduğunda ise HTTP kontrollerini kullanın.
Ping İzleme Nasıl Çalışır?
Klasik bir ping, bir yankı yanıtıyla (echo reply) karşılanan bir ICMP yankı isteğidir (echo request). İzleyici şunları takip eder:
- Gidiş-dönüş süresi (RTT): Yoklamadan yanıta kadar geçen gecikme; genellikle ortalama ve p95 olarak.
- Paket kaybı: Hiç geri dönmeyen yoklamaların payı. Kablolu bir yolda kabaca %1–2'nin üzerindeki sürekli kayıp genellikle incelenmeyi hak eder.
- Titreşim (jitter): Örnekler arasındaki RTT değişkenliği; VoIP ve gerçek zamanlı trafik için önemlidir.
Pek çok ağ ICMP'yi engeller veya hızını sınırlar. Bu durumda 22 veya 443 gibi açık bir porta yapılan el sıkışmanın süresini ölçen bir TCP ping güvenilir bir erişilebilirlik sinyali verir; UDP yoklamaları ise 53 numaralı porttaki DNS gibi hizmetleri kapsar. İşleyişin daha ayrıntılı açıklaması için ping izlemenin nasıl çalıştığına göz atın.
Ping ve HTTP Kontrolleri: Katman 3 ve Katman 7
Temel fark, her kontrolün nerede durduğudur: ping ağ katmanında, HTTP ise uygulama katmanında durur.
| Soru | Ping (ICMP/TCP/UDP) | HTTP kontrolü |
|---|---|---|
| Ana makine erişilebilir mi? | Evet | Dolaylı olarak |
| Rota kötüleşiyor mu (gecikme, kayıp)? | Evet | Kısmen |
| Web sunucusu 200 döndürüyor mu? | Hayır | Evet |
| Yanıt gövdesi doğru mu? | Hayır | Evet, anahtar kelime veya JSON doğrulamalarıyla |
| Web sunucusu olmayan cihazlarda çalışır mı? | Evet | Hayır |
Nginx 502 hataları döndürürken veya uygulama bir çökme döngüsüne takılmışken bir sunucu ping'e kusursuz yanıt verebilir. Ping'in başarılı olması, bir web sitesinin çalıştığını asla kanıtlamaz.
Ping Ne Zaman Doğru Seçimdir?
Hedefin HTTP yüzeyi olmadığında veya önemli olan şey ağ yolunun kendisi olduğunda ping daha iyi bir birincil kontroldür:
- Yönlendiriciler, anahtarlar ve güvenlik duvarları. Bunlar çoğu zaman yalnızca SSH veya SNMP sunar. Ping, cihazların çalıştığını doğrular ve artan üst bağlantı (uplink) gecikmesini ortaya çıkarır.
- VPN ağ geçitleri ve siteden siteye tüneller. Tünelin ötesindeki bir ana makineye ping atmak, yalnızca ağ geçidinin açık olup olmadığını değil, trafiğin gerçekten geçip geçmediğini gösterir.
- Veritabanı ve önbellek sunucuları. PostgreSQL, MySQL veya Redis sunucuları HTTP sunmamalıdır. Hizmet portuna yapılan bir TCP ping, dürüst sinyaldir.
- IoT ve uç cihazlar. Kameralar, sensörler ve POS terminalleri çoğu zaman yalnızca bir IP adresine ve bir ICMP yanıtlayıcısına sahiptir.
- E-posta, oyun ve HTTP dışı diğer sunucular. SMTP, özel TCP hizmetleri ve UDP oyun sunucuları TCP veya UDP yoklamalarına uygundur.
Geçici kesintileri filtrelemek için iki veya üç ardışık başarısızlıktan sonra uyarı veren 30–60 saniyelik aralıklar tipiktir.
HTTP Kontrollerine Ne Zaman İhtiyacınız Olur?
Müşterilerin bir tarayıcı veya istemci kütüphanesi aracılığıyla ulaştığı her şey HTTP izlemeye ihtiyaç duyar: web siteleri, oturum açma ve ödeme akışları, REST ve GraphQL API'leri. HTTP kontrolleri; durum kodlarını, yanıt süresini, yönlendirmeleri ve gövde içeriğini doğrulayarak hatalı dağıtımlar, 500 olarak yansıyan veritabanı hataları veya yanlış yapılandırılmış CDN'ler gibi ağ katmanının üzerindeki arızaları yakalar. SLA'nız başarılı istekleri sayıyorsa ping tek başına bunu ölçemez.
İkisini Birleştirmek Olay Önceliklendirmesini Neden Hızlandırır?
Aynı hizmete karşı her iki kontrolü de çalıştırmak, bir “site çöktü” uyarısını teşhise dönüştürür:
- Ping başarısız, HTTP başarısız: Muhtemelen bir ağ, ana makine veya sağlayıcı sorunu.
- Ping başarılı, HTTP başarısız: Ana makine erişilebilir; bu nedenle web sunucusuna, uygulamaya, TLS'e veya üst akış bağımlılıklarına bakın.
- İkisi de başarılı, gecikmede ani artış: Ağ tıkanıklığını yavaş koddan ayırmak için RTT'yi HTTP yanıt süresiyle karşılaştırın.
Birden fazla bölge başka bir boyut ekler: Yalnızca bir konum ping'i kaybediyorsa sunucunuzdan çok bölgesel bir rotadan şüphelenin. UpScanX, ICMP, TCP ve UDP yoklamalarını HTTP/HTTPS kontrolleriyle birlikte 15'ten fazla küresel konumdan çalıştırır; böylece iki sinyal de tek bir zaman çizelgesini paylaşır ve yapay zekâ raporları ilişkili uyarıları kök neden ipuçlarıyla ilişkilendirir. Uyarılar e-posta, Slack, Telegram, Microsoft Teams veya bir webhook'a gider.
Önemli Çıkarımlar
- Ping; ağ katmanında erişilebilirliği, RTT'yi, paket kaybını ve titreşimi ölçer; uygulama sağlığı hakkında hiçbir şey söylemez.
- Yönlendiriciler, güvenlik duvarları, VPN ağ geçitleri, veritabanı sunucuları, IoT cihazları ve HTTP dışı sunucular için ping'i veya ICMP'nin filtrelendiği yerlerde TCP ve UDP yoklamalarını tercih edin.
- Kullanıcıların veya API istemcilerinin dayandığı her şey için HTTP kontrollerini kullanın.
- Kritik hizmetlerde ikisini birlikte kullanın; böylece uyarı örüntüsünün kendisi hangi katmanın bozulduğunu size söyler.
Çalışma süresi (uptime) izleyicilerinizin yanına ağ katmanı kontrolleri eklemek için UpScanX ping izleme ile başlayın.