journalctl yalnızca systemd servislerinin loglarını mı gösterir?

Hayır. journald; kernel halka tamponunu, syslog soketini, servis stdout/stderr akışlarını ve uygulamaların sd_journal_send API'si ile yazdığı yapılandırılmış kayıtları tek depoda toplar. Bu nedenle dmesg çıktısı, audit benzeri alanlar ve uygulama logları da journalctl üzerinden sorgulanır.

Reboot sonrasında journal kayıtları neden kayboluyor?

Birçok dağıtımda varsayılan depolama 'volatile' olup /run/log/journal altında, yani RAM'de tutulur. Kalıcı tutmak için /etc/systemd/journald.conf içinde Storage=persistent ayarlanır, /var/log/journal dizini oluşturulur ve systemd-journald yeniden başlatılır. Bundan sonra kayıtlar reboot'tan sağ çıkar.

Önceki açılışın kernel mesajlarını nasıl görebilirim?

Persistent storage açıkken journalctl --list-boots ile mevcut boot listesi alınır. Ardından journalctl -k -b -1 komutu bir önceki açılışın yalnızca kernel mesajlarını gösterir. -b -2, -b -3 gibi negatif indekslerle daha eski açılışlara ulaşılabilir.

Structured field filtrelemenin grep'e göre avantajı nedir?

grep mesajın metin içeriğine bakar ve yanlış pozitif üretebilir. Journal alanları (_SYSTEMD_UNIT, _PID, _UID, PRIORITY, _TRANSPORT) doğrudan kayıt meta verisinden sorgulanır. Bu sayede 'nginx unit'inin err seviyesindeki kayıtları' gibi kesin sorgular yapılır ve sonuçlar gürültüsüz döner.

Journal disk kullanımını nasıl sınırlandırırım?

journald.conf içinde SystemMaxUse, SystemKeepFree ve MaxRetentionSec parametreleri belirlenir. Anlık disk kullanımı journalctl --disk-usage ile görülür. Mevcut kayıtları daraltmak için journalctl --vacuum-time=14d veya --vacuum-size=1G komutları kullanılabilir.

rsyslog kullanırken journald'a ihtiyacım var mı?

İki katman birbirini tamamlar. journald yerel, hızlı ve yapısal sorgular için idealdir; rsyslog ise merkezi log sunucusuna iletim, dosya rotasyonu ve eski araç uyumu sağlar. journald'ın ForwardToSyslog=yes ayarıyla kayıtlar rsyslog'a aktarılır.

journalctl çıktısını otomasyona nasıl bağlarım?

journalctl -o json veya -o json-pretty çıktısı her kaydı alan bazlı JSON olarak verir. Bu çıktı jq ile filtrelenebilir, bir HTTP toplayıcıya gönderilebilir veya SIEM uçlarına iletilebilir. --since/--until ile zaman pencereli toplu dışa aktarımlar da kolayca planlanır.

Journal dosyalarının bozulup bozulmadığını nasıl anlarım?

journalctl --verify komutu mevcut journal dosyalarının iç bütünlüğünü kontrol eder ve bozuk ya da kesilmiş segmentleri raporlar. Düzenli yedekleme ve vakum politikasıyla birlikte bu doğrulama, post-mortem analiz öncesi log güvenilirliğini teyit etmek için kullanılır.

LINUX LOGLAMA VE JOURNALCTL

Linux journalctl log akışı ve filtreleme hunisi ile structured field tabanlı sistem günlüğü sorgulama

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.

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)

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ı

journalctl boot oturumları zaman çizelgesi ve önceki açılışların kernel mesajları için filtreleme

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.

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:

/etc/systemd/journald.conf dosyasında Storage=persistent ayarını yapın.
/var/log/journal dizinini oluşturun: mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal ile izinleri düzenleyin.
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.

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.

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.

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

journalctl persistent storage disk depolama ve vacuum politikası ile boyut sınırlandırma yapılandırması

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.