Sistem Loglarından Hata Kaynağını Bulma Yöntemi
Bir sistem yöneticisinin en değerli silahı, hata mesajlarını okuyup anlayabilme yeteneğidir. Sunucu gecenin üçünde çöktüğünde, uygulama aniden yanıt vermez olduğunda ya da bir servis başlamayı reddettiğinde, geriye kalan tek rehber log dosyalarıdır. Bu yazıda Linux sistemlerde log analizi yapmanın pratik yöntemlerini, gerçek dünya senaryolarıyla birlikte ele alacağız.
Log Dosyaları Nerede Bulunur?
Linux sistemlerde loglar geleneksel olarak /var/log/ dizini altında toplanır. Ancak modern sistemlerde journald devreye girdiğinden bu durum biraz daha karmaşık bir hal almıştır.
Temel log dosyaları şunlardır:
- /var/log/syslog veya /var/log/messages: Genel sistem mesajları (Debian/Ubuntu’da syslog, RHEL/CentOS’ta messages)
- /var/log/auth.log veya /var/log/secure: Kimlik doğrulama ve yetkilendirme logları
- /var/log/kern.log: Kernel mesajları
- /var/log/dmesg: Boot zamanı donanım ve sürücü mesajları
- /var/log/boot.log: Sistem başlangıç logları
- /var/log/nginx/ veya /var/log/apache2/: Web sunucu logları
- /var/log/mysql/ veya /var/log/postgresql/: Veritabanı logları
Bunların yanı sıra systemd tabanlı sistemlerde journalctl komutu, tüm servislerin loglarına merkezi erişim sağlar.
journalctl ile Hata Arama
Modern bir Ubuntu veya CentOS sisteminde ilk durağınız journalctl olmalıdır. Binlerce satır log arasında kaybolmadan hata bulmak için doğru filtreleri kullanmak kritik öneme sahiptir.
# Sadece hata ve kritik mesajları göster
journalctl -p err..crit
# Son 100 satırı göster ve yeni logları takip et
journalctl -n 100 -f
# Belirli bir servise ait logları getir
journalctl -u nginx.service
# Son 1 saatin loglarını göster
journalctl --since "1 hour ago"
# Belirli zaman aralığındaki logları filtrele
journalctl --since "2024-01-15 08:00:00" --until "2024-01-15 09:30:00"-p parametresi öncelik seviyesini belirtir. Kullanabileceğiniz seviyeler şunlardır:
- emerg (0): Sistem kullanılamaz durumda
- alert (1): Hemen müdahale gerektirir
- crit (2): Kritik hatalar
- err (3): Hata mesajları
- warning (4): Uyarılar
- notice (5): Normal ama önemli mesajlar
- info (6): Bilgilendirme mesajları
- debug (7): Debug mesajları
Gerçek dünyada bir senaryo düşünelim: Bir web sunucunuz sabah 3’te yanıt vermez oldu ve sabah 8’de işe geldiğinizde bunu fark ettiniz. İlk yapmanız gereken tam olarak o zaman diliminde ne olduğunu anlamak:
# Gece 2 ile 4 arasındaki kritik hataları getir
journalctl -p err..emerg --since "03:00" --until "04:00" --no-pager
# Çıktıyı bir dosyaya kaydet ve analiz et
journalctl -p err..emerg --since "2024-01-15 02:00:00" --until "2024-01-15 04:00:00" > /tmp/gece_hatalari.loggrep ile Log Dosyalarında Hedefli Arama
grep komutu, log analizi yapan her sysadmin’in vazgeçilmezi olmalıdır. Düzgün kullanıldığında binlerce satır arasından saniyeler içinde ilgili satırları bulursunuz.
# Büyük/küçük harf duyarsız hata araması
grep -i "error|failed|critical" /var/log/syslog
# Hata satırını ve sonraki 5 satırı göster (bağlamı anlamak için)
grep -i "segfault" /var/log/syslog -A 5
# Hata satırını ve önceki 3 satırı göster
grep -i "out of memory" /var/log/syslog -B 3
# Hem önceki hem sonraki 5 satırı göster
grep -i "connection refused" /var/log/nginx/error.log -C 5
# Kaç satır eşleştiğini say
grep -c "ERROR" /var/log/mysql/error.log
# Hangi dosyalarda eşleşme var
grep -rl "permission denied" /var/log/-A: Eşleşmeden sonraki N satırı gösterir -B: Eşleşmeden önceki N satırı gösterir -C: Eşleşmenin hem öncesini hem sonrasını gösterir -i: Büyük/küçük harf duyarsız arama -r: Alt dizinleri de dahil ederek recursive arama -l: Sadece eşleşme bulunan dosya adlarını listeler -c: Eşleşme sayısını gösterir
Birden Fazla Log Dosyasını Aynı Anda Taramak
Büyük bir sorunla karşılaştığınızda genellikle tek bir log dosyasına bakmak yetmez. Birden fazla servisi etkileyen bir sorun olduğunda hepsine aynı anda bakmanız gerekir:
# Birden fazla dosyada eş zamanlı arama
grep -i "error" /var/log/syslog /var/log/auth.log /var/log/kern.log
# Tüm log dosyalarında ama gzip'li dosyaları atla
find /var/log -name "*.log" -not -name "*.gz" -exec grep -l "segfault" {} ;
# zgrep ile sıkıştırılmış log dosyalarında arama
zgrep "failed" /var/log/syslog.*.gztail ve multitail ile Canlı Log Takibi
Bir sorun tam anlamıyla devam ediyorsa ya da bir servisi yeniden başlatıp ne olacağını görmek istiyorsanız, canlı log takibi yapmanız gerekir.
# Tek dosyayı canlı takip et
tail -f /var/log/syslog
# Birden fazla dosyayı aynı anda takip et
tail -f /var/log/nginx/error.log -f /var/log/nginx/access.log
# grep ile birleştirerek sadece hataları göster
tail -f /var/log/syslog | grep -i "error|warning|failed"
# Son 200 satırdan başlayarak takip et
tail -n 200 -f /var/log/auth.logmultitail aracı kurulu değilse şiddetle tavsiye ederim. Birden fazla log dosyasını aynı terminal ekranında renkli olarak gösterir:
# multitail kurulumu
apt install multitail # Debian/Ubuntu
yum install multitail # RHEL/CentOS
# Kullanımı
multitail /var/log/syslog /var/log/auth.logawk ve sed ile Log Analizi
Ham log dosyaları bazen işlenmesi gereken veri içerir. awk ve sed bu iş için biçilmiş kaftandır.
# Nginx access logunda en çok 500 hatası veren URL'leri bul
awk '$9 == 500 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Belirli bir IP adresinden gelen tüm istekleri filtrele
awk '$1 == "192.168.1.100"' /var/log/nginx/access.log
# Auth logunda başarısız SSH girişimlerini say ve IP bazlı grupla
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -10
# Log dosyasından sadece zaman damgası ve hata mesajını al
sed 's/(.*) [error] (.*)/1 - 2/' /var/log/nginx/error.log | head -50Bu son awk örneği gerçek hayatta çok işe yarar. Bir güvenlik ihlali şüphesi olduğunda hangi IP adreslerinin brute force saldırısı yaptığını anında görebilirsiniz.
Disk, Bellek ve Kernel Hatalarını Bulmak
Donanım kaynaklı hatalar en sinsi sorunlardır. Disk bozulması, bellek hataları ya da kernel panikler genellikle farklı yerlerde iz bırakır.
# Kernel mesajlarına bak
dmesg | grep -i "error|fail|warn"
# Disk hatalarını kontrol et
dmesg | grep -i "i/o error|bad sector|ata|scsi"
# Son 10 dakikanın kernel mesajları
dmesg --since "10 minutes ago"
# OOM (Out of Memory) killer devreye girmiş mi kontrol et
grep -i "killed process|out of memory" /var/log/syslog
# Disk SMART durumunu log olarak kaydet
smartctl -a /dev/sda 2>&1 | grep -i "error|fail|warning"Gerçek bir senaryo: Bir üretim sunucusunda uygulama sürekli çöküyor ama nedeni bilinmiyor. OOM killer ipucu verebilir:
grep -i "oom|out of memory|killed process" /var/log/syslog | tail -20Çıktıda şöyle bir şey görürseniz, bellek yetersizliği kesinleşmiş demektir:
Jan 15 03:42:17 sunucu kernel: [1234567.890] Out of memory: Kill process 12345 (java) score 900 or sacrifice child
Jan 15 03:42:17 sunucu kernel: [1234567.891] Killed process 12345 (java) total-vm:4096000kB, anon-rss:3800000kBServis Hatalarını Derinlemesine İnceleme
Bir servis başlamıyorsa ya da sürekli çöküyorsa, systemctl ve journalctl birlikte kullanmak size en hızlı sonucu verir.
# Servisin detaylı durumunu göster
systemctl status nginx.service -l
# Servise ait tüm logları zaman sırasıyla göster
journalctl -u postgresql.service --no-pager
# Sadece son başlangıç denemesinin loglarını göster
journalctl -u mysql.service -b
# Servis kaç kez yeniden başladı
journalctl -u nginx.service | grep "Started|Stopped" | wc -l
# Belirli bir boot oturumunun logları (-1 bir önceki boot anlamına gelir)
journalctl -u apache2.service -b -1systemctl status komutu birçok bilgiyi bir arada sunar. Çıktıdaki Active satırı servisin mevcut durumunu, Main PID çalışan proses ID’sini, alt kısımdaki log satırları ise son olayları gösterir.
Başlangıç Sırası Sorunları
Bazen bir servis, bağımlı olduğu başka bir servis başlamadan önce başlamaya çalışır. Bu durumu tespit etmek için:
# Systemd başlangıç zamanlamalarını analiz et
systemd-analyze blame
# Bağımlılık zincirini görselleştir
systemd-analyze critical-chain nginx.service
# Tüm servislerin başlangıç sürelerini listele
systemd-analyze plot > /tmp/boot_analizi.svgUygulama Loglarında Örüntü Analizi
Özellikle üretim ortamlarında loglar çok hızlı büyür. Sadece hata aramak değil, hata örüntülerini bulmak da önemlidir. Belirli bir hata dakikada bir mi görünüyor, yoksa saatte bir mi?
# Her saatte kaç hata oluştuğunu göster
grep "ERROR" /var/log/uygulama.log | awk '{print $1, $2}' | cut -c1-13 | sort | uniq -c
# Benzersiz hata mesajlarını listele ve say
grep "ERROR" /var/log/uygulama.log | awk -F'ERROR' '{print $2}' | sort | uniq -c | sort -rn | head -20
# Belirli bir zaman periyodundaki hata yoğunluğunu analiz et
awk '/2024-01-15 08:/{count++} END{print "08:xx saatinde", count, "hata"}' /var/log/uygulama.logLogrotate ile Eski Logları Kaybetmemek
Bir sorun birkaç gün önce başladıysa ve loglar rotate edilmişse, sıkıştırılmış eski loglara bakmanız gerekir:
# Sıkıştırılmış tüm log dosyalarını listele
ls -la /var/log/syslog*.gz
# Sıkıştırılmış logda arama yap
zgrep "error" /var/log/syslog.2.gz
# Sıkıştırılmış logu geçici olarak aç ve incele
zcat /var/log/syslog.1.gz | grep "Jan 13" | grep -i "failed"
# Tüm rotate edilmiş logları birleştirerek ara
zcat /var/log/nginx/error.log.*.gz | grep "upstream timed out" | tail -50Gerçek Dünya Senaryosu: Yavaşlayan Bir Web Sunucusu
Diyelim ki nginx tabanlı bir web sunucunuz sabah saatlerinde aşırı yavaşlıyor ama tam olarak neden olduğunu bilmiyorsunuz. Adım adım nasıl yaklaşırsınız?
1. Adım: Genel duruma bakın
# Sistem kaynaklarına genel bakış
uptime
free -h
df -h
# Son 200 satır sistem logu
journalctl -n 200 --no-pager | grep -i "error|warn|crit"2. Adım: Nginx loglarını zaman damgasıyla analiz edin
# Sabah 8-9 arasındaki 500 hatalarını say
awk '$4 >= "[15/Jan/2024:08:00:00" && $4 <= "[15/Jan/2024:09:00:00"' /var/log/nginx/access.log | grep " 500 " | wc -l
# O saatte en çok istek gelen endpoint'ler
awk '$4 >= "[15/Jan/2024:08:00:00"' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -10
# Upstream hataları kontrol et
grep "upstream timed out|upstream sent invalid" /var/log/nginx/error.log | grep "2024/01/15 08:" | head -303. Adım: Backend servislerini kontrol edin
# Uygulama servisinin loglarına bak
journalctl -u gunicorn.service --since "08:00" --until "09:00" | grep -i "error|exception|timeout"
# Veritabanı bağlantı sorunları var mı
grep "connection refused|too many connections|timeout" /var/log/postgresql/postgresql-*.logBu sistematik yaklaşım çoğu zaman 10-15 dakika içinde sorunun kaynağını ortaya çıkarır.
Log Analizi İçin Yararlı Araçlar
Komut satırı araçlarının yanı sıra bazı özel araçlar da hayatınızı kolaylaştırabilir:
- logwatch: Günlük log özetleri hazırlar ve mail atar. Küçük kurulumlar için idealdir.
- goaccess: Nginx ve Apache loglarını gerçek zamanlı analiz eder, terminal veya web arayüzü sunar.
- lnav: Log dosyalarını renkli ve gezinilebilir şekilde görüntüler.
- fail2ban-client status: Fail2ban’ın yasakladığı IP’leri ve neden yasakladığını gösterir.
Bu araçların kurulum ve temel kullanımı:
# logwatch kurulumu ve günlük özet alma
apt install logwatch
logwatch --output stdout --format text --range today
# goaccess ile nginx log analizi
apt install goaccess
goaccess /var/log/nginx/access.log --log-format=COMBINED
# lnav kurulumu
apt install lnav
lnav /var/log/syslog /var/log/auth.logHata Ayıklama İş Akışı
Bir soruna yaklaştığınızda sistematik bir iş akışı izlemek, ilerleyen saatlerde kendinizi log denizinde boğulmaktan kurtarır:
- Zaman damgasını sabitle: Sorun ne zaman başladı? Kullanıcı şikayetleri, monitoring alertleri ya da kendiniz fark ettiniz mi?
- Geniş tarama yap: journalctl ile o zaman aralığında kritik ve hata seviyesindeki tüm mesajlara bakın.
- İzole et: Hangi servis ya da component ilk hata mesajını verdi? Zaman sırasına dikkat edin.
- Derinleştir: İlk hata mesajını bulduktan sonra o servise özgü logları inceleyin.
- Bağlamı anlayın: Hatadan önceki ve sonraki log satırlarına bakın. Hata birden çıkmış olamaz.
- Dışsal faktörleri kontrol edin: O saatte bir deployment var mıydı? Cron job çalıştı mı? Disk doldu mu?
Sonuç
Log analizi bir sanat kadar bir bilimdir. Başlangıçta karmaşık görünen binlerce satır log, doğru araçlar ve sistematik bir yaklaşımla birkaç dakika içinde anlaşılır hale gelir. journalctl, grep, awk ve tail dörtlüsünü elinizin arkası gibi bilmek, sorunları çözmede size büyük avantaj sağlar.
En önemli nokta: paniklemeden, adım adım ilerlemektir. Sunucu çöktüğünde ya da servis yanıt vermediğinde loglar her zaman bir hikaye anlatır. Sizin göreviniz o hikayeyi okumak ve doğru soruları sormaktır. Zaman damgasını sabitleyin, genel taramadan özele inin ve hata mesajının bağlamını anlamadan sonuca atlamayın.
Bir de şunu söylemeden geçemeyeceğim: Düzenli olarak loglarınıza bakma alışkanlığı edinin. Sorun olmasa bile haftada bir log özetlerine göz atmak, küçük sorunları büyümeden yakalamanızı sağlar. logwatch gibi araçlar bu alışkanlığı otomatize etmenize yardımcı olur.