Gerçek nedeni bulmak için hata günlüklerini okuma

Linux sunucularda hata günlüklerini okumak için adım adım kılavuz: günlük dosyalarını bulmaktan hata mesajlarını gerçek nedene çevirmeye kadar. Web sitesi yöneticileri ve geliştiriciler için uygundur.

6 dk Güncellendi 5 Aug 2026

Web siteniz çöktüğünde veya 500 hatası verdiğinde, başvurmanız gereken ilk yer hata günlüğüdür. Ancak sorun şu: birçok web sitesi yöneticisi günlükleri tam olarak nerede bulacağını veya Connection refused gibi belirsiz bir hata mesajını gerçek nedene nasıl çevireceğini bilmiyor. Bu makalede, Linux sunucularda hata günlüğünü nasıl bulacağınızı, yapısını nasıl okuyacağınızı ve en yaygın hataları çözüme nasıl dönüştüreceğinizi öğreneceksiniz.

1. Hata Günlüğü Nerede? Linux Sunucuda Standart Yollar

Hizmet türüne bağlı olarak, hata günlüğü farklı yollarda saklanır. En yaygın yerler şunlardır:

  • Sistem günlükleri: /var/log/syslog veya /var/log/messages (Linux dağıtımına bağlı olarak)
  • Apache web sunucusu günlüğü: /var/log/apache2/error.log (Ubuntu/Debian'da) veya /var/log/httpd/error_log (CentOS/RHEL'de)
  • Nginx web sunucusu günlüğü: /var/log/nginx/error.log
  • MySQL/MariaDB günlüğü: /var/log/mysql/error.log
  • PHP-FPM günlüğü: /var/log/php-fpm/error.log veya /var/log/php7.4-fpm.log

Bu dosyalara erişmek için genellikle root veya sudo yetkisine ihtiyacınız vardır. Aşağıdaki komutla hata günlüğünün son 50 satırını görebilirsiniz:

sudo tail -n 50 /var/log/apache2/error.log

1.1. Belirli Bir Hizmetin Günlüklerini Nasıl Buluruz?

Postfix veya Dovecot gibi belirli bir hizmetiniz varsa, günlük yolu farklı olabilir. En iyi yöntem, systemd sistemlerinde journalctl komutunu kullanmaktır:

sudo journalctl -u nginx.service --since "1 hour ago"

Bu komut, Nginx hizmetinin son bir saat içindeki günlüklerini gösterir. MySQL hata günlükleri için mysqladmin kullanabilirsiniz:

sudo mysqladmin -u root -p variables | grep log_error

2. Bir Hata Günlüğü Mesajının Yapısı: İçinde Hangi Bilgiler Gizli?

Apache'deki tipik bir hata günlüğü satırı şöyledir:

[Mon Oct 21 14:23:45.123456 2025] [php:notice] [pid 12345] [client 192.168.1.1:54321] PHP Notice:  Undefined variable: foo in /var/www/html/index.php on line 15

Bu mesaj şu bölümleri içerir:

  • Tarih ve saat: Hatayı tam olarak ne zaman oluştuğunu belirtir.
  • Hata seviyesi: notice, warning, error, critical gibi. critical seviyesi daha ciddidir.
  • İşlem kimliği (PID): Eşzamanlı istekleri izlemek için kullanışlıdır.
  • İstemci IP adresi: Hatayı hangi kullanıcının deneyimlediğini gösterir.
  • Hata metni: Sorunun ayrıntılı açıklaması.

2.1. Hata Seviyelerini Tanıyın

Sistem ve web sunucusu günlüklerinde, hata seviyeleri önemsizden önemliye doğru şu şekilde sıralanır:

  1. debug: Hata ayıklama bilgisi, genellikle göz ardı edilir.
  2. info: Hizmet başlatma gibi normal olaylar.
  3. notice: Önemli ancak kritik olmayan olaylar.
  4. warning: Uyarı, soruna dönüşebilir.
  5. error: Hata, hizmet hala çalışıyor ancak bir kısmı bozulmuş.
  6. critical: Kritik, hizmet çökebilir.
  7. alert: Acil müdahale gerektirir.
  8. emergency: Sistem çökme noktasında.

Sorun giderme için genellikle error ve üzeri seviyelere odaklanın.

3. Hata Mesajlarını Gerçek Nedene Çevirme

Birçok hata günlüğü mesajı belirsizdir. İşte en yaygın hatalar ve gerçek nedenleri.

3.1. MySQL'de "Connection refused" Hatası

Mesaj: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)

Gerçek neden: MySQL hizmeti çalışmıyor veya soket bozuk. Önce aşağıdaki komutla hizmet durumunu kontrol edin:

sudo systemctl status mysql

Hizmet aktif değilse, başlatın:

sudo systemctl start mysql

Hizmet aktifse ancak hata devam ediyorsa, soket dosyası silinmiş olabilir. Aşağıdaki komutla soket yolunu bulun:

mysql -u root -p -h 127.0.0.1

Bu çalışıyorsa, sorun sokettendir. Soket dosyasını yeniden oluşturun veya MySQL ayarlarında doğru yolu belirtin.

3.2. Web Sunucusu Günlüğünde "Permission denied" Hatası

Mesaj: AH00558: apache2: Could not reliably determine the server's fully qualified domain name

Gerçek neden: Bu bir uyarıdır, kritik hata değil. Genellikle Apache yapılandırma dosyasında ServerName ayarının yapılmamasından kaynaklanır. Düzeltmek için /etc/apache2/apache2.conf dosyasına aşağıdaki satırı ekleyin:

ServerName localhost

Ardından Apache'yi yeniden başlatın:

sudo systemctl restart apache2

3.3. "PHP Fatal error: Allowed memory size exhausted" Hatası

Mesaj: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-admin/includes/media.php on line 123

Gerçek neden: PHP'ye ayrılan bellek (genellikle 128 MB) betiği çalıştırmak için yeterli değil. Bu hata, WordPress'te büyük dosyalar yüklerken yaygındır. Düzeltmek için php.ini dosyasındaki memory_limit değerini artırın:

memory_limit = 256M

Ardından PHP-FPM hizmetini yeniden başlatın:

sudo systemctl restart php7.4-fpm

3.4. "SSL: error:0A000086:SSL routines::certificate verify failed" Hatası

Mesaj: SSL: error:0A000086:SSL routines::certificate verify failed

Gerçek neden: Sunucunuzun SSL sertifikası süresi dolmuş, geçersiz veya sertifika zinciri tam değil. Aşağıdaki komutla sertifikanın son kullanma tarihini kontrol edin:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Sertifikanın süresi dolmuşsa, yenileyin. Sorun sertifika zincirinden kaynaklanıyorsa, fullchain.pem ve privkey.pem dosyalarının web sunucusu yapılandırmasında doğru şekilde yer aldığından emin olun.

4. Hata Günlüğü Okumada Yaygın Hatalar

Birçok acemi yönetici aşağıdaki hataları yapar:

  • Yanlış günlüklere bakmak: Örneğin, Apache hata günlüğü yerine erişim günlüğüne (access log) bakarlar. Erişim günlüğü yalnızca istekleri kaydeder, hataları değil.
  • Hatanın oluşma zamanını göz ardı etmek: Eski hatalar artık geçerli olmayabilir. Sorunun oluştuğu zamana ait günlükleri her zaman kontrol edin.
  • Hata seviyelerini yanlış yorumlamak: Bir warning'ı kritik sanıp üzerinde zaman harcamak.
  • Filtreleme araçlarını kullanmamak: grep komutuyla günlüğü anahtar kelimeye göre filtreleyebilirsiniz. Örneğin:
sudo grep "PHP Fatal error" /var/log/apache2/error.log

5. Hata Günlüğü Analizi için Gelişmiş Araçlar

Büyük projeler için günlükleri manuel okumak imkansızdır. Aşağıdaki araçları kullanın:

  • Logwatch: Günlüklerin özetini günlük olarak e-posta ile gönderen bir komut satırı aracı. Kurulumu ve yapılandırması basittir:
sudo apt install logwatch
sudo logwatch --detail High --mailto admin@example.com --service all --range today
  • GoAccess: Terminal arayüzlü bir web sunucusu günlük analizörü. Erişim ve hata günlüklerini etkileşimli olarak görebilirsiniz.
  • Fail2ban: Hata günlüklerinden brute-force saldırılarını tespit etmek ve saldırgan IP'leri otomatik olarak engellemek için.

6. Son İpucu: Günlükleri Otomatik Olarak İzleyin

Kullanıcıların sorunu bildirmesini beklemeyin. Prometheus ve Grafana gibi araçlarla veya basit bir bash betiğiyle günlükleri otomatik olarak izleyin. Örneğin, aşağıdaki betik her 5 dakikada bir hata günlüğünü kontrol eder ve kritik bir hata bulursa e-posta gönderir:

#!/bin/bash
if sudo tail -n 10 /var/log/apache2/error.log | grep -q "PHP Fatal error"; then
    echo "Sunucuda kritik hata!" | mail -s "Uyarı: PHP Fatal Error" admin@example.com
fi

Bu betiği cron ile her 5 dakikada bir çalıştırın.

Son olarak, sunucunuzu yönetmek için kapsamlı bir çözüm arıyorsanız, ServerNet web barındırma hizmetleri, tam günlüklere ve izleme araçlarına erişim sağlar. Ancak bundan daha önemlisi, bu makalede ele aldığımız sorun giderme ilkelerini öğrenmektir. Pratik yaparak ve yukarıdaki komutları kullanarak, kısa sürede her hata günlüğünü hızlıca analiz edebilir ve sorunun kaynağını bulabilirsiniz.

Bu sayfa yardımcı oldu mu?