Sunucu hata günlüğü: Kaybolmadan hatayı bulmak

Site 500 veriyor. Ne beyaz sayfa ne de net bir mesaj; sadece kuru ve açıklamasız bir Internal Server Error. İlk yapacağınız şey sunucu hata günlüğüne bakmak olur. Ve işte tam burada çoğu insan ilk on dakikayı boşa harcar, çünkü hangi dosyayı açacağını ve neyi arayacağını bilmez.

Bu makale tam olarak aynı yolu izliyor: günlükler nerede, binlerce satır arasında belirli bir isteği nasıl bulursunuz ve neden error_log ile access_log birbirine karıştırılmaması gereken tamamen farklı iki şeydir.

Sunucu hata günlüğü nerede ve neden bulamıyorsunuz

Paylaşımlı Linux hosting'te günlükler genellikle hesabınızın ana dizinindedir, /var/log içinde değil. SSH ile bağlandıysanız önce şunu çalıştırın:

ls -la ~/logs/ ~/public_html/error_log 2>/dev/null

cPanel ve DirectAdmin'de ana dosya genellikle ~/logs/error_log veya ~/public_html/error_log'dur. Hiçbiri yoksa, doğrudan web sunucusuna sorun:

apachectl -S 2>/dev/null | head -20
php -i | grep -i error_log

php -i çıktısının son satırı, PHP düzeyindeki gerçek error_log yolunu gösterir. Bu sayıyı not edin; kafa karışıklığının yarısı, Apache günlüğü ile PHP günlüğünün iki ayrı dosyaya yazılması ve sizin yalnızca birine bakmanızdan kaynaklanır.

Özel sunucu veya VPS'te yollar farklıdır. Apache, Debian ve Ubuntu'da /var/log/apache2/error.log dosyasına yazar, CentOS ve AlmaLinux'ta /var/log/httpd/error_log dosyasına. Nginx, PHP-FPM'in önünde oturuyorsa PHP hataları /var/log/php-fpm/www-error.log dosyasına gider ve Nginx günlüğü yalnızca web katmanı hatalarını tutar. Yani bir 500 hatası üç farklı dosyada iz bırakabilir.

error_log ve access_log arasındaki fark bir bakışta

Bu tabloyu bir kez ve sonsuza dek ezberleyin, çünkü çoğu zaman insanlar saatlerce access_log okur ve hata arar:

access_log'dan örnek bir satır:

185.55.12.9 - - [14/Feb/2025:09:41:22 +0330] "POST /cart/checkout HTTP/1.1" 500 312 "-" "Mozilla/5.0"

Bu satır, bir kullanıcının saat 09:41'de /cart/checkout yolunda 500 hatası aldığını söylüyor. Ama nedenini söylemiyor. "Neden" için aynı anı error_log içinde aramalısınız. İşte burada hata yapılıyor: 500 kodunu access_log'da görüyorlar, günlüğü bulduklarını sanıyorlar ve sonra belki hata mesajı görünür diye sayfayı on kez yeniliyorlar. Hata mesajı orada değil. Başka bir dosyada.

Sunucu hata günlüğünde belirli bir isteği nasıl buluruz

Aynı /cart/checkout hatasına sahip olduğunuzu ve arkasında ne olduğunu bilmek istediğinizi varsayalım. Önce zaman aralığını access_log'dan alın, sonra error_log içinde aynı aralığı arayın:

grep "14/Feb/2025:09:4" ~/logs/access_log | grep " 500 "
grep -A 5 "09:41:2" ~/logs/error_log

-A 5 bayrağı her eşleşmeden sonraki beş satırı da gösterir, çünkü PHP hatası genellikle çok satırlıdır ve stack trace ilk satırın altında gelir. Yalnızca ilk satırı görürseniz, genellikle elinize bir şey geçmez.

Günlük dosyası büyük olduğunda, grep tüm dosya üzerinde yavaşlar. Günlük döndürülmüşse (rotated) ve error_log.1 ile error_log.2.gz dosyalarınız varsa, doğrudan sıkıştırılmış sürümde arayın:

zgrep -i "fatal error" ~/logs/error_log.2.gz

Hatayı ne zaman oluştuğunu bilmediğinizde günlüğü canlı görmek için:

tail -f ~/logs/error_log | grep -v "favicon"

O grep -v'yi hafife almayın. Yoğun trafikli sitelerde, favicon.ico ve bot istekleriyle ilgili satırlar çıktının yarısından fazlasını doldurabilir ve sizi gerçek hatadan uzaklaştırabilir.

Hata düzeyini okumak: gerçekten önemli olan şey

PHP günlüğünde her satır bir düzeyle başlar. Bunları birbirinden ayırt etmelisiniz:

• Fatal error: Betik tam orada durmuştur. Bu neredeyse her zaman 500'e neden olur ve her şeyden önce bunu aramalısınız.
• Parse error: Koddaki sözdizimi hatası. Genellikle bir düzenlemeden veya eksik dosya yüklemesinden sonra ortaya çıkar.
• Warning: Betik devam etmiştir, ama bir şey yerinde değildi. include(): Failed opening gibi.
• Notice ve Deprecated: Yeni PHP sürümlerinde çoğalırlar ve tek başlarına siteyi düşürmezler.

Sık gördüğüm gerçek bir örnek:

[14-Feb-2025 09:41:22 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/user/public_html/wp-includes/wp-db.php on line 2056

134217728 sayısı 128 megabayttır. Yani memory_limit 128M'deydi ve betiğin yeri yoktu. Hızlı çözüm, bu değeri php.ini veya .user.ini içinde yükseltmektir:

memory_limit = 256M

Ama burada dürüstçe söylemem gereken bir tuzak var: memory_limit'i yükseltmek sorunu gizler, çözmez. Bir eklenti her istekte 200 megabayt yiyorsa, 256M ile yalnızca biraz daha geç düşer ve yoğun trafikli bir sunucuda tüm sunucunun bellek tüketimini artırır. Bellek hatası belirli bir yolda tekrarlanıyorsa, sorun o eklenti veya sorgudadır, memory_limit sayısında değil.

Günlükte olmayan ve başka yerde aramanız gereken hatalar

Bazen site 500 verir ama error_log tamamen boştur. Bu durumun birkaç belirli nedeni vardır:

1. Hata PHP düzeyinde değil, web sunucusu düzeyinde oluşmuştur. Örneğin .htaccess bozuktur. Bu durumda PHP günlüğüne değil, Apache günlüğüne bakın.
2. Hata DNS veya bağlantı düzeyindedir ve sunucunuza hiç ulaşmamıştır. Bu durum için DNS ve ağ kontrolü doğru başlangıç noktasıdır.
3. Günlükleme kapalıdır. Hem display_errors hem log_errors kapalıysa, hiçbir yere bir şey yazılmaz.

Üçüncü durum için, bu iki satırı php.ini veya .user.ini içine koyun:

log_errors = On
error_log = /home/user/logs/php_error.log

Ve sonra web sunucusunu yeniden başlatın. PHP-FPM'de, php.ini değişikliği servis yeniden başlatılmadan uygulanmaz ve bu, ayarın işe yaramadığını düşünmenize neden olur.

Hata kodun kendisinden olmadığında

Bazen günlük hatalarla doludur ama site sağlıklı çalışır. Örneğin PHP 8.2'de yüzlerce Deprecated: Creation of dynamic property satırı. Bunlar göz ardı edilmemelidir, ama birinci öncelik de değildir. Önceliği Fatal error ve 500 kodlarına verin.

Site yavaşsa ama günlükte hata yoksa, sorun başka bir yerdedir. O durumda doğru yol, hata değil performans sorun gidermedir; Site neden yavaş? Yavaş site sorun giderme tam kılavuzu tam olarak bu yolu kapsar ve TTFB ile sorgu süresinden başlar.

Pratik bir not: canlı sunucuda herhangi bir değişiklik yapmadan önce ayrı bir ortam oluşturun. Site için staging ortamı oluşturma kılavuzu, ana siteye dokunmadan hatayı nasıl yeniden üreteceğinizi gösterir. Bu, uzun vadede size en çok zaman kazandıran şeydir.

İşi kısaltan araçlar

Hataları türe göre hızlıca saymak için:

grep -o "PHP Fatal error" ~/logs/error_log | wc -l
awk '{print $5}' ~/logs/access_log | sort | uniq -c | sort -rn | head

İkinci satır durum kodlarını sayar ve isteklerin yüzde kaçının 500 olduğunu gösterir. 500 sayısı toplam isteklere göre yükselirse, sorun artık tek bir kullanıcı değildir.

Paylaşımlı hosting'deyseniz ve SSH erişiminiz yoksa, genellikle panelden günlükleri indirebilirsiniz. Linux hosting'te bu dosyalar aynı panelden görüntülenebilir ve indirilebilir, root erişimine gerek yoktur. Başlıkları ve yönlendirmeleri kontrol etmek gibi daha hafif işler için, ücretsiz web yöneticisi araçları terminal açmaktan daha hızlı yanıt verir.

Ve günlüklerin boyutu birkaç gigabaytı geçerse ve paylaşımlı sunucuda grep yavaşlarsa, özel sunucu düşünmenin zamanı gelmiştir; işlem gücü için değil, günlük döndürme ve uzun süreli saklama üzerindeki kontrol için.

Sık sorulan sorular

Paylaşımlı hosting'te sunucu hata günlüğü nerede?

Çoğu Linux panelinde, error_log dosyası hesabınızın kökündeki logs klasöründe bulunur, yani ~/logs/error_log gibi bir yolda. Orada yoksa, tam yolu php -i | grep error_log ile bulun, çünkü PHP günlüğü ile web sunucusu günlüğü iki ayrı dosyadır.

Site neden 500 hatası veriyor ama error_log boş?

Genellikle hata PHP düzeyinde değil, web sunucusu düzeyinde oluşmuştur; örneğin .htaccess içinde geçersiz bir satır. Diğer neden, log_errors'ın kapalı olması ve hiçbir yere yazılmamasıdır. Her iki durumda da Apache veya Nginx günlüğünü ayrıca incelemelisiniz.

Hangi isteğin hataya neden olduğunu nasıl anlarım?

Önce isteğin zamanını ve yolunu access_log'dan alın, sonra aynı zaman aralığını error_log içinde arayın. error_log üzerinde grep -A 5 komutu, hatadan sonraki birkaç satırı da görmenize yardımcı olur, çünkü stack trace genellikle çok satırlıdır.

memory_limit'i yükseltmek sorunu çözer mi?

Yalnızca belirtiyi erteler. Bir eklenti veya sorgu her istekte çok fazla bellek yiyorsa, memory_limit'i yükseltmek daha geç düşmesine neden olur, düzelmesine değil. Kökü o eklenti veya sorguda bulun.

Sonraki adım basit: şimdi bir kez error_log üzerinde tail -f çalıştırın ve siteyi tarayıcıda açın. Bir hata oluşuyorsa, tam o anda gözünüzün önünde belirir. Belirmezse, hata başka bir yerdedir ve web sunucusu günlüğüne bakmanız gerekir.