journalctl

Seluruh service yang kita kelola sepanjang section ini tidak pernah diam: setiap start, setiap kegagalan, setiap koneksi yang diterima dicatat sebagai baris log. Pertanyaannya, ke mana semua baris itu pergi? Di dunia klasik jawabannya file teks /var/log/syslog yang diurus rsyslog. Distribusi modern mengumpulkan semuanya lebih dulu ke journald — service kecil bawaan systemd yang menyimpan log dalam format biner terstruktur lalu memakai journalctl sebagai satu-satunya pintu baca. Chapter ini membahas cara menyaring journal per unit, waktu, prioritas, dan boot, membedah format terstrukturnya, lalu mengatur ukuran dan retensinya.

journald: Log Biner Terstruktur #

journald adalah daemon logging yang dijalankan langsung oleh systemd sebagai PID 1. Daemon ini memungut pesan dari tiga sumber sekaligus: kernel lewat /dev/kmsg, service lewat stdout/stderr yang ditangkap systemd, dan program lama yang masih memanggil API syslog lewat socket /dev/log. Setiap entri disimpan bukan sebagai baris teks, melainkan sebagai kumpulan field bernama — MESSAGE, PRIORITY, _PID, _SYSTEMD_UNIT — dalam file biner yang punya indeks, sehingga penyaringan berdasarkan field mana pun cepat.

Karena journald dan journalctl dibundel dalam paket yang sama, versinya identik dengan versi systemd:

journalctl --version | head -n1

Output yang Dihasilkan:

systemd 257 (257.13-1~deb13u1)

Baris di atas diambil dari mesin penulis materi (Debian 13) — di Ubuntu atau Fedora angkanya akan berbeda, tetapi perintahnya sama persis. Perilaku penyimpanannya diatur oleh /etc/systemd/journald.conf. Kita saring baris-baris pengatur pentingnya:

grep -E '^#(Storage|Compress|SystemMaxUse|MaxRetentionSec)' /etc/systemd/journald.conf

Output yang Dihasilkan:

#Storage=auto
#Compress=yes
#SystemMaxUse=
#MaxRetentionSec=0

Tanda # di awal tiap baris berarti nilai bawaan belum diubah oleh admin — nilai di sebelah kanan tanda = itulah yang sedang aktif. Tiga baris pertama yang paling relevan:

1. #Storage=auto: mode bawaan. journald menyimpan log secara persisten (bertahan reboot) hanya bila direktori /var/log/journal ada; tanpa direktori itu, log hanya hidup di /run/log/journal dan lenyap saat reboot.
2. #SystemMaxUse=: kosong berarti journald memakai batas otomatis (sepersepuluh kapasitas filesystem) untuk ukuran maksimum journal.
3. #MaxRetentionSec=0: nol berarti journal tidak dibuang berdasarkan usia, hanya berdasarkan ukuran.

Membaca Log: per Unit, Boot, dan Waktu #

Tanpa argumen, journalctl mengosongkan seluruh journal ke layar — persis seperti cat untuk semua log sistem sekaligus. Berikut contoh tampilan empat baris pertamanya:

Jan 15 09:00:01 laptop-budi systemd[1]: Started ssh.service - OpenBSD Secure Shell server.
Jan 15 09:00:01 laptop-budi kernel: e1000e 0000:00:1f.6 enp3s0: link is up
Jan 15 09:01:17 laptop-budi sudo[2210]: budi : TTY=pts/0 ; PWD=/home/budi ; COMMAND=/usr/bin/apt update
Jan 15 09:01:20 laptop-budi sshd[2240]: Server listening on 0.0.0.0 port 22.

Format tiap barisnya: tanggal-jam, hostname, proses pencatat beserta PID di dalam kurung siku, lalu isi pesan — dan perhatikan tiga sumber berbeda (systemd, kernel, sudo) duduk berdampingan dalam satu alur waktu. Kekuatan journalctl ada pada penyaringannya; flag yang paling sering kita pakai:

Flag-flag itu boleh dikombinasikan sesuka hati. Pola favorit saat service berperilaku aneh adalah journalctl -u nama.service -p err --since today — log unit itu saja, yang gagal saja, sejak hari ini saja. Daftar prioritas mengikuti standar syslog, dari yang paling telak sampai yang paling berisik: emerg, alert, crit, err, warning, notice, info, dan debug; menyaring dengan -p err berarti tiga level di atasnya ikut tampil.

Format Terstruktur: json dan __REALTIME_TIMESTAMP #

Mode teks di atas hanyalah proyeksi dari field-field yang tersimpan penuh di journal. Format mentah itu bisa kita lihat dengan flag output:

journalctl -u ssh.service -n 1 -o json

Berikut contoh tampilan satu entri hasilnya:

{"__REALTIME_TIMESTAMP":"1768478400000000","_HOSTNAME":"laptop-budi","_COMM":"sshd","_PID":"2240","PRIORITY":"6","SYSLOG_IDENTIFIER":"sshd","MESSAGE":"Server listening on 0.0.0.0 port 22."}

Setiap field menjadi satu kunci JSON, dan inilah asal kecepatan penyaringan journal: journalctl -u tidak memindai teks, melainkan membaca indeks field _SYSTEMD_UNIT. Satu field layak diperhatikan: __REALTIME_TIMESTAMP menyimpan waktu kejadian dalam mikrodetik sejak epoch (1 Januari 1970 UTC) — angkanya panjang karena satu detik sama dengan satu juta mikrodetik. Kita bisa membuktikannya dengan date:

epoch=$(date -u -d '2026-01-15 12:00:00' +%s)
printf '%s detik = %s mikrodetik\n' "$epoch" "$((epoch * 1000000))"

Output yang Dihasilkan:

1768478400 detik = 1768478400000000 mikrodetik

Angka 1768478400000000 di contoh JSON di atas ternyata bermakna tepat pukul 12:00 siang tanggal 15 Januari 2026 UTC. Format ini lazim disalurkan ke jq untuk diolah otomatis — misalnya journalctl -o json | jq -r '.__REALTIME_TIMESTAMP'. Dua format lain yang sering dipakai: -o json-verbose menambahkan field yang lebih lengkap, sedangkan -o cat hanya mencetak isi MESSAGE polos tanpa prefiks.

Ukuran, Retensi, dan Vacuum #

Journal tumbuh terus sepanjang hidup sistem, jadi journald membawa pengaturan pembersihan bawaan dan kita bisa memaksa pembersihan kapan pun. Pemeriksaan ukurannya satu perintah:

journalctl --disk-usage 2>&1

Output yang Dihasilkan:

No journal files were found.
Archived and active journals take up 0B in the file system.

Blok di atas dijalankan pada sistem latihan tanpa journald yang hidup, dan journald melaporkan keadaannya dengan jujur: tidak ada file journal. Di laptop atau server Anda yang berjalan penuh, baris kedua berisi angka nyata seperti Archived and active journals take up 4.0G in the file system. — dari situlah kita tahu saatnya membereskan. Dua perintah vacuum mengerjakannya: journalctl --vacuum-size=200M memangkas arsip lama sampai totalnya di bawah 200 MB, dan journalctl --vacuum-time=7d membuang semua entri yang lebih tua dari tujuh hari. Untuk batas yang berlaku permanen, ubah SystemMaxUse= di journald.conf seperti yang kita lihat di awal chapter — misalnya SystemMaxUse=500M.

journald dan /var/log/syslog #

Dua dunia logging ini hidup berdampingan. journald selalu berjalan pada sistem systemd dan menampung semuanya lebih dulu; rsyslog, bila dipasang, membaca dari journal lalu menulis salinan teks ke /var/log/syslog dan /var/log/auth.log, lengkap dengan rotasi logrotate — tail -f /var/log/syslog dengan journalctl -f pun nyaris setara. Distribusi modern seperti Debian 13 bahkan tidak lagi memasang rsyslog secara bawaan, sehingga journalctl adalah keterampilan yang tidak tergantikan. Detail cara kerja journald ada di systemd-journald.service(8) , daftar flag lengkap di journalctl(1) , dan resep praktisnya di wiki Arch tentang systemd journal .

Dengan kemampuan membaca log, pertanyaan berikutnya terjawab sendiri: bisakah kita menulis service sendiri dan mendapatkan semua ini gratis? Bisa — dan itulah misi chapter berikutnya.