monitoring

PROBLEM jam lima pagi untuk fleet yang sehat dan sengaja lebih baru dari Docker Hub. Perbandingan versi ternyata buta arah.

TL;DR: Script monitor gue ngamuk jam 5 pagi gara-gara versi fleet beda sama Docker Hub. Ternyata semua host sehat dan sengaja di-upgrade ke versi custom, yang nggak kejar malah Docker Hub-nya. Akhirnya gue perbaiki logika perbandingannya: versi dihitung numerik kayak SemVer dan fleet lebih baru dari Hub dianggap rollout yang disetujui, bukan masalah.

Prometheus TargetDown di server ke-10 fleet: node_exporter nggak ada, Ansible gagal deploy karena SSH MaxAuthTries terbakar oleh urutan kunci ed25519. Fix = hardening SSH dulu (key-only, urutan kunci), baru monitoring — semua idempoten.

TL;DR: Monitor nyala merah alert TargetDown server kesepuluh, kira cuma kurang scrape config tapi SSH gagal total karena node_exporter nggak ada dan Ansible kena batas MaxAuthTries dari terlalu banyak kunci ed25519. Akhirnya benerin urutan playbook: hardening SSH dulu (hanya kunci, urutin biar nggak kebakar limit), baru deploy node_exporter. Sekarang idempoten, server baru jalanin playbook sama aja.

Server ke-10 fleet bongkar ilusi otomatisasi: SSH MaxAuthTries terbakar, cloud-init timpa hardening, node_exporter nggak ter-deploy. Pelajaran: fleet discipline berarti pipeline idempoten, bukan manual one-off.

TL;DR: Tambah server ke-10 gagal karena SSH MaxAuthTries 6 habis dipakai kunci salah urutannya, plus cloud-init override PasswordAuthentication lewat file drop-in yang menang leksikal. Server baru juga nggak pasang node_exporter jadi monitoring buta. Pelajarannya: playbook harus idempoten kelola config cloud-init eksplisit, jangan asumsikan rollout lama pasti jalan.

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.

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.

Buang stack GoAccess DIY, pindah ke admin bawaan 3proxy mode counters-only, lalu sadar pertanyaan berubah: GoAccess dipanggil balik di belakang nginx.

TL;DR: Penulis sempat hapus GoAccess dan ganti pakai admin service bawaan 3proxy, cuma tiga baris config. Ternyata counter bawaan cuma jawab "berapa traffic", nggak bisa nunjukin URL mana yang paling boros bandwidth. Jadi GoAccess balik lagi buat breakdown per-URL, sekarang dua-duanya dipakai sesuai kebutuhan masing-masing.