Log Rotation: cara kerja, strategi rotasi, dan konfigurasi untuk proyek mobile

Apa itu Log Rotation

Log Rotation adalah proses pergantian periodik file log aktif ke file baru dengan pengarsipan, kompresi, atau penghapusan file lama secara bersamaan. Tanpa rotasi, satu file log akan tumbuh tanpa batas hingga memenuhi seluruh partisi disk, yang menyebabkan kegagalan aplikasi dan kehilangan data.

Skenario tipikal: aplikasi menulis log ke file app.log. Ketika app.log mencapai 100 MB, sistem mengganti namanya menjadi app.log.1, mengompresinya menjadi app.log.1.gz, dan membuat app.log baru yang kosong. Pada pengisian berikutnya, app.log.1 menjadi app.log.2, app.log.1.gz menjadi app.log.2.gz, dan app.log.2.gz lama dihapus. Mekanisme ini disebut rotasi dengan keep count — jumlah salinan arsip tetap.

Menurut Splunk (2023), konfigurasi rotasi yang salah adalah penyebab 40% insiden terkait kepenuhan disk di server aplikasi. Untuk perangkat mobile, rotasi bahkan lebih kritis karena pengguna tidak dapat dan tidak boleh mengelola log secara manual.

Strategi rotasi log

Log Rotation mendukung tiga strategi dasar yang dapat dikombinasikan. Pemilihan strategi tergantung pada jenis aplikasi: sistem server lebih sering menggunakan rotasi berdasarkan waktu, aplikasi mobile — berdasarkan ukuran, sistem tertanam — berdasarkan jumlah file.

Rotasi berdasarkan ukuran — yang paling umum

Rotasi berdasarkan ukuran menjamin bahwa tidak ada file log yang melebihi batas yang ditentukan. Batas dipilih berdasarkan ruang disk yang tersedia dan frekuensi logging. Untuk server, batas tipikal adalah 100–500 MB per file, untuk perangkat mobile — 1–10 MB. Jika aplikasi melakukan logging secara agresif, batas harus diturunkan, jika tidak rotasi akan terjadi setiap beberapa menit.

Rotasi berdasarkan waktu — untuk kepatuhan

Rotasi berdasarkan waktu tidak tergantung pada volume log — file berubah secara ketat sesuai jadwal. Nyaman untuk sistem di mana log harus disimpan dalam jumlah hari tetap: rotasi harian dengan keep count = 30 berarti penyimpanan 30 hari. Kekurangannya — satu file dapat tumbuh hingga satu gigabyte per hari di bawah beban intensif.

logrotate di Linux: konfigurasi dan contoh

logrotate adalah utilitas Linux standar untuk rotasi log otomatis. Ini dijalankan melalui cron dan memproses file konfigurasi dari /etc/logrotate.d/. Setiap layanan (nginx, postgresql, aplikasi) membuat konfigurasinya sendiri dengan jalur ke log, strategi rotasi, dan tindakan pasca-rotasi.

# /etc/logrotate.d/myapp — rotasi log aplikasi
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    postrotate
        kill -HUP $(cat /var/run/myapp.pid)
    endscript
}

Konfigurasi ini merotasi log setiap hari, menyimpan 7 salinan arsip, mengompresi file lama dengan gzip (kecuali yang terakhir — delaycompress), tidak memberikan error jika log tidak ada (missingok), tidak merotasi file kosong (notifempty), dan membuat ulang file dengan hak akses 0640. Setelah rotasi, mengirim sinyal HUP ke proses aplikasi melalui skrip postrotate.

Parameter logrotate

size — rotasi saat mencapai ukuran (size 100M). rotate — jumlah salinan arsip (rotate 7). compress — kompresi gzip. dateext — penambahan tanggal ke nama file sebagai pengganti nomor urut. sharedscripts — eksekusi postrotate satu kali untuk semua file, bukan untuk masing-masing secara terpisah. maxage — penghapusan arsip yang lebih lama dari N hari.

Log Rotation di aplikasi mobile

Di perangkat mobile, Log Rotation sangat penting karena pengguna tidak mengelola sistem file dan tidak mengharapkan aplikasi memakan gigabyte untuk log. iOS dan Android memiliki mekanisme bawaan: os_log di iOS menggunakan buffer melingkar berukuran tetap (rotasi dengan penimpaan), Android Logcat memiliki buffer terbatas di kernel.

Untuk file log kustom di iOS digunakan CocoaLumberjack dengan kelas DDFileLogger, yang mendukung rotasi berdasarkan ukuran dan waktu. Di Android — Logback atau implementasi sendiri melalui RollingFileAppender. Kedua alat memungkinkan pengaturan ukuran file maksimum dan jumlah arsip.

// CocoaLumberjack — rotasi file di iOS
import CocoaLumberjack

let fileLogger = DDFileLogger()
fileLogger.maximumFileSize = 1024 * 1024 // 1 MB
fileLogger.logFileManager.maximumNumberOfLogFiles = 5
DDLog.add(fileLogger)

iOS: os_log tidak memerlukan rotasi — pesan ditimpa di buffer melingkar. Tetapi jika aplikasi menulis file log kustom (misalnya, untuk debugging atau pengiriman ke server), rotasi harus dikonfigurasi secara manual. CocoaLumberjack adalah pilihan standar untuk tim iOS, secara otomatis mengompresi arsip ke .gz dan menghapus file lama saat melampaui batas.

Mengapa rotasi penting di Android

Android tidak membatasi aplikasi dalam menulis log ke direktori sendiri. Jika pengembang menulis log debug ke file tanpa rotasi, dalam sebulan penggunaan aktif dapat memakan 500 MB — 1 GB. Pengguna akan menemukan masalah ketika sistem menampilkan peringatan ruang tidak mencukupi dan akan menghapus aplikasi. Logback dengan RollingFileAppender memecahkan masalah ini: batas 5 MB dengan 3 arsip menjamin bahwa log tidak akan pernah memakan lebih dari 20 MB.

Contoh implementasi rotasi di iOS dan Android

Di bawah ini adalah contoh konfigurasi rotasi log di kedua platform. Di iOS digunakan CocoaLumberjack, di Android — Logback dengan konfigurasi melalui XML.

// Logback di Android — konfigurasi rotasi di logback.xml
// Ukuran file 5MB, 3 salinan arsip
@file:Suppress("unused")

// Di logback.xml:
// <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
//   <file>${DATA_DIR}/logs/app.log</file>
//   <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
//     <fileNamePattern>app.%i.log.gz</fileNamePattern>
//     <minIndex>1</minIndex>
//     <maxIndex>3</maxIndex>
//   </rollingPolicy>
//   <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
//     <maxFileSize>5MB</maxFileSize>
//   </triggeringPolicy>
// </appender>

CocoaLumberjack di iOS mendukung tidak hanya rotasi berdasarkan ukuran, tetapi juga penghapusan log lama berdasarkan tanggal dengan logFileManager.maximumLogFiles. Jika Anda mengatur maximumLogFiles = 0, batasan dihapus — log akan menumpuk tanpa batas, yang berbahaya untuk production.

// Rotasi kustom dengan pemeriksaan volume total
class SizeAwareLogger {
    let maxTotalSize: Int64 = 20 * 1024 * 1024

    func enforceQuota(at logDirectory: URL) {
        let files = (try? FileManager.default
            .contentsOfDirectory(
                at: logDirectory,
                includingPropertiesForKeys: [.fileSize]
            )) ?? []
        let total = files.reduce(0) {
            $0 + (try? $1.resourceValues(forKeys: [.fileSize])
                .fileSize).map(Int64.init) ?? 0
        }
        if total > maxTotalSize {
            // Kami menghapus file tertua
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Monitoring dan alert saat rotasi

Log Rotation tidak hanya pengarsipan otomatis, tetapi juga indikator kesehatan sistem. Jika log terlalu sering berotasi (setiap beberapa menit), ini adalah sinyal logging berlebihan atau kesalahan dalam logging siklikal (error log loop). Konfigurasikan alert pada frekuensi rotasi: lebih dari 10 rotasi per jam — alasan untuk diperiksa.

Sistem monitoring (Prometheus, Grafana, Datadog) dapat melacak metrik rotasi melalui eksportir sistem file. Prometheus node_exporter menyediakan metrik ukuran file dan waktu modifikasinya. Di perangkat mobile, monitoring rotasi biasanya terintegrasi dalam SDK: CocoaLumberjack mencatat peristiwa rotasi melalui DDLog, dan Logback mengirim status melalui appender.

Alert: jika arsip lebih banyak dari yang diharapkan (rotate count melampaui batas) atau volume total log melampaui kuota — sistem harus memberi tahu administrator. Untuk server, ambang standar adalah 80% dari ukuran partisi, untuk perangkat mobile — alert saat melampaui 50 MB per aplikasi.