Logrotate untuk Home Server — Menjaga Log Tetap Berguna Tanpa Memenuhi Disk

Home server bisa bekerja diam-diam selama berbulan-bulan, dan justru karena itulah log-nya mudah terlupakan. Lalu pada suatu malam sebuah aplikasi menolak menulis data, update gagal, dan df -h menunjukkan bahwa file log yang terlihat sepele sudah menghabiskan sisa ruang disk.

Aku membayangkan log seperti kumpulan struk di laci dapur. Menyimpannya berguna saat ada sesuatu yang perlu diperiksa, tetapi menyimpan semua struk selamanya akhirnya membuat laci tidak bisa dipakai. logrotate memberi Linux rutinitas untuk merapikan laci itu: menutup bundel saat ini, mempertahankan riwayat terbatas, mengompresi catatan lama, dan membuang yang sudah melewati masa gunanya.

Apa yang sebenarnya dilakukan log rotation

Rotation biasanya tidak menghapus active log begitu saja tanpa jejak. Proses ini mengganti nama atau mengarsipkan file tersebut, menyediakan ruang untuk file baru, lalu menerapkan retention policy pada arsip lama. File bernama app.log bisa berubah menjadi app.log.1, kemudian app.log.2.gz, sementara aplikasi melanjutkan penulisan ke app.log yang baru.

Ini menyelesaikan dua masalah yang saling berkaitan. Pertama, satu file tidak lagi tumbuh tanpa batas. Kedua, troubleshooting tetap praktis karena riwayat terbaru disimpan dalam potongan yang mudah diprediksi. Rotation bukan centralized log management ataupun backup. Ia adalah pekerjaan rumah lokal, dan tetap berguna baik server hanya menjalankan satu script buatan sendiri maupun observability stack lengkap.

Periksa setup yang ada sebelum mengubahnya

Di Debian dan banyak distribution lain, konfigurasi utama berada di /etc/logrotate.conf, sedangkan rule khusus package tersimpan di /etc/logrotate.d/. Sistem biasanya menjalankan logrotate melalui systemd timer atau scheduled job. Mulailah dengan memeriksa apa yang sudah tersedia, bukan membuat scheduler kedua.

logrotate --version
systemctl status logrotate.timer
systemctl list-timers logrotate.timer
sudo ls -l /etc/logrotate.d/
sudo cat /etc/logrotate.conf

Timer mungkin berjalan setiap hari, tetapi itu tidak berarti semua file dirotasi setiap hari. Scheduler hanya meminta logrotate mengevaluasi rule-nya. State yang disimpan di /var/lib/logrotate/status membuatnya mengingat kapan setiap log terakhir diproses. Pemisahan ini seperti petugas yang memeriksa setiap ruangan pada pagi hari: pemeriksaannya harian, tetapi tempat sampah hanya dikosongkan jika rule-nya mengatakan sudah waktunya.

Buat rule untuk aplikasi khusus

Anggap sebuah aplikasi self-hosted menulis ke /var/log/myapp/app.log. Buat /etc/logrotate.d/myapp dengan policy yang terfokus. Contoh berikut melakukan rotation mingguan, tetapi juga melakukannya lebih cepat saat active file mencapai 50 MB.

/var/log/myapp/app.log {
    weekly
    size 50M
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
    su myapp adm
}

rotate 8 mempertahankan delapan generasi arsip. compress menghemat ruang disk, sedangkan delaycompress membiarkan arsip terbaru tidak terkompresi sampai cycle berikutnya; ini dapat membantu software yang masih membuka file lama untuk sesaat. missingok mencegah error ketika log tidak ada, dan notifempty melewati file kosong.

Baris create menentukan permission, owner, dan group untuk file pengganti. Nilainya harus cocok dengan service yang menulis log. Directive su memberi tahu logrotate user dan group yang digunakan saat merotasi log dalam directory tersebut. Jangan menyalin identity ini begitu saja: periksa dengan stat /var/log/myapp/app.log dan lihat service definition terlebih dahulu.

Pilih waktu, ukuran, dan retention secara sengaja

Policy yang baik mengikuti laju produksi data dan panjang riwayat yang benar-benar berguna. Backup script yang jarang berjalan mungkin cukup memakai rotation bulanan. Reverse proxy yang menerima banyak request mungkin membutuhkan rotation harian atau berdasarkan ukuran. Mempertahankan delapan arsip mingguan memberi sekitar dua bulan riwayat, tetapi tidak menjamin jumlah hari yang persis ketika size threshold memicu rotation tambahan.

Perhatikan perbedaan antara size, minsize, dan maxsize. size 50M menjadikan ukuran sebagai trigger utama. minsize 50M hanya merotasi ketika scheduled period sudah lewat dan ukuran file cukup besar. maxsize 50M mengizinkan rotation lebih awal setelah file melewati batas, meskipun interval waktunya belum selesai.

Retention juga perlu menyesuaikan kebutuhan recovery. Security dan audit log mungkin memerlukan periode lebih panjang daripada debug output yang ramai. Namun, retention rule bukan compliance strategy yang lengkap. Siapa pun yang berhasil menguasai server mungkin juga dapat mengubah arsip lokal, sehingga evidence penting sebaiknya dikirim ke sistem terpisah dengan access control yang sesuai.

Tangani aplikasi yang terus membuka file

Mengganti nama log hanya bekerja dengan mulus ketika aplikasi dapat membuka ulang file-nya. Beberapa daemon memahami signal, beberapa menyediakan reload command, dan yang lain terus menulis ke inode yang sudah diganti namanya. Dalam kasus terakhir, file baru tetap kosong sementara penggunaan disk terus bertambah pada arsip.

Untuk systemd service yang membuka ulang log setelah reload, tambahkan script postrotate. Script berjalan setelah rotation, dan sharedscripts memastikan ia hanya dijalankan sekali walaupun sebuah pattern cocok dengan beberapa file.

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 0640 myapp adm
    sharedscripts
    postrotate
        systemctl reload myapp.service >/dev/null 2>&1 || true
    endscript
}

Gunakan command yang direkomendasikan aplikasi, jangan berasumsi reload selalu didukung. copytruncate adalah fallback yang menyalin file lalu mengosongkan file asli di tempat, tetapi sebagian tulisan bisa hilang dalam interval kecil di antara dua operasi itu. Ia praktis, tetapi bukan pilihan ideal. Aplikasi yang mencatat langsung ke journald biasanya tidak memerlukan custom logrotate rule karena journald memiliki kontrol ukuran dan retention sendiri.

Uji rule tanpa mempertaruhkan production log

Konfigurasi perlu diuji sebelum menunggu scheduled run berikutnya. Debug mode membaca konfigurasi dan menjelaskan apa yang akan dilakukan logrotate tanpa mengubah file. Jalankan terhadap rule tertentu terlebih dahulu.

sudo logrotate --debug /etc/logrotate.d/myapp
sudo logrotate --verbose /etc/logrotate.d/myapp

Verbose command hanya melakukan tindakan yang memang sudah waktunya. Untuk pengujian satu kali yang terkendali, memaksa rotation memang bisa dilakukan, tetapi jangan menjadikannya command rutin karena setiap forced run memajukan rantai arsip.

sudo logrotate --force --verbose /etc/logrotate.d/myapp
sudo ls -lh /var/log/myapp/
sudo systemctl status myapp.service

Sesudahnya, pastikan service tetap sehat, active file mempunyai ownership yang benar, baris baru muncul di dalamnya, dan archived file dapat dibaca. Jika compression aktif, zless atau zgrep bisa memeriksa arsip .gz tanpa mengekstraknya secara manual.

Monitor policy agar tidak kembali terlupakan

Rotation mengurangi risiko, tetapi typo, perubahan service account, atau kegagalan reload dapat diam-diam merusak rutinitas. Periksa timer dalam maintenance server biasa dan tinjau journal terbarunya. Disk alert tetap diperlukan karena log hanyalah salah satu kemungkinan pemakai storage.

systemctl list-timers logrotate.timer
journalctl -u logrotate.service --since "7 days ago"
df -h
sudo du -xhd1 /var/log | sort -h

Policy yang sehat menghasilkan bukti yang dapat diamati: ukuran active file terbatas, arsip memiliki tanggal yang masuk akal, permission benar, dan tidak ada error berulang dalam service journal. Setting juga layak ditinjau ulang setelah traffic berubah. Threshold 50 MB yang terasa longgar untuk personal project bisa menjadi terlalu kecil setelah aplikasi memperoleh pengguna.

Kesimpulan: buat log terbatas, bukan sekali pakai

Tujuan logrotate bukan membuat log menghilang. Tujuannya menjaga log tetap berguna dalam batas yang sanggup ditanggung server. Periksa scheduler yang sudah ada, tulis satu rule yang sempit, cocokkan ownership dengan aplikasi, perhitungkan open file handle, dan uji memakai debug mode sebelum memaksa apa pun.

Rutinitas kecil itu mengubah penggunaan disk dari kejutan menjadi policy. Jika kamu mempunyai logrotate rule yang pernah menyelamatkan home server, atau aplikasi yang membutuhkan command postrotate tidak biasa, bagikan pengalamannya di kolom komentar agar self-hoster lain dapat ikut belajar.