Sunucu Yanıt Süresi İzleme Kurulumu

Sunucu yanıt süresi, bir performans sorununun en erken ve en dürüst habercisidir. Kullanıcı henüz şikâyet etmeden, hız testi hâlâ yeşil görünürken, sunucunun ilk baytı üretme süresi çoktan tırmanmaya başlamıştır. Sorun şu ki bu değeri ölçmüyorsan tırmanışı göremezsin; olayı ancak sayfa tamamen açılmaz hâle geldiğinde fark edersin ve o noktada elinde geçmiş veri olmadığı için "ne zaman başladı, o gün ne değişti" sorularını da cevaplayamazsın.

Bu rehberde harici bir servise para ödemeden, kendi sunucunda çalışan bir yanıt süresi izleme düzeni kuracağız. Sırasıyla şunları yapacağız: web sunucusu günlüğüne süre alanı eklemek, günlükten yavaş istekleri ve yol bazında dağılımı çıkarmak, PHP ve veritabanı katmanında yavaş istek günlüklerini açmak, dışarıdan düzenli prob atan bir kontrol kurmak ve son olarak gerçekten müdahale ettiren, sürekli ötmeyen bir alarm eşiği belirlemek.

Yanıt Süresi Tam Olarak Neyi Kapsar#

"Yanıt süresi" kelimesi bulunduğun katmana göre farklı şey ifade eder ve bu karışıklık teşhiste ciddi zaman kaybettirir. Üç ayrı sayıyı birbirinden ayırman gerekir.

Aynı olay için bu üç sayı çok farklı çıkabilir. Uygulama 90 ms'de işini bitirmişken, sunucu yanıt süresi 3 saniye görünüyorsa fark genellikle yavaş bir istemciye büyük bir yanıt gönderilmesinden ya da yukarı akış (upstream) beklemesinden gelir. TTFB 900 ms iken sunucu yanıt süresi 120 ms ise aradaki 780 ms ağ ve TLS maliyetidir; sunucuyu büyütmek o farkı hiç değiştirmez.

Bu üç ölçümü birlikte topladığında elinde bir fark analizi olur ve sorunun hangi aralıkta doğduğunu tek bakışta görürsün. Katman ayrımının teşhisteki genel karşılığı için yavaş site teşhis akışı yazısındaki eleme adımlarını da yanına al.

Web Sunucusu Günlüğüne Süreyi Eklemek#

Varsayılan günlük biçimleri süre bilgisi içermez; bu yüzden çoğu sunucuda geçmişe dönük hiçbir performans verisi yoktur. İlk iş bunu düzeltmektir ve maliyeti neredeyse sıfırdır.

nginx tarafında log_format içine iki değişken eklemen yeterli: $request_time toplam istek süresini, $upstream_response_time ise yukarı akıştan (PHP-FPM veya proxy) gelen süreyi verir. İkisinin farkı, isteği istemciye teslim etme süresini gösterir.

# /etc/nginx/nginx.conf - http bloğu içine
log_format sureli '$remote_addr - [$time_local] "$request" '
                  '$status $body_bytes_sent '
                  'rt=$request_time urt=$upstream_response_time '
                  'cache=$upstream_cache_status "$http_user_agent"';

# server bloğunda bu biçimi kullan
access_log /var/log/nginx/firmaniz-access.log sureli;

Apache kullanıyorsan %D mikrosaniye, %T saniye cinsinden süre verir:

# httpd.conf veya vhost içinde
LogFormat "%h %l %u %t \"%r\" %>s %b %D \"%{User-Agent}i\"" sureli
CustomLog /var/log/apache2/firmaniz-access.log sureli

Değişikliği uygulamadan önce yapılandırmayı mutlaka doğrula, yoksa yeniden yükleme sırasında sunucuyu durdurabilirsin:

nginx -t && systemctl reload nginx
# Apache için:
apachectl configtest && systemctl reload apache2

cache=$upstream_cache_status alanını eklememin özel bir sebebi var: yavaş istekleri incelerken bunların önbellekten mi geldiğini yoksa uygulamaya kadar mı indiğini görmek, teşhisin yarısını halleder. MISS yoğunluğu yüksekse sorun uygulamada değil önbellek yapılandırmasındadır; o durumda nginx FastCGI cache yapılandırması yazısındaki ayarları gözden geçir.

Günlükten Yavaş İstekleri Çıkarmak#

Süre alanı biriktikçe elinde ücretsiz ve son derece değerli bir veri seti oluşur. Onu okumak için ek yazılıma ihtiyacın yok; awk ile birkaç satırda anlamlı özetler çıkarırsın. Aşağıdaki komutlarda süre alanının rt= ile başladığını varsayıyorum.

LOG=/var/log/nginx/firmaniz-access.log

# 1) En yavaş 20 istek
grep -o 'rt=[0-9.]* .*"[A-Z]* [^ ]*' "$LOG" | sort -t= -k2 -rn | head -20

# 2) Yol bazında ortalama süre ve istek sayısı - en pahalı uç noktalar
awk '{
  for (i=1; i<=NF; i++) if ($i ~ /^rt=/) { sub("rt=","",$i); sure=$i }
  yol=$7
  topla[yol]+=sure; adet[yol]++
} END {
  for (y in topla) printf "%8.3f  %7d  %s\n", topla[y]/adet[y], adet[y], y
}' "$LOG" | sort -rn | head -20

# 3) Saatlik p95 - hangi saatte bozuluyor
awk '{
  for (i=1; i<=NF; i++) if ($i ~ /^rt=/) { sub("rt=","",$i); sure=$i }
  split($4, t, ":"); saat=t[2]
  print saat, sure
}' "$LOG" | sort -k1,1 -k2,2n | awk '
  { dizi[$1][++n[$1]]=$2 }
  END { for (s in n) { idx=int(n[s]*0.95); if (idx<1) idx=1; printf "%s:00  p95=%.3f  n=%d\n", s, dizi[s][idx], n[s] } }
' | sort

İkinci komut çoğu zaman tek başına sorunu bulur: listenin başındaki yol genellikle indekssiz bir sorgu çalıştıran ya da her istekte harici bir API'ye giden bir uç noktadır. Üçüncü komut ise zamana bağlı bozulmayı gösterir; belirli bir saatte p95 tırmanıyorsa neden büyük olasılıkla zamanlanmış bir görevdir ve site belirli saatlerde yavaşlıyor yazısındaki nedenler listesine bakman gerekir.

Bu özetleri elle çalıştırmak yerine günlük bir işe bağla; her sabah bir dosyaya yazdır, haftada bir göz at. Ölçmenin değeri düzenli bakıldığında ortaya çıkar.

PHP ve Veritabanı Katmanında Yavaş Günlükler#

Web sunucusu günlüğü sana hangi isteğin yavaş olduğunu söyler ama nedenini söylemez. Nedeni bulmak için bir alt katmana inersin.

PHP-FPM'in yavaş istek günlüğü, belirlediğin süreyi aşan isteklerin o anki çağrı yığınını (stack trace) diske yazar. Yani hangi dosyanın hangi satırında beklendiğini doğrudan görürsün:

; /etc/php/8.2/fpm/pool.d/www.conf
slowlog = /var/log/php-fpm-slow.log
request_slowlog_timeout = 3s

; Havuz doygunluğunu izlemek için durum sayfasını aç
pm.status_path = /fpm-status

Havuz durumunu okumak, "sunucu neden yavaş" sorusunun sık atlanan bir cevabını verir: eğer listen queue sürekli sıfırdan büyükse istekler işlenmeyi beklerken kuyrukta duruyordur ve tek tek isteklerin süresi normal görünse bile kullanıcı bekliyordur.

# FPM havuz durumunu oku - active/idle süreç ve kuyruk
curl -s "http://127.0.0.1/fpm-status?full" | head -20

Veritabanı tarafında yavaş sorgu günlüğü aynı işi yapar. Eşiği önce 1 saniyeye koy, gürültü azalınca düşür:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL long_query_time = 1;
-- İndeks kullanmayan sorguları da yakala
SET GLOBAL log_queries_not_using_indexes = 'ON';

Bu ayarları kalıcı yapmak için sunucu yapılandırma dosyasına da yazmayı unutma; SET GLOBAL ile yapılanlar yeniden başlatmada kaybolur. Ayrıca log_queries_not_using_indexes seçeneğini uzun süre açık bırakma, küçük tablolarda bile satır ürettiği için günlük dosyası hızla büyür.

Dışarıdan Prob Atan Kontrol Kurmak#

Sunucu içi ölçümler önemlidir ama sunucu tamamen cevap veremez hâle geldiğinde susarlar. Bu yüzden dışarıdan bakan bağımsız bir prob şarttır ve bunu bir servise ödeme yapmadan da kurabilirsin: başka bir sunucuda, hatta küçük bir sanal makinede çalışan bir zamanlanmış görev yeter.

#!/bin/bash
# /usr/local/bin/yanit-probu.sh - başka bir sunucuda çalışır
HEDEF="https://firmaniz.com/saglik.php"
CIKTI="/var/log/yanit-suresi.log"
ESIK="1.5"   # saniye

OKUMA=$(curl -o /dev/null -s -w "%{http_code} %{time_starttransfer} %{time_total}" \
        --max-time 10 "$HEDEF")
KOD=$(echo "$OKUMA" | cut -d' ' -f1)
TTFB=$(echo "$OKUMA" | cut -d' ' -f2)
TOPLAM=$(echo "$OKUMA" | cut -d' ' -f3)

echo "$(date -Is) kod=$KOD ttfb=$TTFB toplam=$TOPLAM" >> "$CIKTI"

# Eşik aşıldıysa ya da kod 200 değilse uyar
if [ "$KOD" != "200" ] || awk "BEGIN{exit !($TTFB > $ESIK)}"; then
  echo "UYARI $(date -Is) kod=$KOD ttfb=$TTFB" >> "$CIKTI"
  # Buraya kendi bildirim komutunu ekle (mail, webhook, vb.)
fi

Görevi dakikada bir çalıştır:

# crontab -e
* * * * * /usr/local/bin/yanit-probu.sh

Probun hedefi olarak ana sayfayı değil, veritabanına gerçekten dokunan bir sağlık ucunu seç. Ana sayfa tam önbellekliyse veritabanı çökmüşken bile 200 döner ve izlemen sana yanlış bir güven verir. Daha kurumsal bir kurulum istiyorsan aynı işi blackbox_exporter ve Prometheus ile yapabilirsin; araç seçenekleri için performans izleme araçları karşılaştırması yazısındaki katman tablosuna bak.

Doğru Alarm Eşiğini Belirlemek#

İzlemenin en zor kısmı ölçmek değil, ne zaman rahatsız edileceğine karar vermektir. Çok hassas bir eşik iki hafta içinde sessize alınır; çok gevşek bir eşik ise olay bittikten sonra tetiklenir.

Pratikte işe yarayan yöntem şudur: bir hafta veri topla, normal dağılımı çıkar ve eşiği p95'in biraz üstüne koy. Sonra mutlaka bir süre koşulu ekle; tek bir yavaş istek olay değildir, beş dakika süren bir bozulma olaydır.

Eşikleri sabitlerken sunucunun kaynak durumunu da yanına koy. Yanıt süresi tırmanışının çoğu, yük ortalamasının çekirdek sayısını aşmasıyla aynı ana denk gelir; bu ilişkiyi kurmak için load average nasıl okunur yazısındaki normalize yük hesabını kullan. Bot kaynaklı ani yük artışları da aynı desende görünür ve ayırt edilmesi gerekir; günlükteki kullanıcı aracısı alanı bu ayrımı yapmanı sağlar.

Sık Yapılan Hatalar#

Günlüğe süre alanı eklemeyi unutmak. En yaygın eksik budur. Sorun çıktığında geçmiş veri olmadığı için "ne zaman başladı" sorusuna cevap veremezsin. Bu ayarı sorun çıkmadan önce yap; maliyeti yok, karşılığı büyük.

Günlük döndürmeyi ayarlamamak. Süre alanı eklenmiş bir erişim günlüğü trafikle birlikte hızla büyür. logrotate kuralını kontrol et; dolu bir disk, ölçmeye çalıştığın yavaşlığın ta kendisine dönüşür.

Ortalamaya bakmak. Ortalama yanıt süresi neredeyse hiçbir zaman bozulmaz çünkü hızlı statik istekler sayıyı aşağı çeker. p95 ve p99'a bak; kullanıcının hissettiği kuyruk oradadır.

Probu izlenen sunucunun üzerinde çalıştırmak. Sunucu çökerse prob da çöker ve hiç bildirim alamazsın. Dış prob mutlaka bağımsız bir makinede olmalı.

Yavaş sorgu günlüğünü açık unutmak. Düşük eşikle açılmış bir günlük, birkaç günde onlarca gigabayt üretebilir. Teşhis bittiğinde eşiği yükselt ya da kapat.

Sıkça Sorulan Sorular#

İyi bir sunucu yanıt süresi kaç milisaniyedir#

Dinamik olarak üretilen bir sayfa için 200–400 ms arası iyi kabul edilir, 800 ms üstü incelenmesi gereken bir değerdir. Tam önbellekten dönen statik bir yanıt 100 ms'nin altında olmalıdır. Bu sayıları yorumlarken ölçümü nerede yaptığını hesaba kat: sunucunun kendi üzerinden yapılan ölçüm ağ payını içermez, dışarıdan yapılan ölçüm ise mesafeye bağlı sabit bir gecikme taşır.

request_time ile upstream_response_time farkı nedir#

upstream_response_time yalnızca PHP-FPM ya da proxy'lediğin uygulamanın yanıt üretme süresini gösterir. request_time ise isteğin okunmasından yanıtın istemciye tamamen gönderilmesine kadar geçen tüm süreyi kapsar. İkisi arasındaki büyük fark genellikle yavaş bir istemciye büyük bir dosya gönderildiğine ya da ağ tarafında bir sorun olduğuna işaret eder; uygulama katmanında arama yapmadan önce bu farka bak.

Günlük dosyaları diskimi doldurur mu#

Süre alanı eklemek satır başına yalnızca birkaç bayt ekler, asıl risk trafiğin kendisidir. Günde yüz binlerce isteği olan bir sitede erişim günlüğü günlük yüzlerce megabayta ulaşabilir. Çözüm logrotate ile günlük döndürme, sıkıştırma ve 14–30 günlük saklama süresidir. Statik dosya isteklerini ayrı bir günlüğe yazmak ya da hiç kaydetmemek de hacmi ciddi biçimde düşürür.

Yanıt süresi izlemek için ücretli servis gerekir mi#

Gerekmez. Bu yazıdaki kurulum tamamen ücretsiz araçlarla çalışır: web sunucusu günlüğü, awk, curl ve zamanlanmış görevler. Ücretli servislerin kattığı asıl değer çok konumlu prob, hazır panolar ve bildirim entegrasyonlarıdır. Küçük ve orta ölçekli bir sitede kendi kurduğun düzen fazlasıyla yeterlidir; ölçek büyüdükçe merkezî bir çözüm işini kolaylaştırır.

Yanıt süresi aniden yükseldi, önce neye bakmalıyım#

Sırayla üç şeye bak: sistem kaynakları (yük ortalaması, bellek, disk doluluğu ve disk beklemesi), önbellek isabet oranı ve erişim günlüğündeki trafik hacmi. Trafikte ani bir artış varsa ve bu artış kullanıcı aracısı alanında bot imzaları taşıyorsa neden tarama dalgasıdır. Trafik normalse ve önbellek isabet oranı düşmüşse yapılandırma değişmiş olabilir. Her ikisi de normalse veritabanı tarafına inip o anda çalışan sorgulara bak.

Bu izlemeyi paylaşımlı hostingde kurabilir miyim#

Kısmen. Paylaşımlı hostingde nginx yapılandırmasına ve PHP-FPM havuz ayarlarına erişemezsin, bu yüzden günlük biçimini değiştiremezsin. Ancak dış prob kısmını başka bir yerden çalıştırabilir, hosting panelindeki kaynak kullanım grafiklerini takip edebilir ve uygulama içinde kendi süre ölçümünü yapıp bir dosyaya yazabilirsin. Tam kontrol istiyorsan sanal ya da özel bir sunucuya geçmen gerekir.

Kapanış#

Yanıt süresi izleme, kurulumu bir saat süren ama karşılığını ilk olayda fazlasıyla veren bir yatırımdır. Aklında kalması gereken dört alışkanlık şu: günlük biçimine süre alanını sorun çıkmadan ekle, ortalamaya değil p95'e bak, dış probu izlenen sunucunun dışında çalıştır ve her alarma bir süre koşulu koyarak gürültüyü kes. Bunları kurduğunda bir sonraki yavaşlık şikâyetinde elinde tahmin değil grafik olur.

Bu kurulumun tamamı yapılandırma dosyalarına ve sistem servislerine erişim gerektirir; tam root yetkisi için VDS veya esnek ölçeklenen bulut sunucu paketlerimizi inceleyebilirsin. İzleme, alarm ve günlük yönetimini kendin üstlenmek istemiyorsan sunucu yönetimi hizmetimiz bu düzeni kurup bakımını üstlenir. Basit bir kontrol için hızlı bir başlangıç arıyorsan uptime SLA hesaplayıcı aracımızla hedef erişilebilirlik oranının pratikte kaç dakikalık kesintiye denk geldiğini görebilirsin.