Server yang tiba-tiba lambat, gagal menjalankan proses, atau menolak upload belum tentu mengalami lonjakan trafik. Salah satu penyebab yang sering luput adalah disk yang hampir penuh karena file log terus bertambah.
Log adalah catatan aktivitas aplikasi dan sistem: siapa yang mengakses website, error yang terjadi, proses yang gagal, hingga pesan dari service tertentu. Catatan ini sangat berguna saat troubleshooting. Masalahnya, log tidak selalu berhenti tumbuh. Jika tidak diatur, satu file bisa berukuran gigabyte dan perlahan menghabiskan seluruh ruang penyimpanan.
Penanganannya tidak cukup dengan menghapus semua file di folder /var/log. Beberapa log mungkin masih dibutuhkan untuk investigasi, audit, atau proses aplikasi yang sedang berjalan. Langkah yang lebih aman adalah mencari sumber pemborosan, menyimpan bagian yang penting, lalu menerapkan rotasi log.
Mulai dengan Memeriksa Ruang Disk
Jangan langsung menebak folder mana yang bermasalah. Periksa kapasitas setiap partisi terlebih dahulu dengan perintah:
df -hPerintah tersebut menampilkan kapasitas total, ruang yang sudah terpakai, dan sisa ruang dalam format yang mudah dibaca. Perhatikan kolom persentase penggunaan. Partisi yang mendekati 90 persen perlu segera diperiksa, karena server membutuhkan ruang kosong untuk membuat file sementara, menulis log baru, dan menjalankan proses normal.
Setelah mengetahui partisi yang penuh, cari folder terbesar. Untuk pemeriksaan tingkat awal, gunakan:
sudo du -xhd1 /var | sort -hOpsi -d1 membatasi hasil pada satu tingkat folder, sedangkan sort -h mengurutkan ukuran agar folder terbesar lebih mudah terlihat. Jika ternyata /var/log yang paling besar, lanjutkan pemeriksaan:
sudo du -xhd1 /var/log | sort -hNama file yang umum membesar antara lain syslog, auth.log, nginx, apache2, atau log dari aplikasi yang berjalan dengan systemd.
Bedakan Log Aktif dan Arsip
Sebelum menghapus file, bedakan log yang masih aktif dari arsip lama. File aktif biasanya masih dibuka oleh service. Menghapusnya secara langsung memang dapat mengembalikan ruang pada beberapa kondisi, tetapi proses yang masih memegang file tersebut bisa terus menulis ke inode lama. Akibatnya, ruang disk belum tentu benar-benar kembali sampai service melakukan restart.
Untuk mengetahui apakah file sedang dipakai proses, gunakan:
sudo lsof +L1Perintah ini dapat membantu menemukan file yang sudah dihapus tetapi masih terbuka. Kondisi seperti ini sering membuat hasil df -h terlihat penuh, sementara hasil du tidak menemukan file berukuran setara.
Untuk log yang sudah tidak dibutuhkan dan benar-benar berupa arsip lama, penghapusan dapat dilakukan sesuai kebijakan penyimpanan. Namun, jangan menjadikan perintah seperti rm -rf /var/log/* sebagai solusi standar. Cara tersebut berisiko menghapus struktur folder, permission, atau log yang masih dibutuhkan service.
Gunakan Log Rotation, Bukan Hapus Manual
Log rotation adalah mekanisme untuk mengganti log aktif secara berkala. File lama biasanya diberi nama berbeda, dikompres, lalu dihapus setelah melewati jumlah atau usia tertentu.
Pada banyak distribusi Linux, pengaturan ini dikelola oleh logrotate. Anda dapat memeriksa konfigurasi utamanya dengan:
cat /etc/logrotate.confKonfigurasi khusus aplikasi biasanya berada di:
ls -lah /etc/logrotate.d/Contoh konfigurasi sederhana untuk log aplikasi:
/var/log/aplikasi/*.log {
daily
rotate 14
compress
delaycompress
missingok
notifempty
copytruncate
}Artinya, log diputar setiap hari dan disimpan hingga 14 versi. File lama dikompresi agar lebih hemat ruang. missingok mencegah proses gagal jika file belum ada, sedangkan notifempty menghindari pembuatan arsip untuk log kosong.
Opsi copytruncate dapat berguna untuk aplikasi yang tidak mendukung pembukaan ulang file log. Namun, ada jeda kecil saat file disalin dan dikosongkan, sehingga tidak selalu menjadi pilihan terbaik. Jika aplikasinya mendukung reload atau reopen log, mekanisme tersebut biasanya lebih rapi.
Periksa Penyebab Log Membesar
Rotasi hanya mengendalikan pertumbuhan log. Jika file membesar sangat cepat, penyebab utamanya tetap perlu dicari.
- Error berulang: aplikasi mungkin gagal terhubung ke database atau service tertentu dalam setiap request.
- Mode debug aktif: lingkungan produksi yang masih memakai level log debug dapat menghasilkan catatan jauh lebih banyak.
- Bot atau request mencurigakan: website bisa menerima permintaan otomatis dalam jumlah besar, terutama ke endpoint yang tidak ada.
- Konfigurasi terlalu verbose: beberapa aplikasi mencatat payload, query, atau detail koneksi yang sebenarnya tidak diperlukan setiap saat.
- Service gagal berulang: proses yang terus crash lalu restart dapat menulis pesan error tanpa henti.
Gunakan sebagian isi log untuk mencari pola, bukan hanya menghapusnya. Contohnya:
sudo tail -n 100 /var/log/nginx/error.logJika ingin menghitung pesan yang paling sering muncul, Anda dapat menyalin log ke lokasi kerja terlebih dahulu, lalu menganalisisnya dengan grep, awk, atau alat observabilitas yang digunakan tim.
Jika Disk Sudah Kritis, Lakukan Pemulihan Bertahap
Saat ruang kosong tinggal sedikit, prioritasnya adalah membuat ruang kerja secukupnya tanpa mengganggu service utama.
- Hentikan sementara proses yang terus menghasilkan error, jika memang aman dilakukan.
- Kompres arsip log lama yang masih perlu disimpan.
- Pindahkan arsip ke storage terpisah sesuai kebijakan keamanan dan retensi.
- Jalankan rotasi log secara manual menggunakan mode uji terlebih dahulu.
- Periksa kembali kapasitas dengan
df -h. - Setelah ruang tersedia, cari penyebab error sebelum service dijalankan normal kembali.
Jangan memindahkan log ke sembarang storage publik hanya demi mengosongkan disk. Log bisa mengandung alamat IP, username, token yang tidak sengaja tercatat, atau informasi internal aplikasi. Perlakukan arsip log seperti data operasional, bukan file sampah.
Yang Bisa Dilakukan Sekarang
Jika Anda mengelola VPS atau server website, buat pemeriksaan rutin sederhana: pantau penggunaan disk, tinjau folder log terbesar, pastikan rotasi berjalan, dan tetapkan masa penyimpanan yang masuk akal. Untuk server kecil, menyimpan log aktif selama 7 sampai 14 hari mungkin sudah cukup. Untuk kebutuhan audit atau investigasi, kebijakannya bisa berbeda.
Yang penting, keputusan tersebut dibuat sebelum masalah muncul. Log seharusnya membantu menjawab pertanyaan “apa yang terjadi?”, bukan menjadi penyebab server berhenti bekerja. Dengan rotasi yang tepat, pemantauan kapasitas, dan kebiasaan membaca pola error, Anda bisa menghemat ruang tanpa kehilangan jejak penting saat troubleshooting.
– Rio Yotto @rioyotto
