Ketika sebuah layanan di server Linux tiba-tiba gagal, banyak administrator langsung menebak-nebak penyebabnya. Padahal sistem operasi sudah menyimpan jejak digital yang rapi dalam bentuk log. Pada distribusi Linux modern yang menggunakan systemd, log-log ini dikelola oleh systemd-journald dan dapat dibaca dengan satu perintah: journalctl. Dengan membaca log secara sistematis, kita bisa menelusuri jejak masalah dan percobaan akses tanpa perlu mengandalkan spekulasi.

Artikel ini akan memandu Anda menggunakan journalctl untuk membaca log sistem Linux secara efektif. Fokusnya adalah praktik yang etis dan legal—hanya pada sistem milik sendiri atau yang Anda miliki izin tertulis untuk mengaksesnya. Anda akan belajar cara memfilter log berdasarkan unit layanan dan rentang waktu, serta memantau log autentikasi untuk mendeteksi percobaan login yang mencurigakan.

Mengenal journalctl dan systemd-journald

Pada sistem Linux modern yang menggunakan systemd sebagai init system, semua log terpusat dikumpulkan oleh sebuah daemon bernama systemd-journald. Daemon ini menerima pesan dari kernel, proses init, layanan systemd, hingga aplikasi yang berjalan di latar belakang. Hasilnya adalah satu basis data log yang terstruktur dan bisa diakses lewat satu alat bantu: journalctl.

Perintah dasar journalctl tanpa argumen akan menampilkan seluruh log dari yang paling lama hingga terbaru. Karena jumlahnya bisa sangat banyak, Anda jarang membutuhkan itu. Beberapa opsi dasar yang sering dipakai:

  • journalctl -b — menampilkan log sejak boot terakhir.
  • journalctl -f — mengikuti log secara real-time, mirip tail -f.
  • journalctl -e — langsung melompat ke akhir log untuk melihat pesan terbaru.

Dengan memahami bahwa journalctl hanyalah pintu masuk ke data yang dikumpulkan systemd-journald, Anda bisa mulai berpikir untuk menyaring output sesuai kebutuhan. Inilah kunci utama menelusuri jejak masalah tanpa tenggelam dalam ribuan baris teks.

Memfilter Log Berdasarkan Unit dan Rentang Waktu

Salah satu keunggulan journalctl adalah kemampuannya memfilter log berdasarkan unit systemd. Unit di sini bisa berupa layanan, socket, atau timer. Misalnya, jika Anda curiga ada masalah pada layanan SSH, cukup jalankan:

journalctl -u sshd.service

Perintah ini hanya menampilkan log yang dihasilkan oleh unit sshd.service. Anda bisa mengganti sshd.service dengan nama unit lain seperti nginx.service, apache2.service, atau docker.service. Filter ini sangat mempercepat penelusuran masalah karena Anda tidak perlu membaca log dari semua komponen sistem.

Selain unit, filter berdasarkan rentang waktu juga sangat membantu. journalctl menerima opsi --since dan --until dengan format yang fleksibel. Contoh:

journalctl -u nginx.service --since "2025-01-01 10:00:00" --until "2025-01-01 12:00:00"

Anda juga bisa memakai parameter relatif seperti --since "1 hour ago" atau --since "yesterday". Kombinasi keduanya sangat kuat. Misalnya, untuk melihat log SSH dari dua jam terakhir:

journalctl -u sshd.service --since "2 hours ago"

Dengan memfilter unit dan rentang waktu, Anda mengubah pencarian dari “mencari jarum di tumpukan jerami” menjadi “mengambil jarum langsung dari kotaknya”. Praktik ini bukan sekadar trik, melainkan cara kerja administrator Linux yang terlatih.

Memantau Log Autentikasi untuk Deteksi Percobaan Login Mencurigakan

Log autentikasi adalah sumber informasi yang sangat berharga untuk memantau siapa saja yang mencoba masuk ke sistem. Pada banyak distribusi, pesan autentikasi dicatat oleh layanan seperti sshd, login, dan sudo. Anda bisa membacanya lewat journalctl dengan filter unit atau dengan memanfaatkan field khusus.

Cara paling sederhana adalah memfilter berdasarkan unit layanan SSH:

journalctl -u sshd.service

Outputnya akan menampilkan baris seperti Accepted password for user from 192.168.1.10 port 22 untuk login berhasil, atau Failed password for invalid user admin from 203.0.113.5 port 22 untuk kegagalan. Jika Anda melihat banyak sekali baris Failed password dari alamat IP yang sama dalam waktu singkat, kemungkinan besar ada percobaan brute force.

Anda juga bisa memfilter log berdasarkan field _COMM untuk menangkap semua pesan dari proses tertentu:

journalctl _COMM=sshd --since "today"

Pola mencurigakan yang perlu diwaspadai antara lain:

  • Banyak percobaan login gagal dari satu IP.
  • Percobaan login sebagai user root tanpa alasan jelas.
  • Login berhasil dari IP yang tidak dikenal atau di luar jam kerja normal.

Penting untuk diingat: membaca log ini hanya boleh dilakukan pada sistem milik sendiri atau sistem yang Anda punya izin tertulis untuk mengaksesnya. Jangan pernah menggunakan journalctl untuk memata-matai sistem orang lain—itu melanggar hukum dan etika.

Praktik Membaca Log yang Efektif dan Aman

Membaca log tanpa strategi bisa membuat Anda kewalahan. Berikut beberapa praktik yang membuat pekerjaan lebih efektif:

Gunakan prioritas untuk menyaring noise. journalctl mendukung opsi -p untuk menampilkan log berdasarkan level prioritas syslog. Misalnya, journalctl -p err hanya menampilkan pesan error atau lebih parah. Ini cocok untuk insiden besar.

Balik urutan tampilan. Opsi -r menampilkan log terbaru di atas, sehingga Anda tidak perlu scroll ke bawah berkali-kali.

Simpan output untuk analisis lanjutan. Jika Anda perlu membagikan log atau membacanya di editor teks, gunakan redirection:

journalctl -u sshd.service --since "today" > ssh-log.txt

Jangan aktifkan akses jarak jauh ke journald tanpa perlu. Secara default, journald hanya bisa diakses dari lokal. Jika Anda mengaktifkan fitur remote logging, pastikan hanya IP tepercaya yang diizinkan dan jalur komunikasi dienkripsi.

Dari sisi etika, selalu pastikan Anda bekerja pada sistem yang memang menjadi tanggung jawab Anda. Jika ingin memperdalam analisis log untuk keamanan, Anda bisa membaca materi lanjutan di kalilinux.net atau kalilinux.info sebagai referensi tambahan—keduanya sering membahas praktik forensik dan pemantauan log secara legal. Namun ingat, jangan pernah mencoba teknik membaca log pada sistem yang tidak Anda miliki atau tidak diizinkan.

Dengan pendekatan yang terstruktur, journalctl menjadi alat yang andal untuk menelusuri jejak masalah dan percobaan akses. Anda tidak perlu lagi menebak-nebak—cukup baca log, filter, dan ambil keputusan berdasarkan fakta yang terekam. Latih kemampuan ini di lingkungan laboratorium sendiri, maka Anda akan semakin percaya diri menangani insiden di server produksi.