Merotasi log pengawas VPN tanpa merusak penulisnya

Pemeriksaan kesehatan VPN yang menambahkan satu baris per menit diam-diam menciptakan tugas kedua: memutuskan bagaimana baris-baris itu meninggalkan disk. Memperbaiki terowongan tidak melakukan apa pun untuk tugas itu, dan mengganti nama berkas tidak mengalihkan proses yang masih memegang deskriptor lama. Jawab dulu pertanyaan tujuan, lalu sesuaikan rotasi dengan cara penulis membukanya.

Pilih tujuan sebelum kebijakan rotasi

Unit systemd yang sudah mengirim keluarannya ke jurnal menjaga retensi di satu tempat. journald menegakkan batas seperti SystemMaxUse dan MaxRetentionSec , jadi pengawas yang mencatat di sana mewarisi batas tanpa kerja tambahan. Menambahkan berkas kedua tanpa batas di sampingnya menggandakan pemeliharaan tanpa manfaat.

Berkas khusus mendapat tempatnya ketika hal lain membacanya: parser, ekspor audit, atau halaman yang mengharapkan jalur stabil. Setelah keputusan itu dibuat, berkas membutuhkan pemilik, mode, dan kebijakan rotasi yang ditulis bersama, karena ketiganya hanya benar sebagai satu kesatuan. Jalur yang bisa dibuat siapa pun juga jalur yang bisa diganti siapa pun, jadi izin direktori termasuk dalam catatan yang sama. Tulis semuanya di samping pemeriksaan dan suntingan berikutnya dimulai dari fakta yang sama.

Tulis blok agar sesuai dengan penulis

Mulailah dari penulis yang membuka jalur pada setiap pemanggilan, menambahkan satu baris, lalu keluar. Pola itu bertahan dari rotasi tanpa kerja sama apa pun dari proses, karena jalankan berikutnya membuka berkas yang saat itu ada di jalur tersebut. Blok di bawah menyimpan seminggu versi dan membuat ulang berkas dengan pemilik dan mode yang dibutuhkan penulis:

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

Panduan logrotate mendefinisikan hitungan sebagai jumlah versi yang dirotasi dan disimpan, bukan sebagai jaminan tujuh hari riwayat, dan kata kunci daily dievaluasi saat tugas berjalan bukan bertindak sebagai penjadwalnya sendiri. Pada sebagian besar distribusi, timer systemd atau entri cron sudah memiliki pemanggilan itu, jadi periksa mana yang ada sebelum menambahkan yang kedua. Mencocokkan kepemilikan lebih penting daripada jumlah retensi. Menyalin mode khusus root ke berkas yang ditulis akun layanan menghentikan pencatatan pada rotasi berikutnya, dan kegagalan muncul berjam-jam kemudian sebagai stempel waktu usang bukan sebagai galat. Pastikan pengguna penulis sebelum menyalin blok dari tempat lain.

Penulis yang tidak pernah membuka ulang butuh perbaikan lain

Proses berjalan lama yang memegang deskriptor terbuka terus menulis ke inode yang telah diganti nama. Ruang tidak dibebaskan dan berkas yang terlihat berhenti tumbuh, yang tampak seperti rotasi rusak sampai Anda memeriksa inode. Entah ajari proses membuka ulang, atau buat rotasi menyalin dan memotong alih-alih mengganti nama.

Jalur buka ulang lebih bersih di mana perangkat lunak mendukungnya: kirim sinyal yang didokumentasikan atau jalankan perintah yang didokumentasikan, dan biarkan proses membuka berkas baru sendiri. Alternatifnya adalah copytruncate , yang menyalin isi ke nama yang dirotasi lalu memotong aslinya di tempat, sehingga deskriptor tetap valid tetapi tulisan yang jatuh antara salinan dan pemotongan hilang.

Untuk unit yang dijalankan systemd, arahkan StandardOutput ke jurnal atau ke berkas dan biarkan unit memiliki siklus hidupnya. Perulangan shell yang menambahkan melalui tee -a tanpa batas ukuran adalah susunan yang memenuhi partisi selama gangguan, karena pemeriksaan yang gagal sering mencatat jauh lebih banyak daripada yang sehat.

Uji rotasi tanpa menunggu timer

Mode debug melaporkan apa yang akan terjadi dan tidak menyentuh apa pun, yang menjadikannya jalankan pertama yang aman setelah suntingan. Paksa rotasi nyata setelah Anda puas, lalu pastikan baris log berikutnya mendarat di berkas baru bukan di berkas yang diganti nama:

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

Baca keluaran dalam urutan itu. Jalankan debug harus menyebut berkas dan tindakan yang dimaksudkannya; jalankan paksa harus menghasilkan nama yang dirotasi sesuai harapan; tail harus menunjukkan entri baru setelah penulis berjalan lagi. Nilai df yang tumbuh dengan berkas terlihat yang menyusut berarti masalah deskriptor yang dijelaskan di atas.

Ulangi jalankan paksa dua kali untuk melihat bagaimana retensi berperilaku ketika versi sudah ada. Menghapus berkas tertua adalah hasil yang diharapkan, dan penghapusan yang tidak ada biasanya berarti hitungan atau karakter pengganti pada nama yang dirotasi tidak cocok dengan yang dibuat logrotate.

Simpan rollback dan catatan tertulis

Simpan blok sebelumnya sebelum menyunting, dan catat penjadwal mana yang menjalankannya, karena pemulihan yang mengembalikan berkas tetapi tidak timer mereproduksi separuh masalah awal. Rotasi sekali dengan tangan setelah pemulihan, lalu pastikan akun penulis dapat menulis ke jalur log. Jika layanan berjalan di bawah systemd, muat ulang unit setelah setiap perubahan pada pengalihan keluarannya, karena proses yang berjalan terus menulis ke target lama. Baca sendiri beberapa baris log berikutnya alih-alih percaya bahwa unit kembali dengan bersih.

Catat mode, pemilik, jumlah retensi, dan anggaran disk yang diharapkan di samping pemeriksaan itu sendiri. Ketika nanti pemeriksaan berubah dari skrip sekali jalan menjadi daemon, kebijakan rotasi harus berubah bersamanya, dan catatan itulah yang memberi tahu orang berikutnya asumsi mana yang rusak.

Terakhir, pisahkan keputusan log dari keputusan pemulihan. Pemeriksaan yang gagal harus mengikuti kebijakan pemulihan koneksi itu sendiri, bukan aturan yang tersembunyi di dalam logrotate, dan tidak ada susunan pencatatan yang boleh menjadi alasan terowongan yang berfungsi dimulai ulang.