Mengira Log Rotation WHM Sudah Jalan, Padahal domlogs Apache Terus Membengkak

Banyak admin WHM merasa urusan log sudah beres karena halaman Log Rotation di WHM sudah dibuka, opsinya tercentang, dan tidak ada error. Lalu beberapa minggu kemudian partisi tetap penuh pelan-pelan, padahal jumlah akun tidak bertambah. Ketika dicari, yang membengkak sering kali adalah file di direktori domlogs Apache. Asumsi bahwa "log rotation WHM sudah aktif berarti semua log aman" inilah yang perlu diluruskan.

Log rotation di WHM tidak selalu menyentuh domlogs

domlogs adalah direktori tempat Apache menulis access log per domain. Setiap request ke situs pelanggan menambah satu baris di sana. Di server cPanel, path yang umum dipakai adalah /usr/local/apache/domlogs, dan pada server EasyApache 4 biasanya berupa symlink ke /etc/apache2/logs/domlogs. Halaman cPanel Log Rotation Configuration di WHM umumnya mengatur log milik layanan cPanel sendiri, seperti log di /usr/local/cpanel/logs. Rotasi log sistem lainnya biasanya diurus logrotate lewat konfigurasi di /etc/logrotate.d. domlogs berbeda. Siklus hidupnya biasanya bergantung pada cpanellogd, bukan pada halaman rotasi tadi. Jadi kalau kamu hanya mengecek halaman Log Rotation lalu menyimpulkan domlogs ikut aman, kesimpulannya melompat. Halaman itu bisa tampak sehat sementara domlogs sama sekali tidak tersentuh.

Peran cpanellogd dan kenapa domlogs bisa tertinggal

cpanellogd adalah daemon cPanel yang secara berkala menjalankan apa yang disebut stats run. Dalam stats run, cpanellogd membaca domlogs tiap domain untuk menghitung bandwidth dan membuat statistik untuk aplikasi seperti AWStats atau Webalizer, tergantung yang aktif di server. Setelah sebuah domain selesai diproses, log tersebut bisa diarsipkan ke direktori logs di home user dalam bentuk terkompresi, lalu file di domlogs dikosongkan. Perilaku persisnya mengikuti pengaturan di Tweak Settings. Artinya, domlogs baru "ter-rotate" kalau stats run benar-benar selesai untuk domain itu. Di sinilah asumsi tadi gagal di server produksi:

cpanellogd mati atau tidak berjalan, misalnya setelah update atau restart layanan yang tidak sempurna, sehingga stats run tidak pernah terjadi.
Stats run berjalan tapi tidak selesai tepat waktu. Server yang menampung banyak domain dengan traffic tinggi, atau server yang I/O-nya sudah berat, bisa membuat pemrosesan satu putaran lebih lama dari interval yang diset. Antrean pemrosesan jadi tertinggal terus.
Ada domain dengan log sangat besar, misalnya karena bot atau serangan brute force, yang membuat pemrosesannya lambat dan menahan domain lain di belakangnya.
Domain atau akun sudah dihapus tapi file lognya masih tertinggal di domlogs, tergantung versi dan cara penghapusannya.

Gejalanya di sisi pelanggan sering tidak langsung terlihat sebagai masalah log. Yang muncul biasanya statistik AWStats yang berhenti di tanggal tertentu, angka bandwidth yang tidak bergerak, atau keluhan bahwa situs mulai error saat disk sudah penuh. Bagi support engineer, statistik yang macet adalah petunjuk kuat bahwa stats run tidak sehat, dan biasanya itu jadi hal pertama yang patut dicek.

Cara memeriksa domlogs dan kondisi cpanellogd

Mulai dari ukuran. Perintah di bawah ini read-only dan aman dijalankan.

BASH

# Ruang disk dan inode per partisi
df -h
df -i

# Total ukuran domlogs (gunakan -L agar symlink diikuti)
du -shL /usr/local/apache/domlogs

# 20 file terbesar di domlogs, termasuk subdirektori per user
find -L /usr/local/apache/domlogs -type f -printf '%s %p
' | sort -nr | head -20

Kalau domlogs mengambil porsi besar dari partisi, lihat juga waktu modifikasi dan ukuran file terbesarnya. File yang ukurannya terus naik dari hari ke hari tanpa pernah kembali kecil adalah tanda bahwa domain itu tidak pernah selesai diproses. Berikutnya, pastikan cpanellogd berjalan dan baca log pemrosesannya. cPanel biasanya mencatat aktivitas stats run di /usr/local/cpanel/logs/stats_log.

BASH

# Apakah proses cpanellogd ada
ps aux | grep '[c]panellogd'

# Aktivitas stats run terakhir
tail -n 100 /usr/local/cpanel/logs/stats_log

Yang dicari di stats_log: kapan putaran terakhir dimulai, apakah ada domain yang selalu muncul tapi tidak pernah selesai, dan pesan error atau timeout. Kalau entri terbaru sudah lama sekali, berarti stats run tidak berjalan. Kalau entri ada tapi terus berputar di domain yang sama, berarti ada domain yang menahan antrean. Terakhir, cek pengaturannya di WHM, di Tweak Settings pada tab Stats and Logs. Beberapa opsi yang relevan antara lain interval pemrosesan statistik, apakah log diarsipkan ke home user setelah stats run, dan apakah access log domain dihapus setelah stats run. Nama persis opsinya bisa berbeda antarversi cPanel, jadi baca deskripsi di layar dan sesuaikan dengan versi servermu.

Kenapa disk tetap penuh setelah log dibersihkan

Godaan pertama saat domlogs besar adalah langsung rm file-nya. Hati-hati di sini. Apache masih memegang file log yang aktif. Kalau file dihapus saat masih terbuka, ruang disknya tidak langsung kembali sampai proses yang memegangnya ditutup atau di-restart. Penjelasan lengkapnya ada di artikel Kenapa Disk Tetap Penuh Padahal File Log Sudah Dihapus. Perlu diingat juga bahwa membersihkan domlogs secara manual sebelum stats run memprosesnya berarti data bandwidth dan statistik untuk periode itu ikut hilang. Kalau pelanggan bergantung pada angka tersebut, pertimbangkan dulu. Dalam kondisi darurat saat disk sudah penuh, mengosongkan isi file lebih aman dibanding menghapusnya, tapi lakukan dengan sadar bahwa data di dalamnya tidak bisa dikembalikan. Setelah ruang kembali, perbaiki penyebabnya, bukan hanya gejalanya. Kalau cpanellogd mati, jalankan lagi lalu pantau stats_log sampai satu putaran penuh selesai. Kalau stats run terlalu lambat, cari domain yang lognya tidak wajar besar. Sering kali penyebabnya adalah traffic bot yang lebih tepat ditangani di level firewall atau aplikasi daripada sekadar dibiarkan masuk ke log.

Menjadikannya cek rutin, bukan reaksi saat disk penuh

Pola yang lebih sehat di produksi adalah memperlakukan domlogs seperti komponen yang bisa macet, bukan sesuatu yang "sudah diurus sistem". Beberapa kebiasaan yang membantu:

Catat ukuran domlogs secara berkala, misalnya mingguan, supaya kamu tahu angka normal servermu dan bisa melihat lonjakan lebih awal.
Sesekali buka stats_log dan pastikan putaran terakhir selesai dalam rentang waktu yang wajar dibanding intervalnya.
Jadikan statistik AWStats atau angka bandwidth yang berhenti bergerak sebagai pemicu untuk mengecek cpanellogd, bukan sekadar keluhan tampilan.
Pasang alert ukuran partisi dan inode di sistem monitoring yang sudah kamu pakai, dengan ambang yang memberi cukup waktu untuk bertindak.

Cek yang sama sebaiknya diterapkan ke sumber pertumbuhan disk lain yang juga bekerja diam-diam. Binary log MySQL adalah contoh yang mirip, dan sudah dibahas di Rutin Cek Binary Log MySQL yang Menumpuk Sebelum Disk Server Penuh. Intinya, opsi log rotation yang tercentang di WHM bukan jaminan domlogs ikut dibersihkan. domlogs bergantung pada stats run cpanellogd yang benar-benar selesai. Jadi yang perlu dicek rutin adalah tiga hal: ukuran domlogs, isi stats_log, dan pengaturan Stats and Logs di Tweak Settings. Lakukan sebelum partisi mendekati penuh, bukan sesudahnya.