Yanıt Süresi İzleme

Neden yanıt süresi kendi uyarısını hak ediyor?

Standart uptime uyarıları ikili bir sinyale dayanır: açık veya kapalı. Aradaki gri alan — açık ama yavaş — aslında modern arızaların çoğunun yaşandığı yerdir. Kötü yapılandırılmış bir veritabanı sorgusu 50ms yerine 4 saniye sürmeye başlar. Bellek sızıntısı çöp toplama sıçramalarına neden olur. Backend'in çağırdığı harici API titremeye başlar. Bu sorunların hiçbiri siteyi tamamen bozmaz, ancak onu kullanılamaz hale getirir — ve bunlar, bir veya iki saat uzakta olan bir arızanın erken sinyalleridir.

Yanıt süresi izleme, bir kesinti haline gelmeden yavaşlamayı yakalar. Her monitör için bir eşik ayarlarsınız ve yanıt süresi bunu birkaç ardışık kontrolde aşarsa, bir uyarı alırsınız. Uyarı gitmeden önce hâlâ araştırmak, ölçeklendirmek, sorunlu çağrıyı kısıtlamak veya tetikleyen deploy’u geri almak için zamanınız olur.

DiagnoSEO Uptime Monitoring’de eşikler nasıl çalışır?

Her monitör iki parametreyle yapılandırılabilir: rt_threshold_ms ve rt_threshold_breaches. İlki, kabul edilebilir bulduğunuz milisaniye cinsinden yanıt süresidir. İkincisi ise uyarının tetiklenmesi için kaç ardışık kontrolün eşiği aşması gerektiğidir. Varsayılan olarak eşik kapalıdır ve ihlal sayısı üçtür.

İki parametreli tasarım yanlış pozitifleri önler. Ağ jitter’ı olabilir. Çöp toplamanın kısa duraksamaları olabilir. 200ms olan baz seviyesinde bir seferlik 1 saniyelik sıçrama sizi sabaha karşı 3’te alarma geçirmemelidir. Ancak üç ardışık 1 saniyelik yanıt süresi — artık bu kalıcı bir yavaşlamadır, anlık bir sıçrama değil. Eşiğinizi gözlemlediğiniz normal davranış ve rahat bir tolerans ile seçin: eğer p95 normalde 400ms ise, eşik 1000ms; p95 50ms ise (iç API) eşik 200ms.

Nelerle iyi çalışır?

Yanıt süresi uyarıları, diğer monitör sinyalleriyle birlikte en iyi sonucu verir. Tam tablo: yanıt süresi eşiği, sistemin bozulmakta olduğunu gösterir; HTTP kodu gerçekten bozulduğu anı söyler; SSL/domain uyarıları — zamana bağlı arızaları; DNS değişiklik uyarıları — konfigürasyon sapmasını gösterir. Aynı monitörde bu dört sinyal, ikili “çalışıyor mu” yerine tam bir gözlemlenebilirlik sunar.

Dashboard da bunda yardımcı olur. Her monitör, son yanıt sürelerinin kıvılcım grafiğini gösterir — yavaşlamanın hızlı bir görsel göstergesi. Genişletilmiş görünümde 24s, 7g ve 30g ortalamaları gösterilir. Ortalama hafta hafta yükseliyorsa — bu, uyarı eşiğini aşmadan önce araştırmaya değer erken bir sinyaldir.

Sayfa türüne göre pratik eşikler

• Pazarlama açılış sayfaları: 1500ms mantıklıdır. Görsel ve takipçi scriptleriyle ağırdırlar; mutlak hızdan çok istikrar önemlidir.
• Ürün/kategori e-ticaret sayfaları: 800-1200ms. Yavaş e-ticaret, dönüşümleri öldürür; daha dar eşikler sorunları daha hızlı yakalar.
• Uygulama panelleri/dashboardlar: 500-800ms. Kullanıcılar akıcı yanıt bekler. Yavaş paneller, ürünü bozuk gösterir.
• Genel API’ler: Basit endpointler için 200-400ms, yoğun işlem gerektirenler için daha yüksek. Katmanlayın.
• Dahili mikroservis health check’leri: 50-100ms. Neredeyse anlık olmalı; yavaşlama genellikle gerçek bir sorundur.

Ne seçerseniz seçin, bir kez ayarlayıp unutmayın. Gerçekten gördüğünüz trendlere göre üç ayda bir tekrar değerlendirin. Sürekli olarak gerçekte sorun anlamına gelmeyen eşik uyarıları alıyorsanız — eşik fazla dar. Uyarı gelmeden kesinti yaşıyorsanız — eşik çok gevşek.

Uyarı yönlendirme

Eşik aşımı uyarıları aşağı/yukarı uyarılarıyla aynı kanallardan geçer: E-posta, Telegram, Slack, Discord, SMS. Aynı gece sessizliğine tabidirler. Aynı uyarı tablosuna kaydedilirler. Tek fark olay tipi (“threshold” yerine “down”) ve mesajın içeriğidir — mesajda mevcut yanıt süresi ve yapılandırılan eşik yazılıdır, böylece aşım miktarını hemen görebilirsiniz.

Yapılandırma

Herhangi bir monitörü düzenleyin. Formda "Yanıt süresi eşiği (ms)" kısmına istediğiniz değeri girin. İsteğe bağlı olarak, varsayılan üç yerine "ardışık ihlaller" sayısını toleransınıza göre ayarlayın. Kaydedin. Sonraki döngüden itibaren, her kontrol yanıt süresini eşikle karşılaştırır; belirlediğiniz ardışık ihlal sayısına ulaşıldığında bildirim alırsınız.

Sıkça Sorulan Sorular

• Hangi yanıt süresi metriği kaydediliyor?

  Time To First Byte (TTFB) — isteğin gönderilmesiyle ilk yanıt baytının alınması arasındaki milisaniye. Ayrıca, tam yanıtın indirilme süresi de ölçülür. TTFB, sunucu sağlığı için en kullanışlı tekil metriktir.

• “İyi” bir yanıt süresi nedir?

  Konuma ve içeriğe bağlıdır. CDN’li statik site için: 100ms altında harika, 300ms altında kabul edilebilir. Dinamik uygulamalar için: 500ms altında iyidir, 1000ms altında makul, 2000ms üstü yavaş görünür. Mutlak rakamlar yerine kendi geçmiş verilerinizle kıyaslayın.

• Yanıt süresi eşiği aşınca uyarı alabilir miyim?

  Evet. Her monitörde isteğe bağlı yanıt süresi eşiği bulunur. Üç ardışık kontrol eşiği aşarsa, "slow response" uyarısı alırsınız. Üç kontrol gereksinimi, tekil ağ kesintilerinden yanlış alarmı önler.

• Yanıt süresi nereden ölçülüyor?

  Dünya genelindeki 13 noktamızdan (Avrupa, Kuzey Amerika, Asya, Güney Amerika, Okyanusya). Tek bölge monitörü için en yakın bölgeden ölçülür. Çok bölgeli monitörde her bölge bağımsız ölçülür — CDN’in bölgesel problemlerini tespit etmek için yararlıdır.

• Dashboard yanıt süresi trendlerini gösteriyor mu?

  Evet — 30 günlük hareketli ortalama, günlük maksimum/minimum ve yüzdelikler (p50, p95). Kapasite planlaması için faydalı: örneğin p95 bir ayda 800ms’den 1500ms’ye çıktıysa, sunucularınız yük altında ama uptime %’ınız hâlâ 100% görünür.