--- title: "Cara Mengatur logrotate agar Log Tidak Memenuhi Disk" description: "Disk server penuh gara-gara log? Atur logrotate untuk log aplikasi, pahami opsi pentingnya, uji dengan mode debug, lalu batasi log journald dan Docker." url: "https://nivelva.com/insight/cara-mengatur-logrotate-log-tidak-memenuhi-disk" category: "Server \u0026 Infrastruktur" tags: ["logrotate","log linux","disk penuh","journald","server"] author: "Lucas Tan" published: "2026-11-11T12:53:00+07:00" updated: "2026-11-11T12:53:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Cara Mengatur logrotate agar Log Tidak Memenuhi Disk > **Jawaban singkat:** logrotate memutar, mengompres, dan menghapus file log lama secara terjadwal. Buat satu file aturan di /etc/logrotate.d untuk log aplikasimu, tentukan jadwal, jumlah arsip, dan batas ukuran, uji dengan logrotate -d, lalu batasi juga journald dan log Docker yang tidak diatur logrotate. Supaya log tidak memenuhi disk, setiap file log yang terus tumbuh harus punya aturan rotasi: kapan dipotong, berapa arsip disimpan, dan kapan arsip lama dihapus. Di Linux, tugas itu dikerjakan logrotate, yang sudah terpasang di hampir semua distribusi server. Kenapa ini penting? Log aplikasi yang lupa diatur bisa tumbuh diam-diam sampai partisi penuh. Saat disk 100%, database berhenti menulis, sesi login gagal, dan website bisa mati padahal servernya sehat. Paket resmi seperti Nginx dan MySQL biasanya sudah membawa aturan sendiri. Yang sering terlupa adalah log aplikasi buatan sendiri, log journald, dan log container Docker. ## Bagaimana logrotate dijalankan? logrotate bukan layanan yang berjalan terus. Ia dipanggil terjadwal, di Ubuntu dan Debian modern lewat `logrotate.timer` dari systemd (di sistem lama lewat cron harian). Cek dengan: ``` systemctl list-timers | grep logrotate ``` Konfigurasi utama ada di `/etc/logrotate.conf`, yang memuat semua file di `/etc/logrotate.d/`. Satu file per aplikasi adalah cara paling rapi. Status rotasi terakhir disimpan di file status (di Ubuntu `/var/lib/logrotate/status`). ## Membuat aturan untuk log aplikasi Misalnya aplikasi kamu menulis log ke `/var/www/app/storage/logs/*.log`. Buat file `/etc/logrotate.d/app`: ``` /var/www/app/storage/logs/*.log { daily rotate 14 maxsize 200M compress delaycompress missingok notifempty create 0640 www-data www-data su www-data www-data } ``` Dengan aturan itu, log diputar setiap hari atau lebih cepat bila ukurannya melewati 200 MB pada saat logrotate berjalan, 14 arsip terakhir disimpan, dan yang lebih lama dihapus. ## Arti opsi yang paling sering dipakai - `daily`, `weekly`, `monthly`: jadwal rotasi. - `rotate 14`: jumlah arsip yang disimpan. Arsip ke-15 dihapus. - `size 100M`: rotasi hanya berdasarkan ukuran, mengabaikan jadwal. - `maxsize 200M`: rotasi sesuai jadwal, atau lebih awal bila ukuran terlampaui. - `compress` dan `delaycompress`: arsip dikompres gzip, tapi arsip terbaru dibiarkan sekali tanpa kompres agar aplikasi yang masih menulis ke file lama tidak terganggu. - `missingok` dan `notifempty`: tidak error bila file tidak ada, dan tidak memutar file kosong. - `create 0640 user grup`: membuat file log baru dengan izin dan pemilik tertentu setelah rotasi. - `su user grup`: menjalankan rotasi sebagai user tertentu. Diperlukan bila folder log bisa ditulis oleh user selain root, kalau tidak logrotate menolak dengan peringatan soal izin folder. - `postrotate` sampai `endscript`: perintah yang dijalankan setelah rotasi, misalnya memberi sinyal ke aplikasi untuk membuka file log baru. - `sharedscripts`: skrip postrotate dijalankan sekali saja walau pola file cocok dengan banyak log. ## create atau copytruncate? Ini pilihan yang sering membingungkan. Aplikasi yang sedang berjalan memegang file log yang terbuka. Setelah file diganti nama, aplikasi itu tetap menulis ke file lama kecuali diberi tahu. | Cara | Cara kerja | Cocok untuk | |:--|:--|:--| | `create` + `postrotate` | File diganti nama, file baru dibuat, aplikasi diminta membuka ulang lewat sinyal atau reload | Nginx, aplikasi yang mendukung reopen log | | `copytruncate` | Isi file disalin ke arsip, lalu file asli dikosongkan di tempat | Aplikasi yang tidak bisa diminta membuka ulang log | Dokumentasi logrotate mengingatkan bahwa `copytruncate` punya jeda kecil antara menyalin dan mengosongkan, sehingga sebagian baris log bisa hilang. Kalau aplikasimu mendukung reload log, pilih `create`. Contoh aturan Nginx bawaan Ubuntu memakai `postrotate` yang mengirim sinyal ke proses Nginx. ## Contoh aturan dengan postrotate Untuk aplikasi yang bisa diminta membuka ulang file log, misalnya lewat reload systemd, aturannya bisa seperti ini: ``` /var/log/app/*.log { weekly rotate 8 compress delaycompress missingok notifempty create 0640 app app sharedscripts postrotate systemctl reload app.service > /dev/null 2>&1 || true endscript } ``` `sharedscripts` memastikan reload hanya dijalankan sekali walau ada beberapa file log yang diputar. Bagian `|| true` mencegah logrotate menganggap rotasi gagal bila layanan sedang tidak berjalan. Pastikan perintah reload aplikasimu memang membuka ulang file log; kalau tidak, pakai `copytruncate`. ## Menguji aturan sebelum dipercaya Jalankan mode debug. Mode ini hanya menampilkan apa yang akan dilakukan tanpa mengubah file: ``` sudo logrotate -d /etc/logrotate.d/app ``` Bila sudah yakin, paksa satu kali rotasi untuk melihat hasil nyata: ``` sudo logrotate -f -v /etc/logrotate.d/app ls -lh /var/www/app/storage/logs/ ``` Pastikan ada file `.1` atau arsip `.gz`, dan file log baru dibuat dengan pemilik yang benar. Kalau aplikasi berhenti menulis log setelah rotasi, berarti ia masih menulis ke file lama dan kamu perlu `postrotate` atau `copytruncate`. ## Jangan lupa journald dan Docker logrotate tidak mengurus dua sumber log besar ini. **journald** menyimpan log systemd dalam format biner. Batasi ukurannya di `/etc/systemd/journald.conf`: ``` [Journal] SystemMaxUse=500M ``` Lalu `sudo systemctl restart systemd-journald`. Untuk membersihkan sekarang juga, pakai `sudo journalctl --vacuum-size=500M`. Cara membaca log ini dibahas di [panduan journalctl](https://nivelva.com/insight/cara-membaca-log-aplikasi-journalctl). **Docker** dengan driver log bawaan `json-file` tidak membatasi ukuran log container. Atur di `/etc/docker/daemon.json`: ``` { "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } } ``` Pengaturan ini hanya berlaku untuk container yang dibuat setelah Docker di-restart. Container lama perlu dibuat ulang. > **Cari dulu siapa yang memakan disk:** > > Sebelum mengatur apa pun, lihat folder mana yang paling besar dengan `sudo du -xh /var/log | sort -h | tail` atau langkah di [panduan disk server penuh](https://nivelva.com/insight/disk-server-penuh). Sering kali satu file log yang tidak pernah diputar adalah penyebab utamanya. ## Pertanyaan yang sering diajukan ### Kenapa file log sudah dihapus tapi disk tidak lega? Karena masih ada proses yang memegang file itu terbuka. Cek dengan `sudo lsof +L1`, lalu restart atau reload proses tersebut agar ruangnya dilepas. ### Apakah aman menghapus file .gz lama di /var/log? Umumnya aman bila kamu tidak membutuhkannya untuk audit. Tapi lebih baik atur jumlah arsip lewat opsi rotate agar pembersihan berjalan otomatis dan konsisten. ### Berapa lama log sebaiknya disimpan? Tergantung kebutuhan. Untuk pemecahan masalah harian, beberapa minggu biasanya cukup. Bila ada kebutuhan audit atau aturan internal, kirim log ke penyimpanan terpisah daripada menumpuknya di disk server. ## Sumber - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/cara-mengatur-logrotate-log-tidak-memenuhi-disk Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com