Rollout Node Exporter KTM Fleet dan Jebakan MaxAuthTries
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.
Ringkasan
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.
Alert TargetDown dan Dugaan yang Meleset
Layar monitor saya tiba-tiba menyala merah. Prometheus UI menampilkan alert TargetDown untuk IP 157.245.192.183 pada port 9100. Saya langsung nebak ini masalah sepele. Mungkin tinggal tambahkan target scrape di konfigurasi, toh node_exporter pasti udah jalan di server kesepuluh itu. Tebakan saya meleset total — saat mencoba SSH, koneksi langsung putus. Ternyata biner node_exporter-nya nggak ada sama sekali. Lebih parah lagi, eksekusi Ansible buat mendeploynya malah gagal total. Batas autentikasi SSH habis terbakar bahkan sebelum proses dimulai.
Akar Masalah di Balik Kegagalan Ansible
Mari saya bedah kenapa Ansible bisa gagal begitu aja. OpenSSH punya mekanisme pertahanan bawaan bernama MaxAuthTries. Parameter ini membatasi jumlah percobaan autentikasi yang diizinkan (sshd_config(5)). Nilai defaultnya emang biasanya 6 percobaan per koneksi. Masalahnya, setiap kunci SSH yang ditolak atau salah urutan bakal dihitung sebagai satu kegagalan. Pas Ansible coba menghubungkan beberapa kunci ed25519 secara beruntun, batas ini langsung terlampaui. Koneksi langsung diputus paksa. Akibatnya, seluruh rangkaian tugas penting buat mengunduh dan menjalankan node_exporter sebagai single static binary yang andal di seluruh lingkungan server, nggak pernah benar-benar tereksekusi sampai tuntas oleh sistem.
Sempat saja saya kira ini masalah jaringan atau firewall. Ternyata ini murni masalah disiplin urutan konfigurasi. Keamanan akses harus diselesaikan dulu. Baru kemudian monitoring dipasang.
Solusi Idempoten dan Pelajaran untuk Fleet
Perbaikan yang saya lakukan cukup radikal tapi manjur. Urutan eksekusi di playbook saya ubah total. Langkah pertamanya sekarang adalah hardening SSH. Autentikasi saya pastikan cuma pakai kunci. Urutan penyajian kunci juga saya rapikan biar nggak membakar jatah batas percobaan. Setelah akses stabil, baru saya jalankan role Ansible buat node_exporter. Pendekatan ini bikin proses rollout jadi idempoten. Server kesebelas nanti nggak bakal butuh skrip kustom. Playbook yang sama saja cukup saya jalankan.
Alert TargetDown seperti yang dijelaskan di wiki resmi itu sebenernya adalah peringatan dini yang sangat berharga bagi siapa saja yang mengelola infrastruktur server secara serius. Jangan pernah abaikan urutan fondasi infrastruktur. Monitoring itu penting, tapi akses yang terkunci rapi adalah prasyarat mutlak yang nggak bisa ditawar.