Membaca Log Server: journalctl, logrotate, dan Cara Menghemat Disk

Server yang sehat jarang berteriak. Ia berbisik lewat log. Masalahnya, bisikan itu tersebar di banyak tempat: log systemd, log Nginx, log aplikasi, dan log sistem. Kalau Anda tidak tahu ke mana harus melihat pertama kali, troubleshooting berubah jadi menebak-nebak.

Artikel ini merangkum alur yang saya pakai setiap kali ada server bermasalah: cek log yang relevan, persempit waktunya, temukan baris error yang benar, lalu rapikan log supaya disk tidak penuh diam-diam.

1. journalctl: satu pintu untuk semua log systemd

Di Ubuntu 24.04, hampir semua layanan yang dijalankan systemd mencatat ke journal. Artinya satu perintah, journalctl, bisa menjawab sebagian besar pertanyaan "kenapa layanan ini mati?"

Melihat log satu layanan

# 100 baris terakhir dari layanan nginx
sudo journalctl -u nginx -n 100
# Mengikuti log secara live, seperti tail -f
sudo journalctl -u nginx -f

Flag -u memilih unit. Ganti nginx dengan nama layanan apa pun: ssh, docker, cron, atau nama service aplikasi Anda.

Mempersempit berdasarkan waktu

Log yang menumpuk berhari-hari tidak berguna kalau Anda tidak bisa memfilter waktunya. Dua flag ini yang paling sering saya pakai:

# Log sejak boot terakhir (paling berguna setelah server restart sendiri)
sudo journalctl -u nginx -b
# Log dari 1 jam terakhir
sudo journalctl -u nginx --since "1 hour ago"
# Rentang waktu spesifik
sudo journalctl -u nginx --since "2026-10-25 08:00" --until "2026-10-25 10:00"

Kombinasi --since dan -b menyelesaikan sebagian besar kasus: Anda tahu kapan masalah terjadi, Anda hanya melihat log di sekitar waktu itu.

Hanya tampilkan error

Saat log sudah disaring waktunya tapi masih ramai, saring lagi berdasarkan level:

# Hanya error dan yang lebih parah (err, crit, alert, emerg)
sudo journalctl -u nginx -p err -b

# Semua level dari warning ke atas
sudo journalctl -u nginx -p warning -b

Memulai dari baris error menghemat banyak waktu dibanding membaca log baris demi baris dari atas. Jangan membaca log baris demi baris dari atas — mulai dari error, baru mundur ke belakang untuk mencari penyebabnya.

Mencari kata kunci

# Cari "failed" atau "timeout" di log satu layanan
sudo journalctl -u docker --since "2 hours ago" | grep -iE "failed|timeout|oom|killed"

# Melihat log semua layanan, diurutkan waktu, khusus pesan kernel
sudo journalctl -k -b

Pola yang layak dicari saat server bermasalah: oom (kehabisan RAM, proses di-kill kernel), failed, timeout, connection refused, dan no space left. Pola terakhir itu sering jadi akar masalah yang disangka masalah aplikasi.

2. Contoh kasus nyata: layanan mati tanpa pesan jelas

Suatu malam, sebuah aplikasi web berhenti merespons. Nginx masih jalan, tapi upstream tidak menjawab. Alur pemeriksaannya seperti ini:

Langkah 1 — cek status layanan:

sudo systemctl status app-saya --no-pager

Status menunjukkan failed, tapi pesan di situ singkat. Lanjut ke log.

Langkah 2 — log sejak boot terakhir, hanya error:

sudo journalctl -u app-saya -p err -b

Di sana terlihat baris seperti Failed to bind to port 3000: address already in use. Ternyata proses lama dari deploy sebelumnya tidak mati saat restart, sehingga proses baru gagal mengambil port.

Langkah 3 — cari siapa yang memegang port itu:

sudo ss -tlnp | grep 3000

Lalu proses lama dihentikan, layanan di-restart, dan masalah selesai. Total waktu: kurang dari sepuluh menit — karena log menunjuk langsung ke penyebabnya, bukan ke gejala.

Pelajaran dari kasus ini: selalu baca log layanan yang gagal dulu, sebelum me-restart membabi buta. Restart tanpa membaca log sering hanya memindahkan masalah ke besok.

3. Log file klasik di /var/log

Tidak semua aplikasi memakai journal. Nginx, misalnya, secara default menulis ke file:

# Error log Nginx
sudo tail -n 100 /var/log/nginx/error.log

# Access log, difilter hanya respons error 5xx
sudo grep " 5[0-9][0-9] " /var/log/nginx/access.log | tail -n 50

Dua file lain yang layak dikenal:

  • /var/log/syslog — pesan umum sistem.
  • /var/log/auth.log — login SSH, percobaan gagal, dan sudo. File ini yang pertama dibuka saat ada dugaan akses mencurigakan.
# Percobaan login SSH yang gagal, 20 baris terakhir
sudo grep "Failed password" /var/log/auth.log | tail -n 20

Untuk file log biasa, tail -f tetap alat terbaik untuk memantau live:

sudo tail -f /var/log/nginx/error.log

4. logrotate: supaya log tidak memakan disk diam-diam

Ini masalah klasik server yang dibiarkan berbulan-bulan: semuanya berjalan normal, lalu tiba-tiba disk penuh 100% dan semua layanan mulai gagal. Penyebabnya sering kali satu file log yang membengkak tanpa rotasi.

Ubuntu sudah membawa logrotate, dan sebagian besar layanan sudah punya konfigurasinya di /etc/logrotate.d/. Yang perlu Anda lakukan adalah memastikan konfigurasinya masuk akal, bukan memasang sesuatu yang baru.

Contoh konfigurasi untuk aplikasi sendiri, di /etc/logrotate.d/app-saya:

/var/log/app-saya/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    sharedscripts
    postrotate
        systemctl reload app-saya >/dev/null 2>&1 || true
    endscript
}

Artinya: rotasi setiap hari, simpan 14 arsip terakhir, kompres arsip lama, lewati kalau file tidak ada, dan beri tahu layanan untuk membuka file log baru setelah rotasi. Blok postrotate penting — tanpa itu, aplikasi yang sudah membuka file log lama akan terus menulis ke file yang sudah dirotasi, dan disk tidak benar-benar lega.

Untuk menguji konfigurasi tanpa menunggu jadwal harian:

# Simulasi saja, tidak mengubah apa pun
sudo logrotate -d /etc/logrotate.d/app-saya

# Jalankan rotasi paksa untuk memastikan konfigurasinya benar
sudo logrotate -f /etc/logrotate.d/app-saya

Flag -d adalah teman terbaik Anda di sini: ia menampilkan keputusan logrotate baris demi baris tanpa menyentuh file.

5. Menghemat disk: batasi journal dan bersihkan log lama

Journal systemd juga bisa membengkak. Secara default, systemd membatasi ukurannya, tapi di server kecil batas itu tetap bisa terasa besar. Cek dulu seberapa besar journal Anda:

sudo journalctl --disk-usage

Kalau angkanya sudah ratusan MB atau GB, batasi secara permanen di /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=500M
MaxFileSec=14day

Lalu terapkan:

sudo systemctl restart systemd-journald

Untuk pembersihan sekali jalan — misalnya journal sudah telanjur 3 GB — hapus yang lebih lama dari 14 hari:

sudo journalctl --vacuum-time=14d

Atau batasi langsung berdasarkan ukuran:

sudo journalctl --vacuum-size=500M

Dua perintah vacuum ini aman untuk log yang sedang berjalan: ia hanya menghapus arsip lama, bukan log aktif.

Untuk gambaran disk secara keseluruhan, jangan menebak:

# 10 direktori terbesar di /var/log
sudo du -sh /var/log/* | sort -rh | head -n 10

# Ruang kosong disk secara keseluruhan
df -h /

Biasakan memeriksa /var/log setiap kali df -h menunjukkan disk di atas 80%. Log adalah tersangka pertama yang paling mudah dibersihkan — dan paling sering terlewat.

Checklist penutup

  • Saat layanan gagal, buka dulu journalctl -u <nama-layanan> -p err -b sebelum me-restart.
  • Persempit log dengan --since di sekitar waktu kejadian, bukan membaca dari awal.
  • Kenali tiga pola: oom, failed, dan no space left — ketiganya sering jadi akar, bukan gejala.
  • Pastikan setiap aplikasi yang menulis file log punya konfigurasi di /etc/logrotate.d/, dan uji dengan logrotate -d.
  • Batasi journal di journald.conf (misalnya SystemMaxUse=500M) dan bersihkan arsip lama dengan --vacuum-time.
  • Jadwalkan cek df -h dan du -sh /var/log/* secara berkala — disk penuh karena log adalah insiden yang sepenuhnya bisa dicegah.

Komentar

Posting Komentar