Lokasi Log Penting di Linux dan Cara Membacanya

Saat server bermasalah, jawabannya hampir selalu sudah tertulis di log, dan sebagian besar log itu ada di dua tempat: journal systemd dan folder /var/log.

Masalahnya, server Linux menulis log di banyak tempat dengan nama yang berbeda antar distribusi. Pesan "502 Bad Gateway" di browser tidak memberi tahu apa-apa, tapi satu baris di log error Nginx bisa langsung menunjuk aplikasi yang mati. Mengetahui log mana yang dibuka untuk gejala apa menghemat banyak waktu tebak-tebakan.

Contoh di bawah memakai Ubuntu dan Debian. Di keluarga Red Hat (AlmaLinux, Rocky), sebagian nama file berbeda dan dicatat di tempatnya.

Peta log: gejala apa, buka log mana?

journalctl: pintu utama di sistem modern

Di distribusi dengan systemd, hampir semua layanan menulis ke journal. Perintah journalctl membacanya, dan beberapa opsi ini paling sering dipakai:

• journalctl -u nginx: log satu layanan.
• journalctl -u nginx -f: ikuti log secara langsung, seperti tail -f.
• journalctl -u nginx --since "1 hour ago": hanya satu jam terakhir.
• journalctl -p err -b: hanya pesan error sejak boot terakhir.
• journalctl -b -1: log dari boot sebelumnya, berguna untuk tahu kenapa server reboot.
• journalctl -k: pesan kernel, termasuk OOM killer dan error disk.

Kalau journalctl -b -1 mengatakan tidak ada boot sebelumnya, kemungkinan journal hanya disimpan di memori dan hilang setiap reboot. Dengan pengaturan bawaan Storage=auto, journal disimpan permanen begitu folder /var/log/journal ada, jadi cukup buat folder itu lalu restart systemd-journald.

Apa saja isi folder /var/log?

/var/log/auth.log (di RHEL: /var/log/secure) mencatat login SSH, penggunaan sudo, dan kegagalan autentikasi. Ini log pertama yang dibuka bila kamu curiga ada akses tidak sah. Baris "Accepted publickey" atau "Accepted password" dari IP yang tidak kamu kenal adalah tanda bahaya.

/var/log/syslog (di RHEL: /var/log/messages) berisi pesan umum sistem dan layanan. Di beberapa instalasi baru, file ini tidak ada karena semua sudah ditangani journal saja, dan itu normal.

/var/log/kern.log memuat pesan kernel, sama dengan journalctl -k.

/var/log/apt/history.log mencatat paket yang dipasang, diperbarui, atau dihapus. Berguna ketika masalah muncul tepat setelah pembaruan.

Log web server: akses dan error

Nginx menulis dua file utama:

• /var/log/nginx/access.log: setiap permintaan, lengkap dengan IP, waktu, URL, kode status, dan user agent.
• /var/log/nginx/error.log: masalah di sisi server, misalnya "connect() failed" saat aplikasi di belakangnya mati, atau file konfigurasi yang salah.

Apache di Ubuntu memakai /var/log/apache2/access.log dan error.log, di RHEL /var/log/httpd/. Panel seperti cPanel menyimpan log per domain di lokasinya sendiri.

Dua pola yang sering berguna. Untuk mencari IP yang paling banyak mengakses:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Untuk menghitung respons error 5xx:

awk '$9 ~ /^5/' /var/log/nginx/access.log | wc -l

Perintah kedua mengandalkan format log bawaan, kolom kesembilan adalah kode status. Log akses juga menjadi bukti penting saat menyelidiki peretasan, seperti dijelaskan di tanda website diretas.

Log database dan container

MySQL dan MariaDB di Ubuntu biasanya menulis error ke /var/log/mysql/error.log, dan pesan start atau berhentinya juga tercatat di journalctl -u mysql atau journalctl -u mariadb. PostgreSQL di Debian dan Ubuntu menulis ke /var/log/postgresql/. Lokasi pastinya bisa berbeda tergantung konfigurasi, jadi bila file tidak ada, lihat pengaturan log di file konfigurasi database.

Untuk container, docker logs nama-container menampilkan keluaran aplikasinya, dan docker compose logs -f nama-service untuk stack compose. Opsi --since 30m membatasi rentang waktunya. File aslinya tersimpan di bawah /var/lib/docker/containers/ dan, tanpa pengaturan rotasi, bisa membesar terus. Ini salah satu poin di kesalahan umum Docker di produksi.

Bagaimana mencegah log memenuhi disk?

Log yang tidak dirotasi adalah penyebab klasik disk penuh. Ada tiga lapis yang perlu diperiksa.

Logrotate menangani file di /var/log. Konfigurasinya ada di /etc/logrotate.conf dan /etc/logrotate.d/. Paket seperti Nginx biasanya sudah membawa aturannya sendiri. Contoh aturan untuk log aplikasi buatan sendiri:

/var/log/aplikasiku/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
}

Uji tanpa mengubah apa pun dengan logrotate -d /etc/logrotate.d/aplikasiku.

Journal systemd dibatasi lewat SystemMaxUse= di /etc/systemd/journald.conf. Untuk membersihkan sekali jalan, journalctl --vacuum-size=500M memangkas journal sampai ukuran itu. Cek pemakaian sekarang dengan journalctl --disk-usage.

Log container dibatasi lewat opsi logging Docker, per service atau di /etc/docker/daemon.json.

Kebiasaan membaca log yang menolong

Mulai dari waktu kejadian. Tanyakan kapan gejala pertama kali muncul, lalu baca log di sekitar waktu itu dengan --since dan --until. Membaca ribuan baris dari awal jarang membuahkan hasil.

Pastikan juga jam server benar (timedatectl), karena log dengan zona waktu yang salah bisa membuatmu mencari di jam yang keliru. Untuk lebih dari satu server, pertimbangkan mengirim log ke satu tempat terpusat, dan padukan dengan pemantauan seperti di metrik server yang wajib dipantau.

Simpan tabel di atas sebagai contekan. Lain kali server bermasalah, kamu tidak perlu menebak: cocokkan gejalanya, buka log yang tepat, dan baca sekitar waktu kejadian.