Sunucu & DevOps

Linux'ta log okuma: journalctl, /var/log ve sorun ayıklama

kaan.yildiz Mid 1 saat önce · 0 görüntülenme

Bir servis çöktüğünde, site 500 verdiğinde ya da sunucu kendiliğinden yeniden başladığında cevap neredeyse her zaman loglardadır. Sorun, nereye bakacağını bilmektir.

İki kaynak: journald ve /var/log

Modern dağıtımların çoğu systemd kullanır. Servislerin çıktıları journald'a gider ve journalctl ile okunur. Bunun yanında birçok uygulama kendi dosyasını /var/log altına yazar.

Dosya / komut	İçerik
`journalctl`	systemd servislerinin ve çekirdeğin günlükleri
`/var/log/auth.log` (Debian/Ubuntu), `/var/log/secure` (RHEL)	Giriş denemeleri, sudo kullanımı
`/var/log/syslog` veya `/var/log/messages`	Genel sistem mesajları
`/var/log/nginx/`, `/var/log/apache2/`	Web sunucusu erişim ve hata günlükleri
`/var/log/mysql/`, `/var/log/postgresql/`	Veritabanı günlükleri
`dmesg`	Çekirdek mesajları (donanım, disk hataları, bellek yetersizliği)

journalctl ile en çok kullanılanlar

journalctl -u nginx                     # tek bir servis
journalctl -u nginx -f                  # canlı izle (tail -f gibi)
journalctl -u nginx --since "1 hour ago"
journalctl --since "2026-11-10 14:00" --until "2026-11-10 15:00"
journalctl -p err -b                    # bu açılıştan beri sadece hatalar
journalctl -b -1                        # bir önceki açılışın günlüğü
journalctl -k                           # sadece çekirdek mesajları
journalctl -u ssh -n 50 --no-pager      # son 50 satır, sayfalamadan

Sunucu kendiliğinden yeniden başladıysa journalctl -b -1 -e ile bir önceki açılışın sonuna bak. Kapanmadan hemen önceki satırlar sebebi gösterir.

Not: Bazı sistemlerde günlükler kalıcı değildir ve yeniden başlatınca silinir. /var/log/journal klasörü yoksa oluşturup systemctl restart systemd-journald dersen günlükler kalıcı hâle gelir.

Bir servis neden başlamıyor?

systemctl status php8.3-fpm
journalctl -u php8.3-fpm -n 50 --no-pager

status çıktısının en altındaki birkaç satır çoğu zaman sebebi yazar: yapılandırma dosyasında sözdizimi hatası, port başka bir program tarafından kullanılıyor, izin hatası...

Web sunucusu yapılandırmasını değiştirmeden önce test etmek de iyi bir alışkanlıktır:

sudo nginx -t
sudo apachectl configtest

Dosya günlüklerinde arama

tail -n 100 /var/log/nginx/error.log
tail -f /var/log/nginx/error.log
grep -i "error" /var/log/syslog | tail -n 50
zgrep "timeout" /var/log/nginx/error.log.*.gz       # eski, sıkıştırılmış günlüklerde
less +F /var/log/syslog                              # canlı izle, Ctrl+C ile kaydır

Erişim günlüğünden hızlı istatistik:

# En çok istek yapan 10 IP
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
# 5xx hatası veren istekler
awk '$9 ~ /^5/' /var/log/nginx/access.log | tail -n 20

Klasik ipuçları

Out of memory: Killed process (dmesg veya journalctl -k): Bellek bitti, çekirdek bir işlemi öldürdü. Genellikle veritabanı veya PHP/Node süreçleri kurban olur.
I/O error, EXT4-fs error: Disk sorunu olabilir. Yedeğini hemen kontrol et.
Permission denied: Dosya veya klasör sahibine ve izinlerine bak.
Address already in use: Port başka bir işlem tarafından kullanılıyor. sudo ss -tulpn | grep :80 ile kim olduğunu bul.

Günlükler diski doldurmasın

journalctl --disk-usage
sudo journalctl --vacuum-size=500M      # 500 MB'a indir
sudo journalctl --vacuum-time=30d       # 30 günden eskileri sil

Kalıcı sınır için /etc/systemd/journald.conf dosyasında SystemMaxUse=500M ayarlanabilir. Dosya günlüklerini ise logrotate döndürür (/etc/logrotate.d/). Bir uygulama kendi günlüğünü yazıyorsa onun için de bir logrotate kuralı olduğundan emin ol.

#journalctl #linux #log #systemd