Yardım masasına düşen en yaygın kayıt "internet yavaş" oluyor. Bu cümlenin arkasında birbirinden tamamen bağımsız en az dört farklı sorun olabilir; birini çözmek diğerini etkilemez. Ölçüm yapmadan cihaz değiştirmek ya da hat büyütmek çoğu zaman parayı boşa harcamak anlamına geliyor.
Önce ayrıştırın
Sorunu dört başlıkta ayırmak, çözüm alanını dramatik biçimde daraltır:
- Gecikme (latency): paket gidip geliyor ama geç geliyor. Mesafe, yönlendirme yolu veya cihaz üzerindeki işleme süresi kaynaklı olabilir.
- Paket kaybı: paket hiç ulaşmıyor. Genelde fiziksel katman, doygunluk veya hatalı yapılandırma işareti.
- Doygunluk (congestion): hat kapasitesi doluyor, kuyruklar büyüyor. Gecikme ve kayıp birlikte artıyor.
- Uygulama katmanı: ağ sağlıklı, sorun sunucuda, DNS çözümlemesinde ya da uygulamanın kendisinde.
Arayüz sayaçları ilk bakılacak yerdir
Pahalı bir araç kurmadan önce, cihazlarınızın zaten topladığı veriye bakın. Arayüz üzerindeki hata sayaçları çoğu fiziksel sorunu doğrudan gösterir:
# Cisco IOS
show interfaces | include (^[A-Z]|error|drops|CRC|resets)
# Juniper JunOS
show interfaces extensive | match "Physical|Errors|Drops|CRC"
# Linux
ip -s -s link show dev eth0Artan CRC hataları neredeyse her zaman fiziksel bir sorunu işaret eder: kötü bir kablo, kirli bir fiber konnektörü ya da uyumsuz optik. Input drops kuyruk taşmasını, output drops ise çıkış hattının dolduğunu gösterir. Bu üçünü ayırt etmek, sorunu doğru katmana taşımanızı sağlar.
Gecikmeyi doğru ölçmek
Tek bir ping çıktısına bakmak yanıltıyor. Asıl bilgi zaman içindeki dağılımda: ortalama gecikme kabul edilebilirken jitter yüksekse, ses ve görüntü trafiği bozulur ama dosya transferi normal görünür. Kullanıcı da haklı olarak "bazen yavaş" der.
Uçtan uca ölçüm için hop bazlı kayıp ve gecikme veren araçlar kullanın:
# Hop bazli surekli olcum
mtr --report --report-cycles 200 hedef.example.com
# Jitter ve kayip icin uzun sureli ornek
ping -i 0.2 -c 1000 hedef.example.com | tail -3Trafiğin kim tarafından üretildiğini görün
Hat doluysa asıl soru şudur: neyle dolu? NetFlow, sFlow veya IPFIX ile akış verisi toplamak, bant genişliğini hangi kaynağın, hangi hedefe, hangi uygulama için tükettiğini gösterir. Bu veri olmadan yapılan kapasite artırımı, çoğu zaman aynı sorunun daha pahalı hâlini satın almaktır.
Pratikte sık karşılaştığımız tablo: hattın yarısını yedekleme trafiği ya da kontrolsüz bir güncelleme dağıtımı tüketiyordur. Bu durumda çözüm kapasite değil, zamanlama ve QoS politikasıdır.
Ölçmeden önce ve sonra
Her müdahaleden önce referans ölçüm alın, sonrasında aynısını tekrarlayın. "Daha iyi oldu" bir sonuç değil; "p95 gecikme 84 ms'den 31 ms'ye indi, paket kaybı %1.2'den %0'a düştü" bir sonuç. Bunu yapmanın ikinci faydası da bir sonraki sorunda elinizde karşılaştıracak bir veri olması.