Menentukan Pengaturan Batas Log Lewat journald atau logrotate

Banyak pengelola server baru menyadari masalah log saat disk root tiba-tiba menyentuh angka seratus persen atau notifikasi kehabisan ruang penyimpanan mulai bermunculan. Reaksi yang sering terjadi adalah mencari direktori /var/log, melihat file mana yang ukurannya puluhan gigabyte, lalu bingung apakah harus menghapusnya langsung, menyetel logrotate, atau mengubah file konfigurasi journald. Dua alat ini sering dianggap saling menggantikan, padahal tugas dan cara kerjanya berbeda dari hulu sampai hilir. Jika kamu salah memilih tempat untuk mengatur batas retensi, konfigurasi yang kamu tulis tidak akan berpengaruh apa-apa. File log tetap membesar, ruang penyimpanan tetap habis, dan server berisiko macet di tengah jalan.

Memahami perbedaan lewat analogi pipa air dan wadah penampung

Untuk membedakan keduanya, bayangkan log sebagai air yang keluar dari berbagai kran di rumah kamu. systemd-journald (sering disingkat journald) bekerja seperti pipa utama terintegrasi. Ketika sebuah service Linux dijalankan oleh systemd dan memuntahkan teks ke output standar (stdout atau stderr), data teks tersebut langsung ditangkap oleh journald di gerbang masuk. journald menyaring, memberi cap waktu, dan menyimpannya ke dalam format biner terindeks di memori atau di direktori /var/log/journal/. journald mengelola sendiri ukuran "pipa" dan "ember" miliknya secara internal tanpa perlu bantuan cron job dari luar. Sementara itu, logrotate adalah petugas kebersihan terjadwal yang datang secara berkala, misalnya sekali sehari atau seminggu sekali lewat cron job atau systemd timer. logrotate tidak pernah duduk di antara aplikasi dan aliran log. Aplikasi seperti web server Nginx atau mail server Exim biasanya menulis file teks biasa secara mandiri langsung ke /var/log/nginx/access.log atau /var/log/exim4/mainlog. logrotate bertugas mendatangi file-file teks tersebut, mengganti namanya menjadi arsip berurutan, mengompresinya menjadi .gz, dan menghapus arsip yang umurnya sudah melewati batas rotasi. Karena mekanismenya berbeda, kamu tidak bisa meminta logrotate untuk mengompresi log biner journald, begitu pula kamu tidak bisa meminta konfigurasi journald untuk memotong file access.log milik Apache atau Nginx.

Cara journald mengontrol ukuran log di hulunya

journald dirancang untuk mengelola dirinya sendiri agar tidak menghabiskan seluruh disk. Masalahnya, nilai bawaan journald di beberapa distro Linux sering kali mengizinkan pemakaian ruang disk yang relatif besar, misalnya hingga sepuluh persen dari total kapasitas partisi atau batas tertentu seperti beberapa gigabyte. Di VPS berukuran kecil, sepuluh persen bisa memakan ruang bernilai gigabyte yang sebenarnya kamu perlukan untuk database atau berkas web. Batas journald diatur di /etc/systemd/journald.conf atau file drop-in di /etc/systemd/journald.conf.d/. Parameter yang paling sering digunakan adalah SystemMaxUse. Begitu total ukuran file log biner journald mencapai nilai tersebut, journald secara otomatis akan menghapus potongan log biner tertua (vacuuming) agar ukurannya tetap di bawah ambang batas. Keuntungan utama membatasi log di journald adalah kontrol berbasis ukuran yang sifatnya terus-menerus. Jika sebuah service mendadak mengalami error loop dan menulis ribuan pesan per detik, journald akan langsung menendang log lama saat kuota tercapai tanpa menunggu pergantian hari. Log biner ini juga bisa kamu batasi dan pelajari lebih lanjut teknik hematnya pada artikel Practical Notes on Minimizing ram and disk used by systemd-journald.

Peran logrotate untuk aplikasi yang menulis file teks sendiri

Tidak semua log lewat di depan pintu journald. Aplikasi yang memiliki logging framework sendiri cenderung membuka file teks secara langsung di disk dan menulis entri log ke sana lewat file descriptor milik prosesnya sendiri. Karena aplikasi ini tidak peduli berapa sisa ruang disk kamu, file teks tersebut akan membesar tanpa batas kecuali ada yang memotongnya. Di sinilah logrotate mengambil peran. logrotate membaca konfigurasi di /etc/logrotate.conf dan file per-aplikasi di /etc/logrotate.d/. Satu hal krusial yang perlu dipahami: logrotate bukan daemon yang berjalan sepanjang waktu di memori. Dia dieksekusi secara berkala oleh scheduler. Jika sebuah aplikasi mengalami anomali dan menghasilkan log 50 GB dalam waktu dua jam, logrotate yang dijadwalkan jalan tengah malam tidak akan menyelamatkan server kamu dari kondisi disk penuh di siang hari, kecuali kamu mengombinasikannya dengan parameter maxsize atau menjalankan rotasi lebih sering. Selain itu, saat logrotate mengganti nama file aktif (misalnya access.log menjadi access.log.1), proses web server masih memegang file descriptor dari file lama tersebut. Jika web server tidak diberitahu untuk membuka ulang file log barunya, web server akan terus menulis ke file lama yang sudah berganti nama. Itu sebabnya konfigurasi logrotate membutuhkan baris instruksi seperti postrotate untuk mengirim sinyal USR1 atau instruksi reopen ke proses aplikasi.

Contoh konfigurasi praktis yang sering diterapkan

Untuk melihat bagaimana batasan ini diterapkan tanpa saling tumpang tindih, berikut adalah contoh pengaturan batas ukuran pada journald dan pola rotasi pada logrotate untuk log teks aplikasi:

INI

# 1. Batas ukuran journald (/etc/systemd/journald.conf.d/size-limit.conf)
[Journal]
Storage=persistent
SystemMaxUse=500M
SystemKeepFree=1G

# 2. Pola rotasi log teks di logrotate (/etc/logrotate.d/contoh-app)
/var/log/contoh-app/*.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /run/contoh-app.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

Pada blok pertama, journald diperintahkan untuk mengunci total pemakaian disk di angka 500 Megabyte. Jika log bertambah, file journal lama otomatis dibersihkan saat itu juga. Pada blok kedua, logrotate menangani file teks biasa: setiap hari file akan dirotasi, disimpan selama 7 generasi terakhir, dikompresi, dan aplikasi diberikan sinyal untuk beralih ke file kosong yang baru dibuat.

Kesalahan umum saat menentukan batas log

Kesalahan pertama yang paling sering ditemukan di meja bantuan teknis adalah menghapus file log aktif menggunakan perintah rm saat partisi server penuh. Pengguna mengira ruang disk langsung bebas. Padahal, proses yang masih berjalan tetap mengunci file descriptor file tersebut di memori kernel. Di output df, disk tetap seratus persen penuh, sementara di du file sudah hilang. Cara yang lebih aman untuk log teks yang sedang aktif tanpa mematikan service adalah mengosongkan isinya, misalnya dengan truncate -s 0 /path/ke/file.log, lalu memperbaiki konfigurasi retensinya. Kesalahan kedua adalah mengabaikan kehabisan inode. Disk Linux tidak hanya bisa kehabisan ruang gigabyte (block space), tetapi juga bisa kehabisan tabel indeks berkas (inode). Jika kamu menyetel logrotate untuk merotasi file aplikasi microservice berbasis log harian tanpa batas jumlah arsip yang ketat, kamu bisa memiliki ratusan ribu file log kecil yang tidak memakan banyak gigabyte tetapi menghabiskan jatah inode sistem secara keseluruhan. Kesalahan ketiga adalah menyetel logrotate untuk mengurus direktori /var/log/journal/. Tindakan ini bisa merusak integritas file log biner systemd. Biarkan journald mengelola foldernya sendiri lewat parameter SystemMaxUse atau perintah manual seperti journalctl --vacuum-size.

Menentukan mana yang harus diubah

Aturan praktisnya sederhana: periksa dulu siapa yang memproduksi dan memiliki file log tersebut. Jika log tersebut berasal dari unit service systemd standar yang tidak kamu arahkan ke file khusus (pesan kernel, sshd, cron, atau service latar belakang yang kamu jalankan dengan file unit standar), atur batasnya di journald.conf. Namun, jika log tersebut adalah file teks mentah yang jalurnya didefinisikan di konfigurasi software itu sendiri—seperti direktori log Nginx, MariaDB, PHP-FPM, atau Exim—maka batas retensi, kompresi, dan umurnya mutlak harus kamu kelola lewat logrotate.