devops

Playbook mingguan bilang OK tapi /var/log bengkak 654M: arsip btmp rotasi, file aktif yang di-truncate, dan pipe df yang nggak pernah jalan.

TL;DR: Disk /var/log bengkak diam-diam padahal playbook mingguan selalu lapor aman. Biang keroknya btmp, log login gagal yang numpuk gara-gara brute force SSH, fix-nya hapus arsip dan truncate file aktif biar sshd nggak perlu restart. Bonus: task bukti pakai modul command ternyata nggak memproses pipa, jadi harus diganti shell.

Dua angka untuk satu server yang sama: skor risiko dan skor kesehatan arahnya kebalikan, dan sidebar saya masih baca arah lama.

TL;DR: Dashboard gue bingung karena ring detail nunjukin 92 hijau, sidebar server yang sama bilang 30 merah. Ternyata sidebar masih baca skor risiko lama, sisanya udah pindah ke field health yang arahnya kebalikan. Fix-nya cuma dua baris, pelajarannya: migrasi arah metrik harus sekali di batas API.

Playbook hardening bilang changed, tapi sshd -T masih passwordauthentication yes: first-match-wins dan urutan Include membuat 50-cloud-init.conf menang.

TL;DR: Hardening SSH-nya gagal karena sshd pakai aturan first-match-wins: nilai pertama yang dibaca yang menang, bukan yang terakhir. File 50-cloud-init.conf isinya PasswordAuthentication yes dan urutan alfabetnya lebih dulu daripada drop-in-ku, jadi menang terus. Solusinya ganti nama jadi 00-hardening.conf, komen baris di config utama, dan selalu verifikasi pakai sshd -T.

Playbook Ansible mati karena apostrof di dalam block scalar, lalu host unreachable karena urutan penawaran key SSH. Dua pelajaran dari satu exit code 4.

TL;DR: Cron collector-nya mati gara-gara dua bug sekaligus: komentar dalam block scalar YAML ternyata bukan komentar beneran, dan apostrof di kata "today's" bikin Ansible gagal split argumen. Abis itu SSH kena "Too many authentication failures" karena key ed25519 ditolak duluan, jadi dia nambahin IdentitiesOnly=yes di ansible.cfg. Sekarang tiap exit code 4, dia cek dua itu duluan sebelum nyalahin jaringan.

Alert CPU jam 2 pagi yang ternyata cuma spike backup. Pelajaran debounce 3 sampel, hysteresis 0.75, dan dedupe insiden buat alert Discord.

TL;DR: Author bangun jam 2 pagi gara-gara alert CPU staging padahal cuma spike backup sesaat. Alertnya jadi dianggap spam sampai di-mute, dan alert yang di-mute lebih bahaya daripada nggak ada sama sekali. Solusinya: debounce 3 sampel, hysteresis recover di 0.75x, dedupe per insiden, plus pastikan alertnya beneran actionable.

Nilai terakhir di dashboard bisa basi tanpa terlihat. Cara saya nambahin staleness badge fresh/aging/dead dan aggregate avg/min/max yang ngikutin tab range.

TL;DR: Dashboard nunjukin CPU 3% padahal server udah mati tujuh jam, soalnya cuma render data terakhir tanpa umur datanya. Solusinya kasih badge fresh/aging/dead berdasarkan usia data dibanding poll interval, jadi kelihatan langsung datanya masih bisa dipercaya atau nggak. Pelajaran lain: parsing timestamp zona lokal kayak WIB rentan meledak, mending simpan dan bandingin dalam UTC.

Dashboard monitoring server jadi noise saat item perhatian puluhan tanpa organisasi. Tiga fix kecil mengubah grid datar jadi workflow yang bisa dipakai.

TL;DR: Dashboard monitoring punya terlalu banyak item perhatian di satu grid datar, jadi yang kritis susah ketemu. Penulis bikin tiga fitur: search dengan debounce di API, tombol filter severity, dan grouping item per server yang bisa di-collapse berdasarkan severity terburuk. Ketiganya bikin workflow jadi cepat, langsung keliatan masalah kritis tanpa scroll panjang.

Pola delta dua sampel untuk menghitung kecepatan disk dan jaringan dari counter kumulatif node_exporter tanpa Prometheus.

TL;DR: Angka mentah dari node_exporter itu counter kumulatif, bukan kecepatan baca/tulis disk. Hitung pakai delta dua sampel dengan interval 2 detik supaya dapet angka KB/s yang bener. Server yang belum terpasang node_exporter cukup dilewati tanpa ganggu monitoring.

Rumus konversi Mbps yang diingat salah bikin cap 3proxy cuma 5 Mbps, error 8 kali lipat. Manual bilang bits, speed test yang buktikan.

TL;DR: Bandwidth cap di 3proxy cuma dapet 5 Mbps padahal config nulis 40. Ternyata bandlim pakai satuan bits per detik, bukan bytes, jadi nilai 5.000.000 harusnya 40.000.000. Pelajarannya: baca manual dulu daripada percaya rumus hafalan, sambil dirapiin juga dashboard GoAccess biar tabel URL langsung kelihatan.