journalctl: Cara Efektif Troubleshooting Log Systemd di Linux

Ketika sebuah service di server tiba-tiba mati atau aplikasi gagal start, hal pertama yang dicari sysadmin adalah log. Di distro modern berbasis systemd — Ubuntu, Debian, Fedora, Arch — log tidak lagi tersimpan sebagai file teks biasa di /var/log, melainkan dikelola oleh journald dan diakses lewat perintah journalctl.

Banyak developer yang masih membuka file log lama seperti /var/log/syslog atau /var/log/nginx/error.log padahal jawabannya sudah tersedia di journal dengan filter yang jauh lebih presisi. Artikel ini membahas cara membaca, memfilter, dan menganalisis log systemd secara efektif.

Apa Itu Journald dan journalctl

Journald adalah daemon logging bawaan systemd yang mengumpulkan log dari kernel, systemd unit, dan aplikasi yang berjalan di bawah systemd. Log disimpan dalam format biner terstruktur, bukan teks polos, sehingga bisa difilter berdasarkan field seperti unit, prioritas, user, atau waktu.

journalctl adalah utilitas baris perintah untuk mengakses journal tersebut. Karena formatnya terstruktur, journalctl bisa menjawab pertanyaan yang sulit dijawab dengan log file biasa — misalnya "log apa yang ditulis service ini dalam 10 menit terakhir?" atau "kenapa service restart terus?"

Salah satu keunggulan utama journald: log service yang dijalankan systemd otomatis tertangkap — stdout dan stderr langsung masuk journal tanpa konfigurasi tambahan. Ini berarti troubleshooting jauh lebih cepat dibanding harus mengonfigurasi log rotation dan file path untuk tiap aplikasi.

Perintah Dasar yang Sering Dipakai

Berikut perintah dasar yang paling sering dipakai sehari-hari:

# Semua log sejak boot terakhir
journalctl -b

# Log service tertentu
journalctl -u nginx.service

# Log service dengan live follow (seperti tail -f)
journalctl -u nginx.service -f

# 50 baris terakhir
journalctl -n 50

# Semua log sejak 1 jam terakhir
journalctl --since "1 hour ago"

# Log antara dua waktu
journalctl --since "2026-08-25 08:00" --until "2026-08-25 09:30"

# Hanya error dan level di atasnya
journalctl -p err

Kombinasi -u (unit) dan --since adalah pasangan paling berguna: misalnya journalctl -u myapp.service --since "30 min ago" langsung menampilkan aktivitas service dalam rentang waktu yang relevan tanpa noise dari service lain.

Filter Field dan Prioritas

Journal menyimpan banyak field metadata per entri, dan semuanya bisa dipakai untuk filter. Beberapa field yang sering berguna:

• PRIORITY. 0 (emerg) sampai 7 (debug). Filter -p err menampilkan prioritas 0-3.
• _SYSTEMD_UNIT. Unit systemd yang menghasilkan log.
• _PID. Process ID penghasil log — berguna saat aplikasi fork banyak child.
• _HOSTNAME. Host asal, berguna di journal terpusat.
• _COMM. Nama command/executable.

Filter field ditulis dalam bentuk FIELD=value:

# Log dari PID tertentu
journalctl _PID=1234

# Log dari executable tertentu dalam unit
journalctl _COMM=nginx -u nginx.service

# Kombinasi unit dan prioritas
journalctl -u toolkuy-web.service -p warning --since "1 day ago"

Untuk melihat semua field yang tersedia di sebuah entri, gunakan output verbose:

journalctl -u myapp.service -n 1 -o verbose

Output verbose menampilkan seluruh field metadata — sangat membantu saat ingin menyusun filter yang presisi.

Debugging Service yang Restart Terus

Kasus klasik: service restart berulang (crash loop). Langkah pertama selalu mengecek status unit:

systemctl status toolkuy-web.service

Perintah ini menampilkan beberapa baris log terakhir. Untuk gambaran lengkap kegagalan, lihat seluruh log sejak boot dengan prioritas error:

journalctl -u toolkuy-web.service -b -p err

Kalau service crash, systemd mencatat exit code di log. Exit code seperti Exit code 1 atau signal 9 bisa langsung menunjukkan apakah ini kegagalan aplikasi atau di-kill sistem. Log kernel di sekitar waktu crash juga patut dicek kalau diduga OOM killer:

journalctl -k --since "30 min ago" | grep -i "oom|killed"

Pendekatan berurutan ini — status unit, log error, lalu log kernel — menyelesaikan mayoritas kasus service mati tanpa perlu membuka editor file konfigurasi.

Analisis Boot yang Lambat

Selain service log, journal juga menyimpan log boot. Untuk melihat berapa lama tiap boot berlangsung dan service mana yang paling lambat:

# Waktu boot terakhir
systemd-analyze

# Service paling lambat saat boot
systemd-analyze blame | head -10

Data ini berasal dari systemd itu sendiri, dan bisa dikombinasikan dengan journal untuk melihat apa yang terjadi selama fase boot:

journalctl -b -p warning

Service yang menunda boot biasanya muncul dengan pesan Timed out waiting for device atau dependency yang gagal. systemd-analyze blame langsung menunjukkan waktu tunggu tiap unit, sehingga target optimasi langsung terlihat.

Menjaga Journal Tetap Ringan

Journal biner bisa membesar tanpa kendali kalau tidak dibatasi. Konfigurasi ada di /etc/systemd/journald.conf, khususnya parameter:

• SystemMaxUse. Batas maksimum ukuran journal (default 10% dari partisi).
• SystemMaxFileSize. Ukuran maksimum per file journal.
• MaxRetentionSec. Berapa lama log dipertahankan.

Contoh pembatasan agar journal maksimal 500MB:

SystemMaxUse=500M
MaxRetentionSec=2week

Setelah mengubah konfigurasi, restart journald dan lakukan vacuum untuk menerapkan:

sudo systemctl restart systemd-journald
sudo journalctl --vacuum-size=400M

Perintah --vacuum-size memangkas journal hingga di bawah ukuran yang ditentukan, berguna saat disk menipis dan log bukan prioritas. Kebiasaan yang baik: pasang cron sederhana yang menjalankan vacuum bulanan, atau pantau ukuran journal lewat du -sh /var/log/journal — lebih baik mencegah disk penuh daripada panik saat layanan berhenti karena disk 100%.

Mengekspor Log untuk Audit dan Analisis

Journal tidak hanya untuk dibaca di terminal — outputnya bisa diekspor ke format lain untuk audit, analisis, atau dikirim ke sistem log terpusat. Opsi -o mengontrol format output:

# Format JSON, cocok untuk diproses jq atau dikirim ke log aggregator
journalctl -u myapp.service --since "1 day ago" -o json

# Output singkat satu baris per entri
journalctl -u myapp.service -o short-iso

# Ekspor mentah (binary) untuk dipindah antar mesin
journalctl -u myapp.service --output=export > export.journal

Format JSON sangat berguna saat menggabungkan journal dengan tool seperti jq untuk agregasi:

journalctl -u myapp.service --since "1 hour ago" -o json | jq -r '.MESSAGE' | sort | uniq -c | sort -rn | head -10

Perintah di atas menghitung pesan log yang paling sering muncul dalam satu jam terakhir — cara cepat menemukan error yang berulang tanpa membaca ratusan baris manual.

Untuk sistem dengan banyak server, journal bisa diteruskan ke log aggregator seperti Loki, Elasticsearch, atau Graylog menggunakan agent seperti Promtail atau Filebeat yang membaca journal via journalctl -o json. Ini memberi satu dashboard terpusat untuk semua server, sambil tetap mempertahankan struktur field journal.

Studi Kasus: Mencari Penyebab Downtime

Bayangkan sebuah aplikasi web down pukul 02:00 dan baru ketahuan pagi hari. Dengan journal, rekonstruksi kejadian dilakukan dalam beberapa langkah cepat:

# 1. Kapan service terakhir mati?
journalctl -u myapp.service -b -o short-iso | grep -i "start|stop|exit|signal" | tail -20

# 2. Apa error terakhir sebelum mati?
journalctl -u myapp.service --since "2026-08-25 01:45" --until "2026-08-25 02:15" -p err

# 3. Apakah kernel ikut mencatat sesuatu (OOM, network drop)?
journalctl -k --since "2026-08-25 01:45" --until "2026-08-25 02:15"

Dari tiga perintah ini, penyebab biasanya langsung terlihat: apakah aplikasi crash dengan stack trace (masalah kode), di-kill karena OOM (masalah memory), atau koneksi database terputus (masalah infrastruktur). Tanpa journal, proses ini bisa memakan berjam-jam membuka file log yang tersebar.

Kebiasaan yang baik: sebelum melakukan deploy besar, catat journalctl -u myapp.service -n 1 sebagai baseline. Setelah deploy, bandingkan dengan baseline untuk mendeteksi perubahan perilaku yang tidak diinginkan sejak awal.

Kesimpulan

journalctl adalah salah satu tool paling penting di Linux modern, dan memahaminya menghemat waktu troubleshooting yang sangat besar. Dengan kombinasi filter unit, waktu, dan prioritas, masalah service bisa diidentifikasi dalam hitungan detik — tanpa perlu menebak-nebak file log mana yang harus dibuka.

Mulai dari perintah dasar journalctl -u <service> -f untuk live log, lalu kombinasikan dengan --since dan -p err saat menelusuri kegagalan. Ditambah konfigurasi pembatasan ukuran journal, log systemd jadi aset yang ringan dan terpercaya untuk operasional harian server.