Linux Loglama Mimarisi: Syslog, Rsyslog ve Journald

Bir sunucuda bir şeyler ters gittiğinde, genellikle ilk başvurduğun yer log dosyalarıdır. Ama çoğu sysadmin “loglar nerede?” sorusuna /var/log/syslog ya da /var/log/messages diyerek geçiştiriyor. Oysa Linux loglama mimarisi bundan çok daha derinlikli ve ilginç bir ekosistem. Bu yazıda syslog’dan rsyslog’a, oradan modern systemd dünyasının getirdiği journald’ye uzanan loglama mimarisini hem teorik hem de pratik açıdan ele alacağız.

Linux Loglama: Nereden Nereye Geldik

Loglama Unix tarihinin neredeyse başından beri var. İlk syslog implementasyonu 1980’lerin başında sendmail projesi içinde doğdu ve zamanla bağımsız bir sistem servisine dönüştü. Temel fikir son derece basitti: uygulamalar log mesajlarını standart bir sokete (/dev/log) yazar, merkezi bir daemon bu mesajları alır ve uygun dosyalara yazar.

Bu mimarinin güzel yanı modülerliğiydi. Uygulama geliştiricileri log rotasyonuyla, dosya izinleriyle uğraşmak zorunda değildi. Sadece mesajı gönderirdi, gerisini syslog hallederdi.

Ama zamanla ihtiyaçlar değişti. Yüksek hacimli log trafiği, yapılandırılmış loglama gereksinimleri, güvenlik ihtiyaçları ve merkezi log yönetimi… Bunların hepsi syslog’un yetersiz kaldığı alanlar oldu. İşte bu noktada rsyslog ve sonrasında journald sahneye çıktı.

Syslog: Temel Kavramlar

Syslog’u anlamak için iki temel kavramı bilmen gerekiyor: facility ve severity.

Facility, log mesajının hangi sistemden geldiğini belirtir:

• kern: Kernel mesajları
• user: Kullanıcı seviyesi mesajlar
• mail: Mail sistemi
• daemon: Sistem daemon’ları
• auth: Güvenlik ve kimlik doğrulama
• syslog: syslogd’nin kendi mesajları
• lpr: Yazıcı sistemi
• local0 – local7: Özel kullanım için ayrılmış 8 facility

Severity ise mesajın önem seviyesini belirtir, 0’dan 7’ye doğru azalan önem sırasıyla:

• emerg (0): Sistem kullanılamaz
• alert (1): Hemen müdahale gerekiyor
• crit (2): Kritik durum
• err (3): Hata
• warning (4): Uyarı
• notice (5): Normal ama dikkat gerektiren durum
• info (6): Bilgi mesajı
• debug (7): Debug bilgisi

Bir log mesajının facility ve severity kombinasyonu priority değerini oluşturur. Örneğin auth.warning, kimlik doğrulama sisteminden gelen uyarı seviyesinde bir mesajdır.

rsyslog: Syslog’un Güçlü Halefi

Büyük çoğunluk sistemde artık syslog değil rsyslog çalışıyor. rsyslog, “rocket-fast system for log processing” kelimelerinin kısaltması. İsmi biraz iddialı gelse de gerçekten de klasik syslog’dan çok daha yetenekli.

rsyslog Yapılandırması

rsyslog’un ana yapılandırma dosyası /etc/rsyslog.conf‘tur. Modern sistemlerde ise /etc/rsyslog.d/ dizini altındaki parçalı dosyalar kullanılır.

# rsyslog servisini kontrol et
sudo systemctl status rsyslog

# Yapılandırma dosyasını görüntüle
cat /etc/rsyslog.conf

# Ek yapılandırma dosyalarını listele
ls -la /etc/rsyslog.d/

Temel bir rsyslog kuralı şu yapıdadır: facility.severity hedef

# /etc/rsyslog.d/50-default.conf içinde tipik kurallar
# Tüm auth mesajlarını auth.log'a yaz
auth,authpriv.*     /var/log/auth.log

# Kernel mesajları
kern.*              /var/log/kern.log

# Tüm warning ve üzeri mesajları syslog'a yaz
*.warn              /var/log/syslog

# Mail logları ayrı dosyaya
mail.*              -/var/log/mail.log

# Crit ve üzeri her şeyi hem dosyaya hem konsola yaz
*.crit              /var/log/critical
*.crit              /dev/console

Buradaki -/var/log/mail.log ifadesindeki tire işareti önemli: her yazıştan sonra dosyayı senkronize etme, önbelleğe al anlamına geliyor. Mail gibi yoğun log üreten sistemler için performans açısından kritik.

rsyslog ile Uzak Log Sunucusuna Gönderim

Gerçek dünya senaryosu: 20 sunucun var ve hepsinin loglarını merkezi bir yerde toplamak istiyorsun. rsyslog bu iş için biçilmiş kaftan.

Önce log sunucusu tarafında TCP dinlemeyi aktifleştir:

# /etc/rsyslog.conf içinde log sunucusu yapılandırması
# TCP üzerinden log al (port 514)
module(load="imtcp")
input(type="imtcp" port="514")

# Gelen logları host adına göre ayrı dosyalara yaz
template(name="RemoteLogs" type="string"
         string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")

*.* ?RemoteLogs

Sonra gönderen sunucularda:

# /etc/rsyslog.d/90-forward.conf
# Tüm logları merkezi sunucuya TCP ile ilet
*.* @@192.168.1.100:514

# Sadece belirli severity'yi ilet
*.warning @@log-server.iç.ağ:514

# TLS ile şifreli iletim için
action(type="omfwd"
       target="log-server.iç.ağ"
       port="6514"
       protocol="tcp"
       StreamDriver="gtls"
       StreamDriverMode="1"
       StreamDriverAuthMode="x509/name")

Değişiklikten sonra servisini yeniden yükle:

sudo systemctl restart rsyslog
# Yapılandırma hatası var mı kontrol et
sudo rsyslogd -N1

rsyslog Filtreler ve Dönüşümler

rsyslog’un gerçek gücü mesajları filtreleyip dönüştürebilmesinde. Diyelim ki bir uygulama çok fazla gereksiz debug mesajı üretiyor ve bunları log dosyalarına almak istemiyorsun:

# /etc/rsyslog.d/30-filters.conf

# myapp'tan gelen debug mesajlarını çöpe at
if $programname == 'myapp' and $syslogseverity == 7 then stop

# Belirli IP'den gelen mesajları ayrı dosyaya yönlendir
if $fromhost-ip == '10.0.0.50' then /var/log/app-server.log

# Property-based filtre: mesaj içinde "CRITICAL" geçiyorsa alarm ver
:msg, contains, "CRITICAL" /var/log/critical-alerts.log
:msg, contains, "CRITICAL" | /usr/local/bin/send-alert.sh

journald: Modern Yaklaşım

systemd ile birlikte gelen journald, geleneksel metin tabanlı loglama anlayışını tamamen değiştirdi. journald mesajları ikili (binary) formatta, yapılandırılmış şekilde saklar. Bu başlangıçta “neden?” sorusunu akla getiriyor ama avantajları bir kez görünce anlıyorsun.

journald’nin temel farklılıkları:

• Yapılandırılmış metadata: Her log girişi onlarca field içerebilir
• Kernel ve userspace entegrasyonu: Tek yerden her şeyi görebilirsin
• Hızlı sorgulama: İkili format sayesinde büyük log setlerinde bile hızlı arama
• Güvenli saklama: Forward Secure Sealing ile log manipülasyonunu tespit edebilme
• Otomatik rotation: Disk kullanımına göre otomatik yönetim

journalctl ile Çalışmak

journalctl komutu journald loglarını sorgulamak için kullanılır. Başlangıçta biraz yadırgayıcı gelse de hızla alışıyorsun:

# Son logları göster (tail gibi)
journalctl -n 50

# Canlı takip (tail -f gibi)
journalctl -f

# Belirli servisin logları
journalctl -u nginx.service
journalctl -u nginx.service -f

# Belirli zaman aralığı
journalctl --since "2024-01-15 10:00:00" --until "2024-01-15 11:00:00"
journalctl --since "1 hour ago"
journalctl --since today

# Öncelik seviyesine göre filtrele (0-7 veya isim)
journalctl -p err
journalctl -p warning..crit

# Kernel mesajları (dmesg alternatifi)
journalctl -k

# Boot mesajları
journalctl -b        # Mevcut boot
journalctl -b -1     # Bir önceki boot
journalctl --list-boots  # Tüm boot geçmişi

journalctl ile Gelişmiş Sorgular

Gerçek bir troubleshooting senaryosu: Sabah geldin, disk dolmuş alarm gelmiş. Gece ne oldu?

# Gece yarısından sabah 6'ya kadar olan kritik mesajlar
journalctl --since "2024-01-15 00:00:00" --until "2024-01-15 06:00:00" -p crit

# Belirli kullanıcının tetiklediği mesajlar
journalctl _UID=1000

# Belirli process ID'nin mesajları
journalctl _PID=1234

# Belirli executable'ın mesajları
journalctl _EXE=/usr/sbin/sshd

# JSON formatında çıktı (log analiz araçlarına göndermek için)
journalctl -u sshd -o json-pretty | head -50

# Disk kullanımını göster
journalctl --disk-usage

# Belirli bir kata kadar logları temizle
journalctl --vacuum-size=500M
journalctl --vacuum-time=30days

journald Yapılandırması

journald’nin yapılandırma dosyası /etc/systemd/journald.conf‘tur:

# /etc/systemd/journald.conf örnek yapılandırması
[Journal]
# Logları diske yaz (persistent), varsayılan auto
Storage=persistent

# Maksimum disk kullanımı
SystemMaxUse=2G
SystemKeepFree=500M

# Sıkıştırma
Compress=yes

# Forward to syslog (rsyslog ile birlikte kullanım için)
ForwardToSyslog=yes

# Rate limiting - burst içinde max kaç mesaj
RateLimitIntervalSec=30s
RateLimitBurst=10000

# Maksimum log dosyası boyutu
SystemMaxFileSize=100M

Değişiklik sonrası:

sudo systemctl restart systemd-journald
# Ya da sadece yeniden yükle
sudo kill -USR1 $(pidof systemd-journald)

journald ve rsyslog Birlikte Kullanım

Önemli bir nokta: journald ve rsyslog birbirinin rakibi değil, tamamlayıcısı. Çoğu modern sistemde ikisi birlikte çalışır.

journald’nin ForwardToSyslog=yes ayarı ile mesajlar rsyslog’a da iletilir. Bu sayede hem journald’nin yapılandırılmış sorgu avantajından yararlanabilir, hem de rsyslog’un güçlü yönlendirme özelliklerini kullanabilirsin.

Pratikte bu şöyle görünür:

# Servis loglarını hem journald hem rsyslog üzerinden görebilirsin
journalctl -u myapp.service
tail -f /var/log/myapp.log  # rsyslog'un yazdığı dosya

# journald'dan rsyslog'a iletim durumunu kontrol et
systemctl status systemd-journald
cat /etc/systemd/journald.conf | grep ForwardToSyslog

Gerçek Dünya Senaryosu: SSH Brute Force Tespiti

Diyelim ki sunucunda SSH brute force saldırısı şüphesi var. Önce hızlı kontrol:

# journalctl ile başarısız SSH denemelerini bul
journalctl -u sshd --since "24 hours ago" | grep "Failed password" | wc -l

# Hangi IP'lerden saldırı geliyor?
journalctl -u sshd --since "24 hours ago" | grep "Failed password" 
  | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

# rsyslog ile daha detaylı analiz (eğer auth.log varsa)
grep "Failed password" /var/log/auth.log | 
  awk '{print $11}' | sort | uniq -c | sort -rn | head -20

# Başarılı loginleri de kontrol et - beklenmedik login var mı?
journalctl -u sshd --since "7 days ago" | grep "Accepted"

Bu bilgilerle fail2ban veya iptables ile engelleyebilirsin. Ama önemli olan bu logları zamanında görebilmek. İşte burada merkezi loglama ve alert sistemi devreye giriyor.

Log Rotasyonu ile Entegrasyon

rsyslog loglarının sonsuza dek büyümemesi için logrotate ile entegrasyon şart:

# /etc/logrotate.d/rsyslog örneği
/var/log/syslog
/var/log/kern.log
/var/log/auth.log
{
    rotate 7
    daily
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

# Rotasyonu manuel test et
sudo logrotate --debug /etc/logrotate.d/rsyslog

# Force rotation (test için)
sudo logrotate --force /etc/logrotate.conf

Performans ve Sorun Giderme

Bir noktada rsyslog ya da journald performans sorunu çıkarabilir. Bu durumda neye bakacağını bilmek lazım:

# rsyslog'un CPU/bellek kullanımı
ps aux | grep rsyslog
systemctl status rsyslog

# rsyslog istatistiklerini etkinleştir
# /etc/rsyslog.conf'a ekle:
module(load="impstats" interval="60" severity="7")
*.=debug /var/log/rsyslog-stats.log

# journald disk I/O durumu
iostat -x 1 5  # disk aktivitesini izle
journalctl --disk-usage

# Log flood durumunda rate limiting kontrol
journalctl -p warning --since "1 hour ago" | grep "rate limit"

# rsyslog'da kuyruklama sorunları için
# /etc/rsyslog.conf'da queue ayarları
main_queue(
    queue.type="LinkedList"
    queue.size="50000"
    queue.dequeuebatchsize="1000"
    queue.saveonshutdown="on"
)

Yapılandırılmış Loglama: Geleceğe Hazırlanmak

Modern uygulamalar giderek daha fazla yapılandırılmış log (JSON formatında) üretiyor. journald bu konuda doğal bir avantaja sahip, ama rsyslog da bunu destekliyor:

# rsyslog ile JSON formatında log oluşturma
template(name="JsonFormat" type="list") {
    constant(value="{")
    constant(value=""timestamp":"")   property(name="timereported" dateFormat="rfc3339")
    constant(value="","host":"")     property(name="hostname")
    constant(value="","severity":"") property(name="syslogseverity-text")
    constant(value="","program":"")  property(name="programname")
    constant(value="","message":"")  property(name="msg" format="json")
    constant(value=""}n")
}

# Bu template'i kullanarak yaz
*.* action(type="omfile" file="/var/log/structured.log" template="JsonFormat")

Bu yapılandırılmış logları Elasticsearch’e, Loki’ye ya da başka bir log aggregation sistemine göndermek çok daha kolay oluyor.

Güvenlik: Log Bütünlüğü

Loglar bir saldırı sonrasında ilk silinmeye ya da değiştirilmeye çalışılan şeylerdir. Buna karşı birkaç önlem:

• journald Forward Secure Sealing: Log manipülasyonunu kriptografik olarak tespit eder
• Uzak log sunucusu: Logları gerçek zamanlı başka bir sunucuya ilet. Saldırgan lokal logu silebilir ama uzaktakini silemez
• rsyslog TLS: Log iletimini şifrele, ortadaki adam saldırısını engelle
• Dosya izinleri: Log dosyalarına yalnızca root ve log grubunun yazmasına izin ver

# journald için sealing etkinleştir
journalctl --setup-keys

# Log dosyası izinlerini kontrol et
ls -la /var/log/auth.log
# Çıktı: -rw-r----- 1 syslog adm

# Log grubuna kullanıcı ekle (okuma erişimi için)
sudo usermod -aG adm sysadminuser

Sonuç

Linux loglama mimarisi, ilk bakışta karmaşık görünse de aslında birbirini tamamlayan katmanlardan oluşuyor. syslog, temel kavramları ve protokolü tanımladı. rsyslog, bu temeli alıp üstüne güçlü filtreleme, yönlendirme ve performans özellikleri inşa etti. journald ise yapılandırılmış, sorgulanabilir ve modern bir log depolama katmanı getirdi.

Günlük hayatta en pratik yaklaşım şu: Hızlı sorun araştırması için journalctl, uzun vadeli saklama ve merkezi loglama için rsyslog, uyarı ve analiz için ise ikisinin üstüne oturan araçlar (Grafana Loki, ELK Stack, Graylog) kullan.

Logları doğru yapılandırmak zahmetli görünebilir, ama bir kriz anında “loglar nerede?” yerine “şu anda bakıyorum” diyebilmek… İşte o an bu yazıya harcadığın zamanın değerini anlıyorsun.