Disk Server Cepat Penuh? Bisa Jadi Log Aplikasi yang Tidak Pernah Berhenti

Server yang tiba-tiba kehabisan disk sering membuat orang langsung berpikir tentang database, file upload, atau backup. Padahal, penyebabnya bisa lebih sederhana: log aplikasi yang terus bertambah tanpa pernah diputar atau dihapus.

Log adalah catatan aktivitas sistem—misalnya permintaan HTTP, error aplikasi, proses login, atau pesan dari container. Ia sangat berguna ketika kita perlu mencari penyebab gangguan. Namun, log bukan arsip abadi. Jika setiap request dicatat terlalu detail dan disimpan tanpa batas, server kecil bisa kehabisan ruang dalam hitungan hari.

Kenapa log bisa menjadi masalah besar?

Bayangkan log seperti buku catatan operasional. Satu catatan mungkin kecil, tetapi jika aplikasi menerima ribuan permintaan setiap jam, jumlahnya cepat menumpuk. Pesan seperti GET /api/products, status code, alamat IP, dan waktu akses mungkin hanya memakan beberapa ratus byte. Dalam skala besar, akumulasinya bisa mencapai gigabyte.

Masalahnya tidak hanya soal storage. Ketika disk hampir penuh, aplikasi dapat gagal menulis file sementara, database kesulitan membuat file tambahan, proses deployment berhenti, bahkan sistem operasi bisa berperilaku tidak stabil. Karena itu, log seharusnya diperlakukan sebagai bagian dari desain operasional, bukan sekadar output tambahan dari aplikasi.

Docker sendiri memperingatkan bahwa driver json-file dapat membuat file log membesar jika rotasi tidak dikonfigurasi. Dokumentasi Docker merekomendasikan penggunaan rotasi log atau driver local untuk mengurangi risiko disk penuh. ([docs.docker.com](https://docs.docker.com/engine/logging/configure/?utm_source=openai))

Mulai dengan mencari siapa yang menghabiskan disk

Jangan langsung menghapus folder log secara acak. Langkah pertama adalah mencari lokasi yang paling banyak menggunakan ruang.

df -h
sudo du -sh /var/log/* 2>/dev/null | sort -h
sudo du -sh /var/lib/docker/* 2>/dev/null | sort -h

Perintah df -h memberi gambaran penggunaan partisi. Sementara itu, du membantu melihat folder mana yang paling besar. Pada server yang menjalankan Docker, perhatikan direktori data Docker karena log container biasanya tersimpan di area tersebut.

Jika penggunaan disk sudah mendekati 90 persen, lakukan pemeriksaan lebih terarah. Cari file besar yang berubah baru-baru ini, periksa log aplikasi tertentu, dan lihat apakah ada proses yang menghasilkan error berulang. Log yang terus mencatat stack trace atau pesan gagal koneksi biasanya menjadi tersangka utama.

Bedakan log aktif, log lama, dan data penting

Tidak semua file log aman untuk dihapus. Ada log yang masih sedang ditulis oleh aplikasi, ada log lama yang sudah diputar, dan ada pula log audit yang harus disimpan lebih lama karena kebutuhan bisnis atau kepatuhan.

Hindari perintah seperti menghapus seluruh isi /var/log tanpa memahami dampaknya. File yang sedang digunakan proses aktif bisa menimbulkan kebingungan saat layanan mencoba menulis ulang. Untuk systemd journal, misalnya, tersedia mekanisme khusus seperti journalctl --vacuum-time=7d untuk menghapus arsip journal yang lebih lama dari tujuh hari. Dokumentasi systemd juga menyediakan opsi berdasarkan ukuran dan jumlah file. ([freedesktop.org](https://www.freedesktop.org/software/systemd/man/255/journalctl.html?utm_source=openai))

Contoh pembersihan yang lebih hati-hati:

sudo journalctl --disk-usage
sudo journalctl --vacuum-time=7d

Angka tujuh hari bukan aturan universal. Pilih masa simpan berdasarkan kebutuhan troubleshooting. Untuk aplikasi sederhana, beberapa hari mungkin cukup. Untuk sistem keuangan atau layanan yang perlu investigasi insiden, log tertentu mungkin harus dikirim ke penyimpanan terpisah dan disimpan lebih lama.

Pasang log rotation, bukan mengandalkan pembersihan manual

Membersihkan log secara manual hanya menyelesaikan masalah hari ini. Solusi yang lebih sehat adalah log rotation, yaitu mekanisme yang mengganti file log aktif ketika mencapai ukuran atau usia tertentu, lalu mengompres atau menghapus file lama.

Untuk container Docker, salah satu contoh konfigurasi adalah:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Dengan konfigurasi tersebut, setiap container dibatasi pada beberapa file log berukuran tertentu. Dokumentasi Docker menyebut driver local memakai rotasi otomatis, dengan nilai bawaan yang membatasi ukuran log per container. Perlu diingat, perubahan konfigurasi daemon biasanya berlaku untuk container yang dibuat setelah konfigurasi diterapkan; container lama perlu diperiksa dan dikonfigurasi ulang jika diperlukan. ([docs.docker.com](https://docs.docker.com/engine/logging/drivers/local/?utm_source=openai))

Jika menggunakan Nginx, Apache, aplikasi Node.js, atau service Linux lain yang menulis file langsung ke disk, periksa konfigurasi logrotate. Pastikan file lama dikompresi, jumlah salinannya terbatas, dan aplikasi diberi tahu untuk membuka file baru setelah rotasi.

Kirim log penting ke tempat terpisah

Rotasi lokal penting, tetapi jangan menjadikannya satu-satunya salinan. Jika server rusak, log lokal bisa ikut hilang. Untuk log yang penting bagi pemantauan dan investigasi, gunakan layanan terpusat atau kirim ke server log terpisah.

Contohnya, CloudWatch Logs dapat menyimpan log dari instance, aplikasi, dan layanan lain. Namun, masa simpan perlu diatur karena secara default log dapat disimpan tanpa batas. AWS menyediakan pengaturan retensi per log group, sehingga tim dapat memilih masa simpan yang sesuai. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html?utm_source=openai))

Strategi yang masuk akal adalah menyimpan log operasional yang sering dicari dalam periode pendek, misalnya 7–30 hari, lalu mengarsipkan log audit atau keamanan ke storage yang lebih murah. Jangan menyamakan semua log. Log debug yang sangat detail tidak harus diperlakukan sama dengan catatan transaksi atau aktivitas administratif.

Yang bisa dilakukan sekarang

1. Cek kapasitas disk: jalankan df -h dan cari partisi yang hampir penuh.
2. Identifikasi sumber terbesar: periksa /var/log, data Docker, cache, file upload, dan backup lokal.
3. Hentikan sumber ledakan log: cari error berulang atau level logging yang terlalu detail.
4. Aktifkan rotasi: tetapkan batas ukuran dan jumlah file untuk setiap service atau container.
5. Tentukan masa simpan: pisahkan log untuk debugging, keamanan, audit, dan kebutuhan bisnis.
6. Gunakan penyimpanan terpusat: kirim log penting keluar dari server utama dan batasi aksesnya.
7. Buat alarm: pantau penggunaan disk, misalnya saat melewati 70, 80, dan 90 persen.

Intinya

Server penuh karena log bukan masalah yang sulit jika ditemukan lebih awal. Yang berbahaya adalah membiarkannya tanpa batas, lalu baru bertindak ketika aplikasi sudah gagal menulis data.

Log yang baik bukan log yang menyimpan semuanya selamanya. Log yang baik adalah log yang cukup detail untuk membantu mengambil keputusan, memiliki masa simpan yang jelas, terlindungi dari penghapusan sembarangan, dan tidak dibiarkan menghabiskan ruang kerja server.

Sumber & bacaan lebih lanjut

• Docker Docs: Configure logging drivers
• Docker Docs: Local file logging driver
• systemd journalctl documentation
• AWS CloudWatch Logs: Working with log groups and log streams
• AWS CloudWatch Logs overview

– Rio Yotto @rioyotto