- Konu sahibi
- #1
Erişim logu hangi isteğin ne zaman, hangi IP’den, hangi URL’ye ve hangi HTTP durum koduyla geldiğini gösterir; hata logu ise sunucunun bu isteği işlerken neden uyarı veya hata ürettiğini açıklar. Bir sorunu anlamak için önce erişim logundan başarısız isteği belirleyin, ardından aynı zaman aralığında hata logunda ilgili istemci IP’si, istek yolu, işlem kimliği veya upstream bilgisiyle eşleştirin.
Erişim logu alanları yapılandırmaya bağlıdır. Yaygın combined biçiminde zaman, IP, istek satırı, durum ve boyut bulunur; süre/request ID/host/upstream zamanı ayrıca eklenebilir. Örneğin
Hata logu; yapılandırma hatası, dosya izin problemi, uygulama istisnası, bağlantı reddi, zaman aşımı ve upstream yanıtı gibi ayrıntıları içerir. Aynı hata birçok isteği etkileyebileceği için yalnızca hata loguna bakmak, hangi URL’nin veya hangi istemcinin soruna neden olduğunu ayırt etmeyi zorlaştırabilir.
Varsayımsal olarak erişim logunda şu kayıt bulunsun:
Aynı saniyedeki hata kaydı şöyleyse:
Sonuç, istemcinin
Log dosyalarının adları ve biçimleri sunucu yazılımına, dağıtıma ve yapılandırmaya göre değişir. Bu nedenle aşağıdaki arama örneği yalnızca metin tabanlı loglar içindir:
İlk komut yalnız yukarıdaki standart combined alan dizilimi içindir: $4 saat alanı, $9 durum kodudur. JSON/özel formatta aynı alan numaralarını kullanmayın. Bu komut5xx erişim kayıtlarını, ikinci komut aynı dakikadaki hata kayıtlarını seçer. Gerçek sistemde dosya yollarını kendi yapılandırmanızdaki yollarla değiştirin. Çıktı boşsa bu, sorunun olmadığı anlamına gelmez; saat biçimi, döndürülmüş log dosyası veya farklı bir kayıt seviyesi kullanılıyor olabilir.
Aynı saniye ve yol tek başına aynı istek kanıtı değildir; yüksek trafikte request ID ve upstream bilgisiyle eşleştirin. Nginx’de access kaydı isteğin tamamlanmasına yakın yazılırken hata satırı daha erken oluşabilir; tamponlama da görünürlüğü geciktirebilir. Her4xx veya uygulama5xx için webserver error logunda satır bulunması zorunlu değildir.
Tablodaki eşleştirmeler başlangıç noktasıdır; aynı durum kodu farklı nedenlerden oluşabilir. Özellikle
En yaygın hata, yalnızca hata logunda “error” kelimesini arayıp erişim kaydındaki URL ve durum kodunu doğrulamamaktır. Bir diğer hata, saat dilimini karıştırarak ilgisiz kayıtları aynı olay sanmaktır. Log döndürme nedeniyle olayın eski dosyada bulunabileceği de unutulmamalıdır. Son olarak, loglarda kişisel veri veya oturum bilgisi bulunabileceğinden tüm dosyayı paylaşmak yerine gerekli satırları maskeleyerek kullanın.
İstemci tarafında tarayıcı konsolu, uygulama logu ve yanıt içeriğini kontrol edin. 200 kodu, sunucunun HTTP yanıtı verdiğini gösterir; uygulamanın içerik içinde hata mesajı döndürmesini veya istemci tarafı kodun başarısız olmasını tek başına dışlamaz.
Önce olay zincirinin ilk görünen nedenini inceleyin. Bağlantı reddi veya yapılandırma hatası gibi erken bir kayıt, ardından gelen timeout ve 5xx kayıtlarının asıl kaynağı olabilir.
İki log türünün görevi
Erişim logu alanları yapılandırmaya bağlıdır. Yaygın combined biçiminde zaman, IP, istek satırı, durum ve boyut bulunur; süre/request ID/host/upstream zamanı ayrıca eklenebilir. Örneğin
500 uygulama veya sunucu tarafında işlem hatasına, 404 bulunamayan kaynağa, 502 veya 504 ise çoğunlukla proxy ile arka uç uygulama arasındaki soruna işaret eder. Durum kodu tek başına kesin neden değildir; hata logu ile doğrulanmalıdır.Hata logu; yapılandırma hatası, dosya izin problemi, uygulama istisnası, bağlantı reddi, zaman aşımı ve upstream yanıtı gibi ayrıntıları içerir. Aynı hata birçok isteği etkileyebileceği için yalnızca hata loguna bakmak, hangi URL’nin veya hangi istemcinin soruna neden olduğunu ayırt etmeyi zorlaştırabilir.
Somut bir eşleştirme örneği
Varsayımsal olarak erişim logunda şu kayıt bulunsun:
Kod:
203.0.113.24 - - [07/Nov/2026:14:22:18 +0000] "GET /odeme HTTP/1.1" 504 173 "-" "Mozilla/5.0"
Aynı saniyedeki hata kaydı şöyleyse:
Kod:
2026/11/07 14:22:18 [error] upstream timed out while reading response header from upstream, request: "GET /odeme HTTP/1.1", upstream: "http://127.0.0.1:8080/odeme"
Sonuç, istemcinin
/odeme isteğinde hata aldığı ve web sunucusunun arka uç uygulamasından zamanında başlık alamadığıdır. Sonraki adım web sunucusunu rastgele yeniden başlatmak değil, 127.0.0.1:8080 üzerindeki uygulamanın aynı zaman aralığında yavaşlayıp yavaşlamadığını veya hata üretip üretmediğini incelemektir.Uygulanabilir inceleme yöntemi
- Sorunun zaman aralığını ve saat dilimini netleştirin. Sunucu saatinin UTC mi yoksa yerel saat mi olduğunu kontrol etmeden log satırlarını karşılaştırmayın.
- Erişim logunda ilgili URL’yi, durum kodunu veya istemci IP’sini arayın. Aynı URL’nin başarılı ve başarısız isteklerini karşılaştırarak sorunun sürekli mi, aralıklı mı olduğunu belirleyin.
- Başarısız satırın zamanından hemen önceki ve sonraki hata loglarını okuyun. Yalnızca tek satıra değil, aynı olayın devamındaki zincire bakın; örneğin bağlantı reddi, yeniden deneme ve zaman aşımı birlikte görülebilir.
- Erişim kaydındaki istek yolu, HTTP metodu, durum kodu ve varsa istek kimliğini hata kaydıyla eşleştirin. İstek kimliği yoksa zaman aralığı, IP ve upstream adresini birlikte kullanın.
- Sorunun katmanını ayırın: statik dosya için dosya yolu ve izinleri, PHP veya başka bir uygulama için uygulama logu ve işlem durumu, proxy hatası için upstream bağlantısı ve zaman aşımı incelenmelidir.
- Düzeltmeden sonra aynı isteği kontrollü biçimde yeniden deneyin. Erişim logunda beklenen durum kodunu, hata logunda yeni hata oluşmadığını ve yanıt süresinin normale döndüğünü birlikte doğrulayın.
Log dosyalarının adları ve biçimleri sunucu yazılımına, dağıtıma ve yapılandırmaya göre değişir. Bu nedenle aşağıdaki arama örneği yalnızca metin tabanlı loglar içindir:
Kod:
awk '$4 ~ /:14:22:/ && $9 ~ /^5[0-9][0-9]$/ {print}' /var/log/webserver/access.log
grep '14:22' /var/log/webserver/error.log
İlk komut yalnız yukarıdaki standart combined alan dizilimi içindir: $4 saat alanı, $9 durum kodudur. JSON/özel formatta aynı alan numaralarını kullanmayın. Bu komut5xx erişim kayıtlarını, ikinci komut aynı dakikadaki hata kayıtlarını seçer. Gerçek sistemde dosya yollarını kendi yapılandırmanızdaki yollarla değiştirin. Çıktı boşsa bu, sorunun olmadığı anlamına gelmez; saat biçimi, döndürülmüş log dosyası veya farklı bir kayıt seviyesi kullanılıyor olabilir.
Aynı saniye ve yol tek başına aynı istek kanıtı değildir; yüksek trafikte request ID ve upstream bilgisiyle eşleştirin. Nginx’de access kaydı isteğin tamamlanmasına yakın yazılırken hata satırı daha erken oluşabilir; tamponlama da görünürlüğü geciktirebilir. Her4xx veya uygulama5xx için webserver error logunda satır bulunması zorunlu değildir.
Kayıtları yorumlama karar tablosu
| Erişim sonucu | Hata logunda aranacak belirti | İlk sonraki adım |
|---|---|---|
| 404 | Dosya veya rota bulunamadı | URL yönlendirmesini, uygulama rotasını ve dosya yolunu kontrol edin |
| 403 | İzin, erişim kuralı veya kimlik doğrulama reddi | İlgili dizin, dosya ve sunucu erişim kurallarını karşılaştırın |
| 500 | Uygulama istisnası, yapılandırma veya çalışma zamanı hatası | Uygulama logunu aynı zaman aralığında inceleyin |
| 502/504 | Upstream bağlantı reddi veya zaman aşımı | Arka uç işlemini, dinlediği adresi ve yanıt süresini kontrol edin |
Tablodaki eşleştirmeler başlangıç noktasıdır; aynı durum kodu farklı nedenlerden oluşabilir. Özellikle
500 ve 502 için kesin teşhis, ilgili hata veya uygulama kaydı görülmeden konulmaz.Sık yapılan hatalar
En yaygın hata, yalnızca hata logunda “error” kelimesini arayıp erişim kaydındaki URL ve durum kodunu doğrulamamaktır. Bir diğer hata, saat dilimini karıştırarak ilgisiz kayıtları aynı olay sanmaktır. Log döndürme nedeniyle olayın eski dosyada bulunabileceği de unutulmamalıdır. Son olarak, loglarda kişisel veri veya oturum bilgisi bulunabileceğinden tüm dosyayı paylaşmak yerine gerekli satırları maskeleyerek kullanın.
Kaynaklar
Sık sorulan sorular
Erişim logunda 200 görünüyor ama kullanıcı hata bildiriyor; neye bakmalıyım?
İstemci tarafında tarayıcı konsolu, uygulama logu ve yanıt içeriğini kontrol edin. 200 kodu, sunucunun HTTP yanıtı verdiğini gösterir; uygulamanın içerik içinde hata mesajı döndürmesini veya istemci tarafı kodun başarısız olmasını tek başına dışlamaz.
Aynı saniyede çok sayıda hata varsa hangisini önce incelemeliyim?
Önce olay zincirinin ilk görünen nedenini inceleyin. Bağlantı reddi veya yapılandırma hatası gibi erken bir kayıt, ardından gelen timeout ve 5xx kayıtlarının asıl kaynağı olabilir.