Cheat Sheet journalctl: Pantau, Saring, dan Ikuti Log Linux

journalctl dalam satu baris: journalctl -u <service> -f memantau log layanan secara live, journalctl -u <service> -n 100 menampilkan 100 baris terakhir, dan journalctl --since "1 hour ago" memperlihatkan segala yang baru terjadi. Tiga perintah itu sudah menutup 90% momen “kenapa layanan ini mati”. Sisa cheat sheet ini adalah pola siap tempel yang menyelamatkan Anda dari membaca ulang man page pukul 2 pagi — penyaringan per unit, per waktu, per prioritas, dan per boot, ditambah perintah pembersihan yang menjaga journal agar tidak melahap disk. Setiap perintah di bawah berjalan apa adanya di distro systemd mana pun (Ubuntu, Debian, Fedora, Arch).

Apa itu journalctl, dan kenapa tidak langsung baca /var/log/syslog?

Logging gaya lama menulis file teks biasa di bawah /var/log — syslog, auth.log, messages. systemd menggantinya dengan journal: log biner yang terindeks dan dikelola systemd-journald. grep biasa tidak bisa membacanya; journalctl adalah satu-satunya pintu masuk, dan sebagai gantinya Anda mendapat penyaringan per layanan, per waktu, per boot, dan per tingkat keparahan tanpa akrobatika regex.

Model mentalnya sederhana: journal menyimpan semuanya, dan journalctl adalah alat kuerinya. Sebuah layanan tidak butuh file log sendiri — apa pun yang ditulisnya ke stdout/stderr selama berjalan di bawah systemd otomatis mendarat di journal. Itulah kenapa journalctl -u nginx tetap berfungsi bahkan saat Anda sama sekali tidak tahu nginx meletakkan error log-nya di mana.

Satu catatan: pada beberapa instalasi minimal, journal bersifat volatile (disimpan di /run, terhapus saat reboot) karena /var/log/journal tidak ada. Sekali dibereskan, selesai:

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

Bagaimana cara melihat 100 baris terakhir sebuah log?

-n membatasi keluaran ke N baris terbaru (bawaannya 10):

journalctl -n 100                      # 100 baris terakhir dari semuanya
journalctl -u nginx -n 100             # 100 baris terakhir dari satu unit
journalctl -n 100 --no-pager           # cetak lalu keluar — pas untuk pipe

--no-pager lebih penting dari kelihatannya: tanpanya journalctl membuka less dan skrip, pipe, atau one-liner ssh Anda menggantung menunggu tombol ditekan. Perintah apa pun yang keluarannya di-pipe ke proses lain sebaiknya membawanya.

Bagaimana cara memantau log secara live, seperti tail -f?

Flag -f adalah tail -f-nya journalctl — ia mengalirkan entri baru begitu terjadi:

journalctl -f                    # semuanya, live
journalctl -u sshd -f            # hanya daemon SSH, live
journalctl -u ollama -f -n 50    # live, tapi mulai dari 50 baris terakhir

Inilah perintah untuk dijalankan di terminal kedua sementara Anda me-restart layanan di terminal pertama: systemctl restart nginx di satu panel, journalctl -u nginx -f di panel lain, dan penyebab crash biasanya mengaku sendiri dalam hitungan detik. Saya menjalankan siklus persis ini di homelab saya setiap kali ada kontainer atau layanan yang bandel.

Bagaimana cara menampilkan log untuk layanan tertentu?

-u menyaring berdasarkan unit systemd:

journalctl -u nginx                    # satu unit, seluruh history
journalctl -u nginx -u redis           # beberapa unit sekaligus
journalctl _SYSTEMD_UNIT=nginx.service # alternatif pencocokan eksak

Sebuah unit bisa memunculkan unit pendamping yang menyimpan keluaran penting — aplikasi web yang gagal kadang mencatat error sebenarnya di bawah unit lain. Jika -u <service> tidak menampilkan apa-apa padahal layanannya jelas berjalan, cari dulu nama unit yang sebenarnya:

systemctl list-units --type=service | grep -i <guess>

Pola -u yang sama berlaku untuk timer (systemctl list-timers menampilkan namanya) dan layanan pengguna — untuk apa pun yang berjalan di bawah systemd --user, tambahkan --user:

journalctl --user -u pipewire -n 50

Bagaimana cara menyaring log berdasarkan waktu?

--since dan --until menerima timestamp, tetapi keduanya juga menerima frasa relatif yang besar hati:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Pasangkan jendela waktu dengan satu unit, dan triase insiden selesai dalam satu baris: “apa yang API catat antara pukul 09:00 dan saat ia tumbang?” Untuk satu mesin, ini lebih cepat daripada log aggregator mana pun.

Bagaimana cara menampilkan hanya error (atau warning)?

-p menyaring berdasarkan prioritas, memakai nama tingkat keparahan syslog:

journalctl -p err -b              # hanya error, sejak boot ini
journalctl -p warning..alert -u nginx   # satu rentang tingkat keparahan

Urutan prioritas dari tertinggi: emerg, alert, crit, err, warning, notice, info, debug. Saat sebuah mesin “berperilaku aneh”, journalctl -p err -b --since today adalah uji kewarasan paling cepat — ia menjawab “apakah ada yang benar-benar gagal?” tanpa derau baris info rutin.

Bagaimana cara melihat log dari boot sebelumnya?

Layanan yang crash saat startup menghasilkan baris log sebelum boot Anda yang sekarang, dan journalctl diam-diam hanya menampilkan boot saat ini. -b memilih boot:

journalctl -b                 # hanya boot saat ini
journalctl -b -1              # boot sebelumnya
journalctl -b -1 -u sshd      # kenapa SSH mati terakhir kali
journalctl --list-boots       # indeks boot yang tersimpan

Ini flag paling berguna untuk skenario “rusak, saya reboot, sekarang errornya tidak terlihat” — errornya masih ada, satu boot di belakang.

Referensi cepat: flag yang layak dihafal

Tujuan	Perintah
Memantau satu layanan secara live	journalctl -u <svc> -f
100 baris terakhir	journalctl -n 100
Sejak satu jam lalu	journalctl --since "1 hour ago"
Error pada boot ini	journalctl -p err -b
Boot sebelumnya	journalctl -b -1
Penggunaan disk journal	journalctl --disk-usage
Keluaran yang bisa dibaca mesin	journalctl -o json-pretty
Hanya pesan kernel	journalctl -k

Bagaimana cara mencegah journal memenuhi disk?

Cek dulu harganya, lalu pasang plafon:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # simpan 500 MB terbaru
sudo journalctl --vacuum-time=30d      # simpan 30 hari terakhir

Agar plafonnya permanen, set SystemMaxUse=500M di bagian [Journal] pada /etc/systemd/journald.conf, lalu sudo systemctl restart systemd-journald. Dengan plafon ukuran dan filter boot di atas, journal kembali menjadi alat — bukan kebocoran disk yang pelan.

journalctl vs dmesg vs /var/log — mana yang dicek lebih dulu?

• journalctl — perilaku aplikasi dan layanan. Apa pun yang dikelola systemd ada di sini, terindeks dan bisa disaring. Pemberhentian pertama yang baku.
• journalctl -k / dmesg — kernel dan perangkat keras: OOM kill, reset USB, error disk. Bila sebuah proses mati tanpa alasan jelas, cari si OOM killer di sini sebelum menyalahkan aplikasinya.
• /var/log/<app>/ — hanya untuk aplikasi yang membuat logging file sendiri (access log nginx, PostgreSQL). Bahkan begitu, error startup biasanya tetap mendarat di journal.

Alur kerja yang sama berlaku untuk layanan AI lokal — ketika unit ollama serve macet, journalctl -u ollama -n 100 langsung memperlihatkan kegagalan pemuatan modelnya, seperti dibahas dalam perbandingan Ollama vs LM Studio.

Itulah seluruh cheat sheet-nya: -u untuk unit, -f untuk memantau, -n untuk baris, --since untuk waktu, -p untuk tingkat keparahan, -b untuk boot. Enam flag menjawab hampir semua pertanyaan log yang bisa diajukan sebuah mesin Linux kepada Anda.