Ketika server Linux lambat, layanan gagal berjalan, atau aplikasi tiba-tiba berhenti, log sistem sering menjadi tempat terbaik untuk mulai mencari penyebabnya. Pada distribusi Linux yang menggunakan systemd, perintah journalctl membantu membaca catatan yang dikumpulkan oleh systemd-journald tanpa harus membuka banyak berkas log secara manual.
Panduan ini membahas perintah yang paling berguna untuk pemeriksaan harian, cara mempersempit hasil pencarian, serta beberapa hal yang perlu diperhatikan agar proses troubleshooting tetap aman.
Apa Itu journalctl?
journalctl adalah utilitas untuk membaca log dari systemd journal. Catatan ini dapat berasal dari kernel, layanan systemd, dan aplikasi yang mengirimkan pesan melalui mekanisme logging yang didukung. Format journal menyimpan metadata seperti waktu, unit layanan, dan prioritas pesan, sehingga hasilnya dapat difilter berdasarkan kebutuhan.
Tidak semua sistem Linux menggunakan systemd. Jika perangkat menggunakan sistem init atau sistem logging berbeda, perintah ini mungkin tidak tersedia atau tidak menampilkan seluruh log aplikasi. Akses ke sebagian catatan juga bergantung pada hak pengguna dan konfigurasi distribusi.
1. Membaca log terbaru dan log sejak boot
Jalankan perintah berikut untuk melihat catatan journal:
journalctl
Hasilnya biasanya dibuka melalui pager agar mudah ditelusuri. Tekan q untuk keluar. Untuk melihat pesan dari proses boot saat ini, gunakan:
journalctl -b
Jika journal menyimpan riwayat boot sebelumnya, opsi -b -1 menampilkan log dari boot sebelumnya. Nomor boot yang tersedia dapat diperiksa dengan:
journalctl --list-boots
Riwayat boot lama tidak selalu tersedia. Pada sistem yang hanya menyimpan journal di memori, catatan dapat hilang setelah reboot. Karena itu, jangan menganggap tidak adanya log lama sebagai bukti bahwa masalah tidak pernah terjadi.
2. Memfilter berdasarkan layanan
Jika yang bermasalah adalah layanan tertentu, filter berdasarkan nama unit agar hasilnya tidak bercampur dengan pesan lain. Contoh untuk Nginx:
journalctl -u nginx
Untuk membatasi hasil pada satu jam terakhir:
journalctl -u nginx --since "1 hour ago"
Nama unit harus sesuai dengan sistem yang digunakan. Jika tidak yakin, daftar layanan dapat diperiksa dengan systemctl list-units --type=service. Beberapa aplikasi menulis log ke berkas tersendiri atau ke sistem logging lain, sehingga pesannya mungkin tidak muncul pada journal.
3. Menemukan pesan peringatan dan kesalahan
Saat log terlalu panjang, mulai dari pesan berprioritas peringatan atau lebih serius:
journalctl -p warning
Prioritas journal memiliki tingkatan, mulai dari emergency hingga debug. Memilih warning akan mencakup peringatan dan tingkat yang lebih serius. Untuk melihat pesan sejak hari ini, gabungkan filter waktu:
journalctl -p warning --since today
Filter prioritas dapat membantu mempercepat pemeriksaan, tetapi tidak menggantikan pembacaan konteks. Pesan berprioritas rendah kadang justru menjelaskan kejadian yang mendahului error, sementara beberapa aplikasi memberi tingkat prioritas yang kurang tepat.
4. Mengikuti log secara langsung
Untuk memantau apa yang terjadi ketika layanan dimulai ulang atau permintaan baru masuk, gunakan mode mengikuti log:
journalctl -u nginx -f
Perintah tersebut terus menampilkan pesan baru. Buka terminal kedua untuk menjalankan pengujian atau restart layanan bila memang aman dilakukan. Hentikan pemantauan dengan Ctrl+C. Hindari menjalankan perubahan pada server produksi tanpa memahami dampaknya atau tanpa prosedur pemulihan.
5. Menampilkan waktu dan mempersempit rentang pencarian
Rentang waktu biasanya lebih efektif daripada membaca seluruh journal. Contohnya:
journalctl --since "2026-10-15 14:00:00" --until "2026-10-15 15:00:00"
Sesuaikan tanggal dan jam dengan waktu kejadian serta zona waktu mesin. Untuk membantu analisis, format ISO dapat digunakan agar cap waktu terlihat lebih konsisten:
journalctl -u nginx -o short-iso --since "30 minutes ago"
Jika sedang menelusuri insiden, catat waktu yang tepat, nama layanan, pesan error, dan tindakan yang dilakukan. Informasi ini membantu membandingkan kejadian tanpa perlu menyalin seluruh log.
6. Memeriksa penggunaan ruang dan retensi log
Journal dapat bertambah seiring waktu. Periksa ruang yang digunakan dengan:
journalctl --disk-usage
Jika perlu membersihkan journal, lakukan setelah memahami kebijakan retensi dan kebutuhan audit. Contoh berikut meminta systemd menghapus arsip journal yang lebih lama dari 14 hari:
sudo journalctl --vacuum-time=14d
Perintah vacuum menghapus berkas journal yang sudah diarsipkan; perintah ini bukan pengganti kebijakan pencadangan. Jangan menghapus log sembarangan ketika sedang menyelidiki insiden atau ketika organisasi memiliki kewajiban retensi tertentu. Pastikan juga ruang kosong pada disk dan kebijakan penyimpanan sudah dipahami sebelum mengubah konfigurasi.
7. Mengapa log boot sebelumnya tidak muncul?
Jika journalctl -b -1 tidak menampilkan data, journal mungkin belum dikonfigurasi untuk menyimpan catatan secara persisten. Periksa dokumentasi distribusi dan konfigurasi journald sebelum mengubahnya. Pada sistem yang mendukung penyimpanan persisten, journal biasanya disimpan di lokasi seperti /var/log/journal; pengaturan yang berlaku dapat berbeda menurut distribusi dan kebijakan administrator.
Jangan membuat direktori atau mengubah konfigurasi secara membabi buta. Tinjau berkas konfigurasi yang ada, pahami dampak perubahan, lalu uji apakah log tetap tersedia setelah reboot terencana.
Praktik aman saat membaca log
- Gunakan
sudohanya bila diperlukan dan pahami hak akses yang diberikan. - Samarkan alamat IP, nama pengguna, token, alamat email, dan data sensitif sebelum membagikan potongan log.
- Jangan langsung menyimpulkan penyebab hanya dari satu pesan; periksa beberapa baris sebelum dan sesudahnya.
- Simpan salinan bukti yang diperlukan sesuai kebijakan keamanan sebelum melakukan pembersihan.
- Hindari menempelkan seluruh log server ke layanan publik karena isinya dapat memuat informasi internal.
Kesimpulan
journalctl membantu administrator Linux menelusuri masalah dengan filter layanan, prioritas, rentang waktu, dan pemantauan langsung. Mulailah dari waktu kejadian dan unit layanan yang relevan, kemudian perluas pencarian jika konteksnya belum cukup. Dengan membaca log secara sistematis dan menjaga data sensitif, troubleshooting menjadi lebih terarah tanpa menghapus bukti yang masih dibutuhkan.
Referensi resmi: dokumentasi journalctl dan dokumentasi konfigurasi systemd-journald.