Sisteminiz yeniden başladıktan sonra logların uçup gittiğini fark ettiğinizde, tam da bir sorunu araştırıyorken, o his gerçekten sinir bozucu. Varsayılan journald yapılandırmasında loglar RAM’de tutulur ve sistem yeniden başlayınca her şey sıfırlanır. Üretim ortamında bu kabul edilemez bir durum. Bu yazıda journald’ı kalıcı log saklama için nasıl yapılandıracağınızı, nelere dikkat etmeniz gerektiğini ve gerçek dünya senaryolarında nasıl kullanacağınızı detaylıca anlatacağım.
journald Neden Varsayılan Olarak Kalıcı Değil?
systemd-journald, sistem loglarını yapılandırılmış bir binary formatta saklar. Bu format, klasik syslog’a göre sorgulama açısından çok daha güçlüdür. Ancak kurulum sonrası varsayılan davranış, /run/log/journal/ dizinini kullanmaktır. Bu dizin tmpfs üzerinde çalışır yani tamamen RAM tabanlıdır.
Bu tasarım kararının arkasında birkaç neden var. Birincisi, disk alanı konusunda agresif varsayımlar yapmamak. İkincisi, gömülü sistemler veya containerlar gibi ortamlarda kalıcı depolama her zaman istenmez. Üçüncüsü ise sistem loglarının ayrı bir log yönetim sistemi tarafından işlenmesi beklentisi.
Kalıcı loglama aktif hale geldiğinde ise loglar /var/log/journal/ altına yazılır ve yeniden başlatmalar arasında korunur. Bu geçişi yapmak için bazı şeyler bilmeniz gerekiyor.
Kalıcı Loglama Nasıl Aktif Edilir?
Dizin Oluşturarak Aktif Etme
En basit yöntem, journald’ın otomatik olarak tanıyacağı dizini oluşturmak. journald, /var/log/journal/ dizini varsa otomatik olarak kalıcı moda geçer.
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journaldDizini oluşturduktan sonra journald’ı yeniden başlatmanız gerekiyor. Aksi halde mevcut oturum için eski davranış devam eder.
Dizinin sahipliğini kontrol edelim:
ls -la /var/log/journal/Bu dizinin altında makine ID’sine göre bir alt dizin oluşur. Örneğin:
drwxr-sr-x+ 2 root systemd-journal 4096 Oca 15 10:23 /var/log/journal/
drwxr-sr-x+ 2 root systemd-journal 4096 Oca 15 10:23 /var/log/journal/a1b2c3d4e5f6...journald.conf Üzerinden Yapılandırma
Daha kontrollü bir yaklaşım için ana yapılandırma dosyasını düzenleyin:
sudo nano /etc/systemd/journald.confTemel kalıcı loglama için şu satırları ekleyin veya düzenleyin:
[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=2G
SystemKeepFree=500M
SystemMaxFileSize=200M
MaxRetentionSec=3monthDeğişiklikleri uygulamak için:
sudo systemctl restart systemd-journaldYapılandırmanın aktif olduğunu doğrulayın:
journalctl --disk-usagejournald.conf Parametrelerini Anlamak
Ana yapılandırma dosyasındaki önemli parametreler şunlardır:
Storage: Log saklama yerini belirler. volatile RAM’de tutar, persistent diske yazar, auto dizin varsa diske yazar yoksa RAM’e geçer, none tüm logları atar.
Compress: Binary log dosyalarında sıkıştırma kullanılıp kullanılmayacağı. yes olarak ayarlandığında disk kullanımı önemli ölçüde azalır.
SystemMaxUse: Sistem loglarının (root altındaki) kullanabileceği maksimum disk alanı. Örneğin 2G, 500M gibi değerler alır.
SystemKeepFree: Sistemde her zaman boş bırakılacak minimum disk alanı. Bu limit aşılmaya başlayınca eski loglar temizlenir.
SystemMaxFileSize: Tek bir journal dosyasının maksimum boyutu. Bu değer aşıldığında yeni bir dosya başlatılır.
SystemMaxFiles: Saklanacak maksimum journal dosyası sayısı.
MaxRetentionSec: Logların maksimum saklama süresi. 1week, 2month, 1year gibi değerler kullanılabilir.
MaxFileSec: Tek bir journal dosyasının kapsayacağı maksimum zaman aralığı.
RateLimitIntervalSec: Rate limiting için zaman aralığı.
RateLimitBurst: Belirtilen süre içinde kabul edilecek maksimum log mesajı sayısı.
ForwardToSyslog: Logların syslog’a da iletilip iletilmeyeceği. rsyslog veya syslog-ng ile birlikte kullanıyorsanız dikkatli olun, çift loglama yaşanabilir.
ForwardToKMsg: Logların kernel mesaj tamponuna iletilip iletilmeyeceği.
Seal: Journal dosyalarının FSS (Forward Secure Sealing) ile imzalanıp imzalanmayacağı. Güvenlik açısından önemli.
Drop-in Yapılandırma Dosyaları Kullanımı
Ana yapılandırma dosyasını doğrudan düzenlemek yerine drop-in yapılandırma kullanmak çok daha iyi bir pratik. Bu sayede sistem güncellemelerinde varsayılan dosya değişse bile özelleştirmeleriniz korunur.
sudo mkdir -p /etc/systemd/journald.conf.d/
sudo nano /etc/systemd/journald.conf.d/99-persistent.confDosya içeriği:
[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=4G
SystemKeepFree=1G
SystemMaxFileSize=500M
MaxRetentionSec=6month
RateLimitIntervalSec=30s
RateLimitBurst=10000Bu yaklaşım özellikle configuration management araçları (Ansible, Puppet, Chef) kullanıyorsanız çok değerli. Ana dosyaya dokunmadan sadece ilgili parametreleri override edebilirsiniz.
Gerçek Dünya Senaryosu: Üretim Web Sunucusu
Diyelim ki 50+ container çalıştıran bir Kubernetes worker node’unuz var ve her gece reboot politikanız mevcut. Bu durumda varsayılan journald yapılandırması tamamen işe yaramaz.
Böyle bir ortam için örnek yapılandırma:
sudo nano /etc/systemd/journald.conf.d/99-production.conf[Journal]
Storage=persistent
Compress=yes
SystemMaxUse=8G
SystemKeepFree=2G
SystemMaxFileSize=1G
SystemMaxFiles=20
MaxRetentionSec=30day
MaxFileSec=1week
RateLimitIntervalSec=30s
RateLimitBurst=50000
ForwardToSyslog=no
Seal=yesBurada ForwardToSyslog=no önemli. Eğer hem journald hem de rsyslog çalışıyorsa ve forwarding açıksa loglar iki kez yazılır. Disk alanını gereksiz tüketirsiniz.
Seal=yes ise güvenlik açısından kritik. Forward Secure Sealing aktif olduğunda, eski journal dosyaları imzalanır ve geriye dönük log manipülasyonu tespit edilebilir hale gelir. Compliance gereksinimleri olan ortamlarda mutlaka kullanın.
Log Boyutlarını İzleme ve Yönetme
Kalıcı loglama aktif ettikten sonra düzenli izleme şart. Disk dolduğunda sistem sorunları yaşanabilir.
Mevcut disk kullanımını kontrol etmek için:
journalctl --disk-usageÇıktı şuna benzer:
Archived and active journals take up 3.2G in the file system.Daha detaylı bilgi için:
du -sh /var/log/journal/
du -sh /var/log/journal/*/*Logları manuel olarak temizlemek için çeşitli seçenekler var:
# Belirli bir boyutu aşan eski logları temizle
sudo journalctl --vacuum-size=1G
# Belirli bir tarihten eski logları temizle
sudo journalctl --vacuum-time=2weeks
# Belirli sayıda dosyadan fazlasını temizle
sudo journalctl --vacuum-files=10Bu komutları birleştirmek de mümkün:
sudo journalctl --vacuum-size=2G --vacuum-time=1monthReboot Sonrası Log Erişimi
Kalıcı loglama aktif olduktan sonra önceki boot oturumlarına ait loglara erişebilirsiniz. Bu özellikle bir sistem çökmesini araştırırken son derece değerli.
Mevcut boot oturumlarını listeleyin:
journalctl --list-bootsÇıktı örneği:
-3 a1b2c3d4... Mon 2024-01-13 09:15:22 TRT-Sun 2024-01-14 02:33:11 TRT
-2 e5f6g7h8... Sun 2024-01-14 08:44:55 TRT-Sun 2024-01-14 18:22:09 TRT
-1 i9j0k1l2... Sun 2024-01-14 18:23:41 TRT-Mon 2024-01-15 06:11:33 TRT
0 m3n4o5p6... Mon 2024-01-15 06:12:01 TRT-presentÖnceki boot’un loglarına erişmek için:
# Bir önceki boot
journalctl -b -1
# İki boot öncesi
journalctl -b -2
# Belirli bir boot ID ile
journalctl -b a1b2c3d4...Bir çökme anını araştırıyorsanız:
# Önceki boot'un son 100 satırı
journalctl -b -1 -n 100
# Önceki boot'ta kernel panikleri
journalctl -b -1 -k --priority=0..3
# Belirli bir servisin önceki boot logları
journalctl -b -1 -u nginx.serviceGerçek Dünya Senaryosu: Çökme Sonrası Forensik Analiz
Sabah 3’te telefon çalıyor, üretim veritabanı sunucusu düşmüş. Sistemi ayağa kaldırdınız ama ne olduğunu anlamanız lazım. Kalıcı loglama sayesinde şunu yapabilirsiniz:
# Sistemin çöktüğü andaki kernel mesajlarına bak
journalctl -b -1 -k --priority=0..4 --no-pager | tail -50
# OOM killer devreye girdi mi?
journalctl -b -1 --grep="Out of memory|oom_kill|Killed process"
# Belirli bir zaman aralığındaki tüm kritik loglar
journalctl -b -1 --since="03:00" --until="03:30" --priority=0..3
# Hangi servis çöktü?
journalctl -b -1 --grep="segfault|core dump|SIGSEGV"Bu komutlar olmadan sorunun kaynağını bulmak son derece güçleşirdi.
Kullanıcı Bazlı Loglama
journald sadece sistem loglarını değil, kullanıcı oturumu loglarını da yönetir. Kalıcı loglama aktif olduğunda kullanıcı logları için ayrı parametreler vardır.
[Journal]
Storage=persistent
RuntimeMaxUse=200M
RuntimeKeepFree=100M
RuntimeMaxFileSize=50MRuntime parametreleri /run/log/journal/ için geçerliyken System parametreleri /var/log/journal/ için geçerlidir.
Belirli bir kullanıcının loglarını görüntülemek için:
# Mevcut kullanıcı
journalctl --user
# Belirli bir kullanıcı (root gerektirir)
journalctl _UID=1000Remote Journal ile Merkezi Log Yönetimi
Büyük ortamlarda her sunucuya ayrı ayrı bağlanmak yerine merkezi bir log sunucusu kurmak isteyebilirsiniz. systemd-journal-remote ve systemd-journal-upload bu iş için tasarlanmış.
Log gönderen taraf (istemci) yapılandırması:
sudo apt install systemd-journal-remote
sudo nano /etc/systemd/journal-upload.conf[Upload]
URL=https://log-server.example.com:19532
ServerKeyFile=/etc/ssl/private/journal-upload.pem
ServerCertificateFile=/etc/ssl/certs/journal-upload.crt
TrustedCertificateFile=/etc/ssl/ca/trusted.crtsudo systemctl enable --now systemd-journal-uploadLog alan taraf (sunucu) yapılandırması:
sudo apt install systemd-journal-remote
sudo nano /etc/systemd/journal-remote.conf[Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/ssl/private/journal-remote.pem
ServerCertificateFile=/etc/ssl/certs/journal-remote.crt
TrustedCertificateFile=/etc/ssl/ca/trusted.crtsudo systemctl enable --now systemd-journal-remoteBu kurulum ile tüm sunucularınızın logları merkezi bir noktada toplanır ve merkezi sunucudaki kalıcı loglama yapılandırması sayesinde uzun süreli saklanabilir.
Log Rotasyonu ve Otomatik Temizlik
journald, log rotasyonunu ve temizliği otomatik olarak yönetir. Ancak bu işlemleri izlemek ve özelleştirmek gerekebilir.
Otomatik temizlik politikasını systemd timer ile uygulamak için:
sudo nano /etc/systemd/system/journal-cleanup.service[Unit]
Description=journald Log Temizleme
After=systemd-journald.service
[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-size=2G
ExecStart=/usr/bin/journalctl --vacuum-time=3monthssudo nano /etc/systemd/system/journal-cleanup.timer[Unit]
Description=Haftalik journald Log Temizleme
[Timer]
OnCalendar=weekly
Persistent=true
[Install]
WantedBy=timers.targetsudo systemctl enable --now journal-cleanup.timer
sudo systemctl status journal-cleanup.timerMonitoring ve Alerting Entegrasyonu
Disk kullanımı belirli bir eşiği geçtiğinde uyarı almak için basit bir script yazabilirsiniz:
sudo nano /usr/local/bin/journal-disk-check.sh#!/bin/bash
THRESHOLD_PERCENT=80
JOURNAL_PATH="/var/log/journal"
ALERT_EMAIL="[email protected]"
# Disk kullanim yuzdesini hesapla
DISK_USAGE=$(df -h "$JOURNAL_PATH" | awk 'NR==2 {gsub(/%/,""); print $5}')
if [ "$DISK_USAGE" -gt "$THRESHOLD_PERCENT" ]; then
echo "UYARI: $JOURNAL_PATH disk kullanimi %$DISK_USAGE seviyesinde!" |
mail -s "journald Disk Uyarisi - $(hostname)" "$ALERT_EMAIL"
# Kritik durumda otomatik temizlik yap
if [ "$DISK_USAGE" -gt 90 ]; then
journalctl --vacuum-size=1G
logger "journal-disk-check: Otomatik temizlik yapildi, disk dolulugu %$DISK_USAGE idi"
fi
fisudo chmod +x /usr/local/bin/journal-disk-check.shBunu bir cron job veya systemd timer ile düzenli çalıştırabilirsiniz.
Güvenlik ve Compliance Notları
Kalıcı loglar güvenlik açısından iki ucu keskin bir bıçak gibidir. Bir yandan forensik analiz için vazgeçilmezdir, öte yandan loglar içinde hassas bilgiler bulunabilir.
Dikkat edilmesi gereken noktalar:
/var/log/journal/dizinine erişim kontrolü kritik.systemd-journalgrubu üyeleri logları okuyabilir.- PCI-DSS veya HIPAA gibi compliance gereksinimleri 90 gün ile 1 yıl arasında log saklama zorunluluğu getirebilir.
MaxRetentionSecbuna göre ayarlanmalı. - Loglara yazılan parolalar, token’lar gibi hassas verilere dikkat edin. Uygulama loglarında hassas veri maskeleme uygulanmalı.
Seal=yesile log bütünlüğünü koruyun ve imzaları periyodik olarak doğrulayın.
Mevcut kullanıcıların hangi logları görebildiğini kontrol etmek için:
# systemd-journal grubuna kullanici ekle
sudo usermod -aG systemd-journal kullanici_adi
# Log erişim kontrolunu dogrula
journalctl --verifySonuç
journald’ın kalıcı log saklama yapılandırması, ciddi bir sistem yöneticisi için temel kurulum adımlarından biri olmalı. /var/log/journal/ dizinini oluşturmak veya Storage=persistent ayarını yapmak birkaç dakika alıyor, ancak sağladığı değer son derece büyük. Bir sistem çökmesinden sonra logların yerinde olması, sabah 3’teki panik anında gerçek bir kurtarıcı oluyor.
Yapılandırmayı yaparken şu noktalara özellikle dikkat edin: disk boyutuna göre SystemMaxUse ve SystemKeepFree değerlerini gerçekçi tutun, rate limiting ile log flooding’e karşı önlem alın, MaxRetentionSec ile saklama süresini compliance gereksinimlerinize göre ayarlayın. Üretim ortamında drop-in yapılandırma dosyaları kullanarak değişikliklerinizi sistem güncellemelerinden izole edin.
Merkezi log yönetimi ihtiyacınız varsa systemd-journal-remote entegrasyonunu değerlendirin. Elasticsearch veya Loki gibi çözümlerle entegrasyon için de journald mükemmel bir veri kaynağı. Loglarınız yerinde ve güvende olduğunda, sisteminizin davranışını anlamak çok daha kolay hale geliyor.