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 apl...

Masalah yang Sering Tidak Disadari dari Cron Hampir semua tutorial VPS menyuruh Anda menulis jadwal di crontab -e . Itu tidak salah, tapi cron punya tiga kelemahan yang baru terasa saat ada masalah: Tidak ada log bawaan. Kalau job gagal, cron tidak memberi tahu Anda kecuali Anda mengarahkan outputnya sendiri atau mengandalkan email lokal yang sering tidak terkonfigurasi. Tidak ada retry. Kalau server mati tepat di jam jadwal, job itu lewat begitu saja. Tidak ada yang mengejarnya saat server hidup lagi. Lingkungan minimal. Cron menjalankan job dengan PATH dan variabel lingkungan yang sangat terbatas. Script yang jalan mulus di terminal interaktif bisa gagal di cron karena perintah tidak ditemukan. Contoh crontab yang umum: # Backup database setiap hari jam 02:00 0 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup-db.log 2>&1 Lima kolom di depan adalah menit, jam, tanggal, bulan, dan hari dalam seminggu. Baris di atas berarti: menit ke-0, jam ke-2, setiap tangg...