Menyelidiki gangguan Linux dengan journalctl dan log layanan

Untuk mempersempit penyebab gangguan Linux melalui log, tentukan layanan dan waktu kegagalannya, kumpulkan catatan dari boot serta zona waktu yang sama, lalu cocokkan dengan hasil reproduksi. Satu baris ERROR atau pesan terakhir saja belum cukup untuk memastikan penyebab; periksa konteks dan keadaan sumber daya lain yang terkait.

Pelajari arti status layanan melalui pengantar systemd. Di sini Anda menghubungkan waktu, status, dan catatan untuk menguji dugaan penyebab. Terapkan prosedurnya dalam lingkungan terkendali melalui latihan gangguan dan pemulihan berbahasa Inggris.

Acuan latihan konfigurasi adalah mesin virtual (VM) dengan instalasi biasa Ubuntu 26.04 LTS, yaitu rilis dukungan jangka panjang, atau Rocky Linux seri 9. Kontainer, Windows Subsystem for Linux (WSL), dan rilis lain dapat berbeda dalam layanan serta paket yang tersedia. Siapkan akses konsol pemulihan dan catat versi sistem sesuai panduan persiapan VM berbahasa Inggris.

Mencatat gejala, waktu, dan perubahan terakhir

Ganti pernyataan umum seperti “server bermasalah” dengan pengamatan yang dapat diperiksa, misalnya “permintaan HTTPS dari klien A mendapat respons 502 sejak pukul 14.03.” Bandingkan jam dan zona waktu pada klien serta server. Catat kapan sistem terakhir bekerja normal, kapan aplikasi dirilis, konfigurasi diubah, dan sistem dimulai ulang. Pisahkan fakta yang diamati dari hipotesis agar pesan galat tidak mendorong perubahan yang terburu-buru.

date --iso-8601=seconds
timedatectl
systemctl --failed
journalctl --list-boots

Perintah tersebut menampilkan waktu beserta offset zona waktu, keadaan jam sistem, daftar unit yang gagal, dan daftar boot yang masih tercatat dalam journal. Journal adalah catatan terstruktur yang dikelola systemd-journald. Daftar unit gagal tidak dengan sendirinya menunjukkan kegagalan mana yang menyebabkan gejala pengguna; cocokkan waktunya.

Jika boot sebelumnya tidak tercantum, catatannya mungkin tidak pernah disimpan atau sudah dibersihkan. Periksa penyimpanan sementara dan persisten serta batas retensi journal. Data sementara di /run/log/journal tidak bertahan setelah reboot; penyimpanan persisten menggunakan /var/log/journal. Periksa konfigurasi yang berlaku pada distribusi Anda. Ketiadaan catatan tidak membuktikan bahwa gangguan tidak terjadi, dan hak baca yang terbatas juga dapat menyembunyikan catatan relevan.

Menyaring journal berdasarkan unit, boot, dan waktu

Ganti NAME.service dengan nama unit layanan yang benar. Periksa ringkasan status, baca journal dari boot saat ini, lalu persempit jendela waktu. Menyimpan interval yang terarah lebih mudah untuk dibandingkan daripada menelusuri aliran pesan yang panjang dan tidak berkaitan.

systemctl status NAME.service --no-pager
journalctl -b -u NAME.service --since "30 minutes ago" --no-pager
journalctl -b -p warning --since "30 minutes ago" --no-pager
journalctl -k -b --since "30 minutes ago" --no-pager

-u memilih unit, -b tanpa nilai memilih boot saat ini, dan -k memilih pesan kernel. -p warning mencakup warning serta prioritas yang lebih penting; bukan hanya warning. Aplikasi dapat memberi prioritas yang tidak konsisten atau menulis petunjuk melalui keluaran standar biasa. Setelah memakai filter prioritas journalctl, bandingkan juga interval yang sama tanpa filter prioritas.

Untuk insiden dengan waktu yang sudah diketahui, gunakan tanggal, jam awal, dan jam akhir yang tetap melalui --since serta --until, dengan zona waktu yang jelas. Jendela relatif “30 minutes ago” bergeser setiap kali perintah dijalankan. Boot, unit, dan waktu harus tetap cocok saat membandingkan hasil sebelum serta sesudah perubahan.

Menemukan dua peristiwa latihan dari logger

Contoh berikut menulis dua pesan bertanda tanpa mengubah konfigurasi layanan. Jalankan di lingkungan Linux yang memiliki logger dan jalur pengumpulan syslog ke journal. Kontainer terbatas atau sistem tanpa soket syslog dapat berperilaku berbeda. Periksa jalur pengumpulan sebelum menafsirkan hasil yang kosong.

tag="linux-course-log-$(id -u)"
logger -t "$tag" "stage=start case=practice"
logger -p user.warning -t "$tag" "stage=check result=sample-warning"
journalctl -t "$tag" --since "5 minutes ago" --no-pager

Cari pesan stage=start case=practice dan stage=check result=sample-warning beserta waktu masing-masing. Tambahkan -p warning pada perintah journalctl terakhir dan bandingkan: dengan prioritas yang dipertahankan oleh jalur pengumpulan, pesan pertama tidak lagi muncul, sedangkan sample-warning tetap ada. Menurut manual logger dari proyek util-linux, prioritas bawaan adalah user.notice, sementara pesan kedua secara eksplisit memakai user.warning. Sample-warning sengaja dibuat untuk latihan dan bukan bukti insiden nyata.

Tag pada contoh membedakan ID pengguna, bukan setiap pelaksanaan. Jika diulang dalam lima menit dengan pengguna yang sama, hasilnya dapat mencakup pesan dari latihan sebelumnya; cocokkan waktu pesan atau gunakan rentang waktu yang lebih sempit. Jangan menuntut tepat dua baris tanpa mempertimbangkan pengulangan itu.

Jika pembacaan ditolak, gunakan hak baca journal yang memang diizinkan oleh kebijakan sistem. Hasil logger yang berhasil belum menggantikan pemeriksaan bahwa kedua pesan benar-benar terlihat dalam journal. Jangan menghapus log produksi atau memulai ulang pengumpul hanya untuk membuat latihan ini berhasil.

Mencocokkan pesan dengan bukti independen

Pesan disk penuh dapat merujuk ke jalur yang hendak ditulisi aplikasi, bukan disk tempat log disimpan. Penolakan izin dapat berasal dari hak menelusuri direktori induk atau kebijakan Security-Enhanced Linux (SELinux), bukan sekadar mode berkas. Periksa sumber daya yang benar-benar disebutkan dalam galat. Menjalankan aplikasi sebagai root atau memberi izin 777 dapat menyamarkan gejala sambil memperluas akses tanpa menyelesaikan penyebabnya.

Susun urutan kejadian: gejala dari klien, perubahan status unit, pesan aplikasi, lalu keadaan sumber daya pada waktu yang berkaitan. Pesan yang muncul lebih awal merupakan petunjuk untuk diuji, bukan otomatis penyebab. Ubah satu hal yang relevan dalam lingkungan terkendali, ulangi pengujian dengan kondisi yang sama, dan bandingkan hasil yang benar-benar diamati.

Memeriksa log berkas dan kebijakan retensi

Aplikasi dapat menulis ke berkas di bawah /var/log atau pengumpul terpusat, bukan ke journal. Pastikan jalur dari konfigurasi aplikasi sebelum memakai tail -n 100 atau grep untuk membacanya. Sertakan log yang sudah dirotasi dan dikompresi jika diperlukan, lalu samakan format waktu dan zona waktunya. journalctl --disk-usage menunjukkan ruang penyimpanan journal, bukan pemakaian seluruh log aplikasi.

Menghapus atau menjalankan vacuum pada log saat investigasi dapat menghilangkan bukti. Simpan interval yang diperlukan di tempat dengan akses terbatas. Sebelum membagikannya, samarkan token, cookie, data pribadi, serta alamat internal yang sensitif. Catat penyebab yang telah dibuktikan, perubahan yang terarah, hasil pengujian ulang, dan ketidakpastian yang tersisa; kelola bukti sesuai kebijakan retensi.

Dokumentasi resmi

• Filter dan pemeriksaan penyimpanan journalctl
• Pengaturan penyimpanan dan retensi journal
• Manual logger proyek util-linux