Skor di Sidebar Bilang 30, Ring Bilang 92

Adityo Guni Waluyo17 September 202602.17

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

#monitoring #frontend #observability

Ringkasan

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.

Pagi itu saya buka dashboard monitoring, langsung berhenti di satu hal. Ring detail di halaman server produksi nunjukin angka 92, hijau. Terus mata saya geser ke sidebar di kiri. Server yang sama, jam yang sama, angkanya 30, merah.

Insting pertama saya salah. Saya curiga kalkulasi health di backend baru aja berubah. Saya bolak-balik cek formula-nya, bandingin sama commit sebelumnya, nggak ada yang geser. Ternyata bukan di situ. Angkanya emang datang dari sumber yang beda. Sidebar masih ngambil fleet_score dan s.score, keluarga skor risiko yang 100 berarti kritis. Sisanya, termasuk ring di halaman detail, udah pindah ke field turunan fleet_health_score dan health_score yang 100 berarti sehat. Dua arah yang bertolak belakang, satu slot angka.

Fix-nya nyentuh dua file, frontend/src/main.js dan frontend/src/views/sidebar.js, totalnya dua baris. Fungsi setNavData sekarang binding ke fleet_health_score, dan baris meta di navLink binding ke health_score dengan fallback ke score lama buat payload yang belum punya nilai health. Perubahan binding doang, tapi efeknya ke rasa bac dashboard itu gede. Angka yang kontradiktif di satu layar bikin saya berhenti percaya ke dua-duanya, sampai saya buktikan mana yang bener.

Satu detail kecil yang bikin saya makin yakin ini bug binding, bukan bug kalkulasi: angkanya konsisten. Sidebar nggak random, dia persis cermin dari ring. 30 dan 92 itu pasangan yang masuk akal buat server yang sehat kalau satu-nya baca arah risiko dan satu-nya baca arah health. Kadang bug justru kelihatan "masuk akal" karena datang dari data yang sama, cuma dibaca beda.

Ekosistem Nggak Pernah Sepakat Soal Arah

Yang bikin bug kayak gini susah dicerna: dua-duanya angka 0 sampai 100, kelihatan kompatibel, padahal semantiknya kebalikan. Dan ini bukan keanehan dashboard saya aja. Ekosistem tooling yang saya pakai sehari-hari aja nggak pernah sepakat soal arah skor.

Lighthouse ngukur performa halaman pakai skor 0 sampai 100, dan di sana rentang 90 sampai 100 masuk kategori Good dengan warna hijau [1]. Semakin tinggi semakin bagus, dan dokumennya sendiri bilang skor 100 yang sempurna itu nggak realistis dicapai. CVSS v4.0 jalan ke arah sebaliknya: skala kualitatif resminya nunjukin Critical di 9,0 sampai 10,0 dan High di 7,0 sampai 8,9 [2]. Di dunia vulnerability, angka gede justru kabar buruk. Docker HEALTHCHECK malah biner: exit code 0 artinya container healthy dan siap dipakai, exit 1 artinya unhealthy [3].

Tiga konvensi, tiga arah. Jadi pas saya sendiri mutusin di dashboard bahwa health = 100 dikurangi risiko, wajar ada satu titik yang kelewat: binding sidebar dibuat sebelum migrasi, dan migrasi yang udah menyentuh ring detail ternyata belum menyentuh nav. Yang salah bukan metriknya, juga bukan orang yang lupa ganti satu baris. Yang salah adalah membiarkan dua keluarga skor berbagi satu slot angka di UI tanpa ada satu pun lapisan yang nyatuhi arah.

Invert Sekali di Batas API

Keputusan yang saya ambil dari insiden ini: inversi arah metrik cukup terjadi sekali, di batas API, bukan di tiap komponen frontend. Backend ngitung field turunannya sekali, semua lapisan UI di bawahnya tinggal baca satu arah yang sama. Bonusnya gampang diverifikasi: semua angka di layar harusnya gerak searah pas kondisi server berubah. Kalau ada satu komponen yang masih baca field mentah, dia langsung kelihatan sebagai pengecualian, bukan nyamar jadi versi lain dari kebenaran.

Fallback binding-nya juga saya pertahankan secara sadar. Row yang belum kekoleksi nilai health tetap nampilin angka, walau artinya sementara masih pakai arah risiko. Menurut saya itu lebih jujur daripada nampilin kosong, dan durasinya pendek karena collector udah pindah ke field baru.

Yang saya bawa pulang dari pagi itu: pas kamu merename atau menurunkan metrik jadi field baru dengan arah kebalikan, perlakukan itu sebagai migrasi kontrak data, bukan rename biasa. Angka yang kelihatan serupa tapi semantiknya kebalikan itu lebih licik daripada angka yang jelas beda format, karena nggak ada yang curiga dari penampilannya.