LINUX LOGLAMA VE JOURNALCTL

Yaygın bir yanılgı var: "journalctl sadece systemd servislerinin logunu gösterir" deniyor ve iş /var/log/syslog taramasına dönüyor. Oysa journal; kernel mesajlarını, boot kayıtlarını, audit alanlarını, servis çıktılarını ve uygulama tarafından yazılmış yapılandırılmış (structured) alanları aynı zaman çizelgesinde tutar. Bu yanılgıyı düzeltmek, hata ayıklama süresini ciddi biçimde kısaltır.

1. journalctl Aslında Neyi Toplar?

systemd-journald, çekirdek halka tamponundan (kmsg), syslog soketinden, stdout/stderr akışlarından ve sd_journal_send() API'sinden gelen veriyi tek bir ikili (binary) depoya yazar. Bu yüzden journal yalnızca bir "servis log görüntüleyici" değil; sistem genelinde merkezi bir kayıt katmanıdır.

• Kernel mesajları (dmesg ile aynı kaynak)
• Erken boot (initrd) kayıtları
• systemd unit stdout/stderr çıktıları
• Syslog uyumlu uygulama mesajları
• Yapılandırılmış alanlar (PRIORITY, _PID, _UID, _SYSTEMD_UNIT, MESSAGE_ID)

2. Boot Log: Sadece "Bu Açılışı" Değil, Geçmişi de

Bir sunucu beklenmedik şekilde yeniden başladıysa dünkü açılışın çekirdek paniğini görmek istersiniz. journalctl -b -1 bir önceki açılışı, journalctl --list-boots ise tüm kayıtlı açılışları gösterir. Bu, klasik dmesg'in veremediği bir geriye dönük görünürlük sunar.

Örnek kullanım:

• journalctl -b 0 — mevcut boot
• journalctl -b -2 -p err — iki önceki açılıştaki hata seviyesi ve üstü
• journalctl -k -b -1 — bir önceki boot'un yalnızca kernel mesajları

3. Structured Field'lar: grep'ten Vazgeçmek

Geleneksel log dosyalarında grep "sshd" yaparsınız; ama "sshd" kelimesi mesajın içinde geçen başka bir satıra da takılır. Journal, her kaydı alanlarla saklar. Yani PID, UID, cgroup, unit adı ve öncelik düzeyi metinden değil alandan filtrelenir.

Birkaç pratik filtre:

• journalctl _SYSTEMD_UNIT=nginx.service — sadece nginx unit'i
• journalctl _UID=1000 _COMM=python3 — belirli kullanıcının python süreçleri
• journalctl PRIORITY=3 — sadece "err" seviyesi
• journalctl --since "2 hours ago" --until "10 min ago"
• journalctl -o json-pretty — tüm alanları JSON çıktısı olarak görmek

Yapısal alanları tanımak, log inceleme alışkanlığını kökten değiştirir; tüm filtre anahtarlarının ve alan adlarının ayrıntılı dökümünü resmi kılavuz sayfasında bulabilirsiniz; ardından jq veya bir SIEM ile entegrasyon doğal bir adım haline gelir.

4. Persistent Storage: Reboot'tan Sonra Kayıp Olmasın

Birçok dağıtımda journal varsayılan olarak /run/log/journal altında, yani RAM'de tutulur ve reboot sonrası kaybolur. Bu davranış kasıtlıdır ama post-mortem inceleme yapacaksanız işinize gelmez. Kalıcı depolamayı açmak için:

1. /etc/systemd/journald.conf dosyasında Storage=persistent ayarını yapın.
2. /var/log/journal dizinini oluşturun: mkdir -p /var/log/journal
3. systemd-tmpfiles --create --prefix /var/log/journal ile izinleri düzenleyin.
4. systemctl restart systemd-journald ile servisi yeniden başlatın.

Boyut kontrolü için SystemMaxUse=2G, SystemKeepFree=500M ve MaxRetentionSec=30day gibi anahtarları kullanabilirsiniz. Kalıcı log, "olay sonrası" analizde altın değerindedir.

5. Performans ve Disk Yönetimi

Journal binary olduğu için sıkıştırılmış indekslerle hızlıdır; ancak diskte yer kaplar. Mevcut kullanımı görmek için journalctl --disk-usage, geçmiş kayıtları daraltmak için journalctl --vacuum-time=14d veya journalctl --vacuum-size=1G komutları işe yarar. Cron veya systemd timer ile periyodik vakum, disk doluluğunu önler.

6. rsyslog ile Birlikte mi, Tek Başına mı?

Bazı kurumsal ortamlarda rsyslog hâlâ standarttır: merkezi log sunucusuna TCP/UDP üzerinden iletim, dosya bazlı arşiv ve eski araç zinciri korunabilir. systemd-journald, ForwardToSyslog=yes ile rsyslog'a feed verir. İkisi rakip değil, katman arkadaşıdır:

• journald → yerel, yapısal, hızlı sorgu
• rsyslog → uzak iletim, dosya rotasyonu, eski sistem uyumu

Linux altyapı yönetimi ve sistem yönetimi yetkinliklerinizi derinleştirmek için kapsamlı Linux eğitimi içeriğinden yararlanabilirsiniz; loglama, servis kontrolü ve sorun giderme pratikleri orada bir bütün halinde işleniyor.

7. Sık Kullanılan Komut Özeti

• journalctl -f — canlı takip (tail -f benzeri)
• journalctl -u ssh -p warning..err — ssh servisinde uyarı-hata aralığı
• journalctl --grep="Failed password" — mesaj içinde regex
• journalctl --verify — journal dosyalarının bütünlüğünü doğrula
• journalctl _TRANSPORT=kernel — yalnızca kernel kaynaklı kayıtlar

8. Pratik Bir Çalışma Akışı

Bir olayda izleyebileceğiniz tipik akış şudur: önce journalctl --list-boots ile hangi açılışta olduğunu konumlandırın; ardından ilgili unit'i -u ile daraltın; ardından -p ile öncelik süzgeci uygulayın; son olarak -o json çıktısını jq ile alanlar üzerinden işleyin. Bu sıralama, "log denizinde arama" hissini, "sorgu yazma" disiplinine dönüştürür.

journalctl'i "systemd servis çıktısı görüntüleyici" diye sınırlandırmak, Linux'un sunduğu en güçlü inceleme katmanlarından birini yarı boş bırakmaktır. Boot tarihçesi, kernel kanalı, yapılandırılmış alanlar ve kalıcı depolama birlikte düşünüldüğünde, sistem yönetiminde reaktif olmaktan çıkıp olay öncesi sinyalleri yakalayabilecek konuma geçersiniz. Daha geniş Linux yönetim becerileri için Linux eğitimi içeriklerini inceleyebilirsiniz.