Linux'ta loglar: journalctl, /var/log, rsyslog ve logrotate

Bir servis gece çöktüğünde cevap neredeyse her zaman loglardadır; asıl soru nerede arayacağınızdır. Modern dağıtımlarda (Ubuntu, Debian, RHEL, Fedora, Arch) olayları journald servisi toplar, okumak için journalctl kullanılır. Buna paralel olarak birçok program /var/log altına düz metin dosyaları yazar ve bunların boyutunu logrotate denetler. Aşağıda Linux loglarını journalctl ile pratikte nasıl okuyacağınızı, diğer günlüklerin nerede durduğunu ve döndürme sırasında önemli bir şeyi nasıl kaybetmeyeceğinizi anlatıyoruz.

Linux'ta loglar nerede tutulur

Kaynak üçtür; bunları bir harita gibi akılda tutmak faydalıdır:

• journald — systemd'nin ikili (binary) günlüğü. Tüm servislerin stdout ve stderr çıktılarını, çekirdek mesajlarını ve syslog'u kabul eder. /var/log/journal/ altında kalıcı (/run/log/journal/ altında ise yeniden başlatmaya kadar) tutulur.
• /var/log — düz metin dosyaları. Bunları rsyslog (örneğin /var/log/syslog, /var/log/auth.log) veya nginx, PostgreSQL, MySQL gibi uygulamalar yazar.
• Çekirdek halka tamponu — sürücülerin ve donanımın mesajları; bunları dmesg veya journalctl -k gösterir.

/var/log içindeki dosyaların çoğu yalnızca root'a veya adm grubuna açıktır; bu yüzden okuma komutlarını sık sık sudo ile çalıştırmanız gerekir.

journalctl: temel komutlar

Argümansız journalctl, tüm günlüğü en eskiden en yeniye doğru less sayfalayıcısında gösterir. Bu nadiren gerekir — genellikle hemen daraltırsınız.

journalctl              # tüm günlük, eskiden yeniye
journalctl -e           # doğrudan sonda aç
journalctl -n 50        # son 50 satır
journalctl -r           # ters sırada, yeniler üstte
journalctl --no-pager   # less olmadan; betikler ve grep için uygun

Sayfalayıcının içinde tanıdık less tuşları çalışır: / — arama, G — sona git, q — çıkış. Uzun satırlar ekran genişliğine göre kesilir; sol ve sağ oklar satırı kaydırır.

Belirli bir servisin logları: journalctl -u

En sık senaryo, tek bir systemd biriminin ne yazdığına bakmaktır. Dosya aramanıza ve grep yapmanıza gerek yoktur:

$ sudo journalctl -u nginx -n 20
Oct 14 03:12:41 web1 systemd[1]: Starting nginx.service - A high performance web server...
Oct 14 03:12:41 web1 nginx[1834]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Oct 14 03:12:41 web1 systemd[1]: nginx.service: Failed with result 'exit-code'.

-u bayrağı birden fazla kez verilebilir: journalctl -u nginx -u php8.2-fpm iki servisin kayıtlarını zamana göre karışık gösterir; hata iki servisin kesiştiği noktada ortaya çıkıyorsa bu çok işe yarar. Kullanıcı birimleri (systemctl --user) için journalctl --user -u ad kullanın.

Canlı loglar: journalctl -f

sudo journalctl -u nginx -f

Bu, tail -f'in karşılığıdır: son 10 kaydı gösterir ve yenilerini bekler. Servisi yeniden başlatırken veya bir hatayı tekrar üretirken ayrı bir terminalde açık tutmak faydalıdır. Çıkış için Ctrl+C.

Zamana ve açılışa göre süzme

Olayın ne zaman olduğunu biliyorsanız, --since ve --until bayraklarıyla zaman aralığı verin. Hem kesin tarihleri hem de göreli ifadeleri anlarlar:

journalctl --since "2026-10-14 02:50" --until "2026-10-14 03:30"
journalctl --since "1 hour ago"
journalctl --since yesterday --until today
journalctl -u nginx --since "10 min ago"

Bir diğer faydalı kesit sistem açılışlarıdır (boot). Sunucu kendiliğinden yeniden başladıysa, nedeni bir önceki oturumun sonunda aranır:

$ journalctl --list-boots
 -2 8f1c...  Sat 2026-10-12 09:01:12 UTC  Sun 2026-10-13 22:47:03 UTC
 -1 a7d2...  Sun 2026-10-13 22:48:30 UTC  Tue 2026-10-14 03:05:51 UTC
  0 c3e9...  Tue 2026-10-14 03:07:02 UTC  Tue 2026-10-14 09:15:40 UTC

$ journalctl -b -1 -e      # önceki açılışın sonu
$ journalctl -b            # yalnızca geçerli açılış

Açılış listesi, günlük diskte tutuluyorsa kullanılabilir. Bunu nasıl etkinleştireceğiniz aşağıda, journald yapılandırması bölümünde anlatılıyor.

Önem derecesine göre süzme: journalctl -p

Her kaydın 0 ile 7 arasında bir syslog önceliği vardır. -p bayrağı belirtilen düzeyi ve ondan önemli olan her şeyi gösterir:

journalctl -p err -b              # açılıştan beri tüm hatalar
journalctl -p warning..err -u ssh # bir servis için düzey aralığı

journalctl -p err -b yeniden başlatmadan veya güncellemeden sonra iyi bir ilk kontroldür: neyin ters gittiğini saniyeler içinde gösterir.

Arama ve diğer süzgeçler

journald her kayıtta yapılandırılmış alanlar tutar ve bu alanlarla grep'e ihtiyaç duymadan süzebilirsiniz:

journalctl _PID=1834                 # süreç numarasına göre
journalctl _COMM=sshd                # program adına göre
journalctl _UID=1000                 # kullanıcıya göre
journalctl /usr/sbin/sshd            # çalıştırılabilir dosya yoluna göre
journalctl -k                        # yalnızca çekirdek mesajları (dmesg gibi)
journalctl -t CRON                   # syslog tanımlayıcısına göre
journalctl -g "Out of memory"        # metin araması, düzenli ifade

-g (--grep) bayrağı systemd 237 ile geldi; eski sistemlerde standart bir boru hattı kullanın: journalctl --no-pager | grep .... Farklı alanlardaki süzgeçler “VE” ile birleşir; bu yüzden journalctl -u nginx -p err --since today yalnızca bugünkü nginx hatalarını verir.

Çıktı biçimleri

-o bayrağı biçimi değiştirir. En faydalı seçenekler:

• -o short-iso — zaman ISO 8601 biçiminde, uygulama loglarıyla karşılaştırmak için uygundur.
• -o verbose — kaydın tüm alanları, _SYSTEMD_UNIT, _PID, _BOOT_ID dahil.
• -o json veya json-pretty — betiklerle veya jq ile işlemek için.
• -o cat — yalnızca mesaj metni, tarih ve sunucu adı olmadan.

journalctl -u myapp -o json --since today | jq -r '.MESSAGE'

journald yapılandırması: saklama ve boyut

Ayarlar /etc/systemd/journald.conf dosyasındadır; değişiklikleri /etc/systemd/journald.conf.d/*.conf altına koymak daha temizdir. Ana parametre Storage'dır:

• persistent — günlük /var/log/journal altına diske yazılır ve yeniden başlatmadan sonra da kalır.
• volatile — yalnızca bellekte, /run/log/journal altında.
• auto (varsayılan) — /var/log/journal dizini varsa diske yazar.

Bazı minimal imajlarda bu dizin yoktur ve yeniden başlattıktan sonra geçmiş kaybolur. Kalıcı saklamayı etkinleştirmek için:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Günlüğün tüm diski doldurmaması için sınır koyun:

# /etc/systemd/journald.conf.d/size.conf
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month

Varsayılan SystemMaxUse dosya sisteminin %10'udur, ancak 4 GB'tan fazla olamaz.

journalctl günlüğü nasıl temizlenir

$ journalctl --disk-usage
Archived and active journals take up 1.8G in the file system.

sudo journalctl --vacuum-size=300M   # en fazla 300 MB bırak
sudo journalctl --vacuum-time=2weeks # iki haftadan eski kayıtları sil
sudo journalctl --rotate             # etkin dosyaları kapat, böylece onları da silebilirsiniz

/var/log/journal içindeki dosyaları rm ile silmeyin: vacuum aynı işi güvenli biçimde yapar ve etkin dosyaya dokunmaz.

rsyslog: klasik metin logları

rsyslog, syslog mesajlarını (journald'den iletilenler dahil) kabul eden ve kurallara göre dosyalara dağıtan bir servistir. Yapılandırma /etc/rsyslog.conf ve /etc/rsyslog.d/*.conf dosyalarındadır. Bir kural, kaynak.önem seçicisi ile bir eylemden oluşur:

# /etc/rsyslog.d/50-default.conf (parça)
auth,authpriv.*        /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
kern.*                 -/var/log/kern.log

Yoldan önceki eksi işareti, her satırdan sonra diske eşitlemeden yazma anlamına gelir — daha hızlıdır, ama bir çökmede son satırlar kaybolabilir. Yapılandırmayı değiştirdikten sonra sözdizimini denetleyin ve servisi yeniden başlatın:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

rsyslog'un journald'in yanında tutulmasının asıl nedeni, logların merkezi bir sunucuya iletilmesidir. Tek satır, her şeyi TCP üzerinden gönderir:

# /etc/rsyslog.d/90-remote.conf
*.* @@logs.example.com:514

Tek @ UDP, çift @@ TCP anlamına gelir. Sunucunun tamamı çökse bile logların bir kopyası başka bir makinede kalır. Bir betikten sistem günlüğüne kendi mesajınızı yazmak için logger kullanın:

logger -t backup -p user.err "Veritabanı yedeği başarısız oldu"
journalctl -t backup -n 5

logrotate: log döndürme

Metin logları, biri onları kesmezse sonsuza dek büyür. Bu işi logrotate yapar: günde bir kez (cron veya logrotate.timer ile) geçerli dosyayı yeniden adlandırır, eskileri sıkıştırır ve en eskilerini siler. Genel ayarlar /etc/logrotate.conf, programlara özel kurallar /etc/logrotate.d/ dizinindedir.

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Kuralı değişiklik yapmadan denemek ve döndürmeyi zorla çalıştırmak için:

sudo logrotate -d /etc/logrotate.d/myapp   # kuru çalıştırma, ayrıntılı çıktı
sudo logrotate -f /etc/logrotate.d/myapp   # hemen döndür

Sık yapılan hata: postrotate veya copytruncate unutmak. Bu durumda uygulama yeniden adlandırılmış app.log.1 dosyasına eski tanıtıcıyla yazmaya devam eder, yeni app.log ise boş kalır.

Metin loglarını okuma

/var/log içindeki dosyalar için standart araçlar yeterlidir:

sudo tail -n 100 /var/log/syslog          # son satırlar
sudo tail -F /var/log/nginx/error.log     # döndürmeyi atlatarak izle
sudo less +G /var/log/auth.log            # sonda aç
sudo zgrep "Failed password" /var/log/auth.log.*.gz   # sıkıştırılmış arşivlerde ara
sudo grep -c " 500 " /var/log/nginx/access.log        # kaç tane 500 yanıtı var

tail -F ifadesindeki büyük F dikkat çekicidir: -f'den farklı olarak, logrotate dosyayı değiştirdiğinde onu yeniden açar.

Bir çöküşün adım adım incelenmesi

“Servis gece çöktü” senaryosunu sırayla incelemek kolaydır:

1. systemctl status myapp — mevcut durum ve günlüğün son satırları.
2. journalctl -u myapp --since "03:00" --until "03:30" — çöküş anında servisin ne yazdığı.
3. journalctl -p err -b — aynı zamanda sistemde başka hata var mı.
4. journalctl -k --since "03:00" -g "Out of memory|Killed process" — çekirdekteki OOM killer bir süreci öldürmüş mü.
5. Uygulamanın kendi logları /var/log/myapp/ altında, .gz arşivleri dahil.
6. Sunucu yeniden başlatıldıysa — journalctl -b -1 -e.

Özet

Günlük çalışmada Linux loglarıyla başa çıkmak için birkaç komut yeter: servis için journalctl -u, akış için -f, aralığı daraltmak için --since ve -p err, yeniden başlatmayı incelemek için -b -1. Metin günlükleri /var/log altındadır; rsyslog bunları ayırır ve iletir; logrotate ile journalctl --vacuum-* ise logların diski doldurmasını engeller. Journalctl, döndürme ve yük tanısı kursta uygulamalı olarak işlenmektedir.