Linux Sunucu Log Dosyaları Nerede, Nasıl Okunur (journalctl, /var/log)

Son doğrulama: Eylül 2026 · Ubuntu 24.04 test sunucusunda denendi

Linux log dosyaları nasıl okunur, neden gerekir

Bir servis çökmesi, başarısız giriş denemesi ya da beklenmeyen yeniden başlatma yaşandığında sunucunun ne yaptığını yalnızca log dosyaları anlatır. systemd kullanan güncel dağıtımlarda (Ubuntu, Debian, AlmaLinux, Rocky) çekirdek, servis ve oturum kayıtlarının çoğu journalctl komutuyla okunan ikili bir günlükte (journal) tutulur; komutun tüm seçenekleri journalctl’in resmi man sayfasında listelenir. Bunun yanında eski yapıdan kalan servisler kayıtları hâlâ /var/log altında düz metin dosyalarına da yazar; bu dosyalar tail ve grep ile filtrelenir.

İki katmanın birlikte var olmasının pratik bir sonucu vardır: bir sorunu ararken tek bir yere bakmak yetmez. Örneğin başarısız SSH girişleri Ubuntu ve Debian’da /var/log/auth.log, AlmaLinux ve RHEL ailesinde /var/log/secure dosyasına yazılır; aynı kayıtlar çoğu zaman journalctl üzerinden de okunabilir. Hangi yolu seçeceğiniz, o servisin sunucunuzda journal’a mı yoksa doğrudan dosyaya mı yazdığına bağlıdır.

Log dosyalarını adım adım okuma

1. Log alanının ne kadar yer kapladığını görün. Sorun gidermeden önce kayıtların ne zamandan başladığını bilmek işinize yarar.

   journalctl --disk-usage

   Beklenen sonuç: “Archived and active journals take up X.XM in the file system.” satırı; test sunucusunda bu değer 8,0M çıktı.

2. Güncel önyüklemenin (boot) kayıtlarına bakın.-b bayrağı yalnızca sunucunun son açılışından beri oluşan kayıtları gösterir, --no-pager çıktıyı sayfalama olmadan doğrudan terminale basar.

   journalctl -b --no-pager | tail -n 30

   Beklenen sonuç: zaman damgası, sunucu adı, servis adı ve mesajın yer aldığı satırlar listelenir; test sunucusunda son satırlar systemd[…]: Reached target sockets.target - Sockets. gibi servis başlatma kayıtlarıydı.

3. Yalnızca hataları filtreleyin. Yüzlerce bilgi satırı arasında kaybolmamak için önem seviyesine göre süzün; err systemd’nin öncelik seviyelerinden biridir.

   journalctl -p err -b --no-pager

   Beklenen sonuç: yalnızca hata seviyesindeki satırlar kalır; test sunucusunda bu komut bir SSH protokol uyarısı ve bir MariaDB kurulum uyarısı döndürdü, bilgi satırlarının tamamı elendi.

4. Klasik metin log dosyalarını listeleyin ve okuyun./var/log dizini hem güncel hem sıkıştırılmış eski (.gz) dosyaları tutar.

   ls -la /var/logtail -n 30 /var/log/auth.log

   Beklenen sonuç: dizinde auth.log, syslog, dmesg, btmp gibi dosyalar görünür; tail son satırları olduğu gibi listeler.

5. Belirli bir ifadeyi arayın. Uzun bir dosyada tek bir olayı bulmak için grep kullanın; -i büyük/küçük harf ayrımını kapatır.

   grep -i "fail" /var/log/auth.log | tail -n 10

   Beklenen sonuç: eşleşen satırlar listelenir; test sunucusunda bu komut örnek bir adresten (203.0.113.45) gelen “Failed password for invalid user admin” satırını gösterdi — otomatik tarama girişimlerinin tipik izidir.

6. Çekirdek ve donanım mesajlarına bakın. Disk, ağ kartı ya da bellek ile ilgili düşük seviyeli olaylar burada birikir.

   dmesg | tail -n 30

   Beklenen sonuç: çekirdek zaman damgasıyla başlayan satırlar; test sunucusunda AppArmor’un bir arka plan sürecini kısıtladığını bildiren “DENIED” satırları görüldü.

Doğrulama

Hâlâ çözülmediyse

• journalctl “No journal files were found” veriyor. Sunucu kalıcı (persistent) günlük saklamıyor olabilir; sorun devam eden bir servisle ilgiliyse /var/log altındaki dosyaya bakın.
• /var/log dizini beklenenden küçük, eski kayıt yok. logrotate periyodik olarak eski dosyaları sıkıştırıp yeniden başlatır; .gz uzantılı dosyaları da kontrol edin.
• Sunucu genel olarak yavaş ama loglarda net bir hata yok. Kaynak tüketimini top/htop ile kaynak izleme kartındaki adımlarla kontrol edin.