Kernel Log Analizi: dmesg ve /var/log/kern.log Kullanımı

Bykomut

Sunucunuzda garip bir şey olduğunu hissediyorsunuz ama tam olarak ne olduğunu bilmiyorsunuz. Servisler rastgele düşüyor, donanım hataları alıyorsunuz ya da sistem yavaşlıyor. İşte bu anlarda kernel log’ları en iyi arkadaşınız oluyor. Linux çekirdeği, sistemde olan her şeyi sessizce kayıt altına alır ve bu kayıtlar doğru okunduğunda size sistemin tam hikayesini anlatır.

Kernel Log’ları Nedir ve Neden Önemlidir?

Linux kernel’i, donanım ile yazılım arasındaki köprüdür. Bu köprüde olan her şey, yani disk hataları, bellek sorunları, ağ sürücüsü çakışmaları, USB bağlantı olayları, OOM (Out of Memory) durumları, kernel log’larına düşer. Bu log’ları okumayı öğrenmek, bir sysadmin olarak sizi gerçekten bir sonraki seviyeye taşır.

İki temel kaynak vardır: dmesg komutu ve /var/log/kern.log dosyası. İkisi de kernel ring buffer’dan beslenir ama aralarında önemli farklar vardır.

dmesg, kernel’in bellekte tuttuğu ring buffer’ı okur. Sistem yeniden başlatıldığında bu buffer sıfırlanır, dolayısıyla eski bilgileri tutmaz. Ancak anlık durumu görmek için mükemmeldir.

/var/log/kern.log ise rsyslog veya syslog-ng gibi bir syslog daemon’ı tarafından diske yazılan, kalıcı kernel log dosyasıdır. Sistem yeniden başlasa bile eski logları burada bulabilirsiniz. Debian/Ubuntu tabanlı sistemlerde bu dosya varsayılan olarak oluşturulur. RHEL/CentOS tabanlı sistemlerde ise /var/log/messages dosyası kernel loglarını da içerir.

dmesg Komutunu Etkili Kullanmak

Basitçe dmesg yazdığınızda ekrana binlerce satır dolar. Bu çıktıyı anlamlı hale getirmek için bazı parametreleri ve teknikleri bilmeniz gerekiyor.

Temel Kullanım ve Parametreler

# Tum kernel mesajlarini goster
dmesg

# Sayfalandirarak goster (q ile cikis)
dmesg | less

# Son 20 satiri goster
dmesg | tail -20

# Mesaj sayisini belirt
dmesg -n 5

dmesg komutunun modern Linux sistemlerinde çok daha kullanışlı hale gelen parametreleri şunlar:

-H: Human-readable formatta gösterir, renklendirme ve zaman damgası ile birlikte.

-T: Zaman damgalarını okunabilir tarihe çevirir. Sistem uptime’ı yerine gerçek tarih/saat gösterir.

-L: Çıktıyı renklendirir (hata, uyarı, bilgi mesajları farklı renklerde).

-w: Watch modunda çalışır, yeni mesajlar geldikçe ekrana basar. tail -f gibi düşünebilirsiniz.

-l: Log seviyesine göre filtreler.

-f: Tesise (facility) göre filtreler.

# Insan okunabilir format, renkli, gercek tarih
dmesg -HTL

# Sadece hata ve kritik mesajlari goster
dmesg -l err,crit,alert,emerg

# Canli izleme modu
dmesg -w

# Sadece kernel mesajlari (facility bazli)
dmesg -f kern

# Son sistem acilisini filtrele
dmesg -T | grep -i "error|warn|fail"

Log Seviyeleri Nelerdir?

Kernel mesajları 0’dan 7’ye kadar önem seviyelerine sahiptir. Bu seviyeleri bilmek, hangi mesajlara öncelik vereceğinizi anlamanızı sağlar.

  • 0 – emerg: Sistem kullanılamaz durumda, kernel panic gibi durumlar
  • 1 – alert: Hemen müdahale gerekiyor
  • 2 – crit: Kritik durum, donanım hataları
  • 3 – err: Hata durumları, sürücü hataları
  • 4 – warn: Uyarılar, potansiyel sorunlar
  • 5 – notice: Normal ama önemli olaylar
  • 6 – info: Bilgilendirme mesajları
  • 7 – debug: Debug bilgileri
# Sadece hata ve ustundeki seviyeleri goster (0-3)
dmesg -l emerg,alert,crit,err

# Uyarilari da dahil et (0-4)
dmesg -l emerg,alert,crit,err,warn

# Belirli bir sure araliginda mesajlari filtrele
dmesg -T | awk '/Jan 15 10:00/,/Jan 15 11:00/'

/var/log/kern.log Dosyasını Analiz Etmek

dmesg anlık durum için harika ama geçmişe bakmak istediğinizde /var/log/kern.log devreye giriyor. Bu dosya rotasyona uğrar ve genellikle kern.log.1, kern.log.2.gz gibi sıkıştırılmış arşivler halinde tutulur.

# Gercek zamanli izleme
tail -f /var/log/kern.log

# Hatalar icin arama
grep -i "error" /var/log/kern.log

# Belirli bir tarih araliginda arama
grep "Jan 15" /var/log/kern.log | grep -i "error"

# Tum rotasyonlu dosyalarda arama (gz dahil)
zgrep -i "error" /var/log/kern.log*

# Son 100 satirda hata ara
tail -100 /var/log/kern.log | grep -i "err|fail|warn"

Disk ve Depolama Hatalarını Tespit Etmek

Disk hataları en kritik durumların başında gelir. Bir diskin ölmeden önce verdiği işaretleri kernel log’larında görebilirsiniz.

# Disk hatalarini ara
grep -i "I/O error|hard resetting|ata.*error|SCSI error" /var/log/kern.log

# EXT4 filesystem hatalarini kontrol et
grep -i "EXT4-fs error|ext4_journal|buffer I/O" /var/log/kern.log

# RAID sorunlarini incele
grep -i "md|raid|degraded" /var/log/kern.log

Gerçek bir senaryo üzerinden gidelim. Diyelim ki kullanıcılar yavaş disk performansından şikayet ediyor:

# Once genel durumu goster
dmesg -T | grep -E "sda|sdb|nvme" | tail -50

# Tipik cikan hatalar boyle gorunur:
# [Mon Jan 15 09:23:11 2024] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
# [Mon Jan 15 09:23:11 2024] ata1.00: failed command: READ FPDMA QUEUED
# [Mon Jan 15 09:23:11 2024] ata1.00: status: { DRDY ERR }
# [Mon Jan 15 09:23:11 2024] ata1.00: error: { UNC }

# Bu tarz hatalarda SMART durumunu da kontrol edin
smartctl -a /dev/sda | grep -i "reallocated|pending|uncorrectable"

Bu logları görüyorsanız disk değişimi için acil planlama yapmanız gerekiyor.

OOM Killer Olaylarını Analiz Etmek

OOM (Out of Memory) Killer, sistem belleği tükendiğinde kernel’in devreye soktugu bir mekanizmadır. Bir process’i öldürerek sistemi kurtarmaya çalışır. Bu olaylar production’da ciddi sorunlara yol açabilir.

# OOM olaylarini bul
dmesg -T | grep -i "killed process|out of memory|oom"

# Daha detayli OOM analizi
grep -i "oom|killed process|out of memory" /var/log/kern.log

# Hangi process ne kadar bellek kullaniyordu
grep -A 20 "Out of memory" /var/log/kern.log | head -50

Tipik bir OOM log çıktısı şöyle görünür ve bunu okumayı öğrenmek çok değerlidir:

kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
kernel: mysqld cpuset=/ mems_allowed=0
kernel: Mem-Info:
kernel: active_anon:1250000 inactive_anon:50000 ...
kernel: Out of memory: Kill process 12345 (mysqld) score 800 or sacrifice child
kernel: Killed process 12345 (mysqld) total-vm:4000000kB, anon-rss:3500000kB

Bu logdan şunları anlayabilirsiniz: MySQL, OOM Killer’ı tetiklemiş, sistemi kurtarmak için de yine MySQL process’i kurban edilmiş. Bu durumda MySQL bellek konfigürasyonunu, innodb_buffer_pool_size değerini ve toplam sistem belleğini gözden geçirmeniz gerekiyor.

Donanım Hatalarını ve Kernel Paniclerini Analiz Etmek

Kernel panic, Linux sistemlerinde en korkulan durumlardan biridir. Sistem tamamen donar ve yeniden başlatılması gerekir. Ancak bu durumun izlerini log’larda bulabilirsiniz.

# Kernel panic izlerini ara
grep -i "kernel panic|Oops|BUG:" /var/log/kern.log

# MCE (Machine Check Exception) hatalarini kontrol et
dmesg -T | grep -i "mce|machine check|hardware error"

# CPU hatalari
grep -i "CPU.*error|corrected hardware|EDAC" /var/log/kern.log

# Bellek hatalari (ECC bellekli sistemlerde)
grep -i "EDAC|memory error|correctable|uncorrectable" /var/log/kern.log

MCE hataları özellikle dikkat gerektiriyor. Bir sunucuda şunu görüyorsanız:

# Bu komutu calistirip MCE detaylarini inceleyin
mcelog --client 2>/dev/null || dmesg | grep -i "machine check"

# Tipik bir MCE hata ciktisi:
# mce: [Hardware Error]: Machine check events logged
# mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: b200000000070f0f
# mce: [Hardware Error]: TSC 0 ADDR fe0000000 MISC 88 
# mce: [Hardware Error]: PROCESSOR 0:306a9 TIME 1705311234 SOCKET 0 APIC 0 microcode 21

Bu tarz hatalar RAM veya CPU sorununa işaret eder. Hemen donanım satıcınıza bildirmeniz ve etkilenen bellek modülünü tespit etmeniz gerekiyor.

Ağ Sorunlarını Kernel Log’larından Tespit Etmek

Ağ sürücüsü hataları, link down/up olayları ve NIC sorunları da kernel log’larına düşer.

# Network interface olaylarini izle
dmesg -T | grep -i "eth0|ens|bond|link|network"

# NIC hatalari
grep -i "tx timeout|link down|link is down|renamed" /var/log/kern.log

# Bonding durumu
grep -i "bond|slave|active backup" /var/log/kern.log

# Gercek zamanli network olaylarini izle
dmesg -w | grep -i "eth|ens|link|net"

Bir üretim senaryosu: Gece 03:00’da monitoring alertleriniz geliyor, ağ bağlantısı kesiliyor. Sabah gelip logları inceliyorsunuz:

# Gece 3'teki olaylara bak
grep "Jan 15 03:" /var/log/kern.log | grep -i "eth|link|ens"

# Cikabilecek ornek log:
# Jan 15 03:14:22 webserver01 kernel: e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang
# Jan 15 03:14:22 webserver01 kernel: e1000e 0000:00:19.0 eth0: Reset adapter
# Jan 15 03:14:23 webserver01 kernel: e1000e 0000:00:19.0 eth0: NIC Link is Up 1000 Mbps

# Surucuyu guncellemeyi veya NIC'i degistirmeyi dusunun
ethtool -i eth0

Pratik Log Analiz Script’leri

Günlük işlerinizi kolaylaştırmak için basit ama etkili script’ler yazabilirsiniz.

#!/bin/bash
# kernel_health_check.sh - Gunluk kernel log saglik kontrolu

LOG_FILE="/var/log/kern.log"
REPORT_FILE="/tmp/kernel_report_$(date +%Y%m%d).txt"
YESTERDAY=$(date -d "yesterday" "+%b %e")

echo "=== Kernel Saglik Raporu - $(date) ===" > $REPORT_FILE
echo "" >> $REPORT_FILE

echo "### OOM Olaylari ###" >> $REPORT_FILE
grep "$YESTERDAY" $LOG_FILE | grep -i "out of memory|oom killer|killed process" >> $REPORT_FILE
echo "" >> $REPORT_FILE

echo "### Disk Hatalari ###" >> $REPORT_FILE
grep "$YESTERDAY" $LOG_FILE | grep -i "I/O error|ata.*error|SCSI" >> $REPORT_FILE
echo "" >> $REPORT_FILE

echo "### Donanim Hatalari ###" >> $REPORT_FILE
grep "$YESTERDAY" $LOG_FILE | grep -i "hardware error|machine check|mce" >> $REPORT_FILE
echo "" >> $REPORT_FILE

echo "### Network Hatalari ###" >> $REPORT_FILE
grep "$YESTERDAY" $LOG_FILE | grep -i "link down|tx timeout|reset adapter" >> $REPORT_FILE
echo "" >> $REPORT_FILE

echo "### Kritik Hatalar ###" >> $REPORT_FILE
grep "$YESTERDAY" $LOG_FILE | grep -i "kernel panic|BUG:|Oops:" >> $REPORT_FILE

cat $REPORT_FILE

Bu script’i cron ile her sabah çalıştırıp e-posta ile kendinize gönderebilirsiniz.

# Crontab'a ekle
# Her sabah 07:00'da calistir ve mail gonder
0 7 * * * /usr/local/bin/kernel_health_check.sh | mail -s "Kernel Saglik Raporu - $(hostname)" [email protected]

journalctl ile Kernel Log’larına Erişmek

Modern systemd tabanlı sistemlerde journalctl kernel log’larına erişmek için güçlü bir alternatif sunar.

# Sadece kernel mesajlarini goster
journalctl -k

# Son sistem acilisindaki kernel mesajlari
journalctl -k -b 0

# Bir onceki sistem acilisi
journalctl -k -b -1

# Iki acilis oncesi
journalctl -k -b -2

# Bircok acilis varsa listeyi goster
journalctl --list-boots

# Belirli bir tarih araliginda kernel mesajlari
journalctl -k --since "2024-01-15 00:00:00" --until "2024-01-15 23:59:59"

# Sadece hata seviyesi ve ustunu goster
journalctl -k -p err

# Gercek zamanli izleme
journalctl -k -f

journalctl -b -1 -k komutu, özellikle sistem beklenmedik şekilde kapandıktan sonra ne olduğunu anlamak için çok değerlidir. Bir önceki oturumun kernel log’larını gösterir.

Log Analizi İçin Faydalı Araçlar

Ham log analizi bazen yetersiz kalabilir. Bu araçlar işinizi kolaylaştırır.

logwatch: Günlük log özeti hazırlar, kernel hatalarını da içerir.

# Logwatch kurulumu
apt install logwatch  # Debian/Ubuntu
yum install logwatch  # RHEL/CentOS

# Manuel calistirma
logwatch --detail High --service kernel --range today

grep ve awk kombinasyonu ile gelişmiş analizler yapabilirsiniz:

# Hangi hata en cok tekrar ediyor
grep "error" /var/log/kern.log | awk '{print $6,$7,$8}' | sort | uniq -c | sort -rn | head -20

# Saatlik hata dagilimi
grep "error" /var/log/kern.log | awk '{print $3}' | cut -d: -f1 | sort | uniq -c

# Belirli bir surucu hatasini say
grep -c "e1000e.*error" /var/log/kern.log

ausearch: Audit log’ları ile kernel log’larını ilişkilendirmek için kullanılır.

# Guvenlik olaylarini kernel loglarıyla karsilastir
ausearch -m avc -ts today 2>/dev/null | head -30

Log Rotasyonu ve Saklama Politikası

Kernel log’larının düzgün rotasyona alınması disk yönetimi açısından önemlidir.

# Mevcut logrotate yapilandirmasini kontrol et
cat /etc/logrotate.d/rsyslog

# kern.log icin ozel rotasyon ayari ornegi
cat > /etc/logrotate.d/kern << 'EOF'
/var/log/kern.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
EOF

# Logrotate'i test et (dry-run)
logrotate -d /etc/logrotate.d/kern

Gerçek Dünya Senaryosu: Periyodik Sistem Yavaşlaması

Diyelim ki kullanıcılar her gün sabah 10:00 ile 11:00 arasında sistemin yavaşladığını bildiriyor. Adım adım araştıralım:

# Once bu zaman araligindaki kernel mesajlarina bak
grep "Jan 15 10:" /var/log/kern.log | grep -v "^$"

# OOM mu yoksa baska bir sey mi
grep "Jan 15 10:" /var/log/kern.log | grep -i "oom|memory|killed"

# CPU throttling var mi (termal sorun)
grep "Jan 15 10:" /var/log/kern.log | grep -i "thermal|temperature|throttl|scaling"

# Disk I/O doygunlugu
grep "Jan 15 10:" /var/log/kern.log | grep -i "I/O error|cfq|blkio"

# dmesg'den de kontrol et
dmesg -T | awk '/Jan 15 10:00/,/Jan 15 11:00/' | grep -i "error|warn|throttl"

Bu araştırma sürecinde şöyle bir pattern buldunuz diyelim:

Jan 15 10:15:33 server01 kernel: CPU1: Package temperature above threshold, cpu clock throttled
Jan 15 10:15:34 server01 kernel: CPU0: Package temperature above threshold, cpu clock throttled  
Jan 15 10:32:11 server01 kernel: CPU1: Temperature/speed normal

Bu, termal bir sorun. Sunucunun fiziksel konumu, fan durumu, soğutma sistemi kontrol edilmeli. Belki sabah 10:00’da ofisteki klima çalışmaya başlıyor ve sunucu odasına sıcak hava veriyor, ya da sunucu fanları tıkalı.

Kernel Log İzleme İçin Alarm Sistemi Kurmak

Kritik kernel olayları için anlık bildirim almak her sysadmin’in hayatını kolaylaştırır.

#!/bin/bash
# kernel_alert.sh - Kritik kernel hatalarinda bildirim gonder

ALERT_PATTERNS="out of memory|kernel panic|hardware error|machine check|I/O error"
LOG_FILE="/var/log/kern.log"
ALERT_EMAIL="[email protected]"
HOSTNAME=$(hostname)

# Son 5 dakikadaki loglara bak
RECENT_ERRORS=$(journalctl -k --since "5 minutes ago" -p err | grep -iE "$ALERT_PATTERNS")

if [ -n "$RECENT_ERRORS" ]; then
    echo "$RECENT_ERRORS" | mail -s "KRITIK: Kernel Hatasi - $HOSTNAME" $ALERT_EMAIL
    logger -t kernel_monitor "Kritik kernel hatasi tespit edildi, alarm gonderildi"
fi

Bu script’i 5 dakikada bir cron’a ekleyerek kernel sorunlarını anında öğrenebilirsiniz.

*/5 * * * * /usr/local/bin/kernel_alert.sh

Sonuç

Kernel log analizi, sistem yönetiminin en kritik becerilerinden biridir. dmesg ve /var/log/kern.log birlikte kullanıldığında, sisteminizde olup biten her şeyi anlayabilir, sorunları proaktif olarak tespit edebilir ve ciddi arızaları önleyebilirsiniz.

Önemli noktalara değinmek gerekirse: dmesg -HTL komutu günlük kullanım için başlangıç noktanız olmalı. Kritik hata seviyelerini mutlaka filtreleyin, her şeyi okumaya çalışmayın. /var/log/kern.log ve journalctl -k geçmişe bakmak için vazgeçilmez. OOM, disk hataları ve MCE olaylarına özellikle dikkat edin. Otomatik kontrol script’leri ve cron job’ları ile izlemeyi rutin hale getirin.

Bir sysadmin olarak bu log’ları düzenli olarak inceleme alışkanlığı edindiğinizde, sorunlar sizi bulmadan önce siz sorunları bulursunuz. Kernel log’ları yalan söylemez, sadece doğru sorular sormayı bilmek gerekir.

Similar Posts

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir