Beberapa hari lalu ada laporan simpel dari tim operasional. Status agent di salah satu server tidak muncul di dashboard internal yang saya kelola. Kedengarannya seperti masalah kecil, mungkin cuma elemen yang ketutup atau lupa refresh. Saya pikir ini bakal selesai dalam lima menit.

Ternyata saya salah besar. Satu laporan kecil itu bongkar tiga bug berbeda yang numpuk, masing masing nyembunyiin yang lain. Tulisan ini saya buat buat dokumentasi pribadi, sekaligus semoga bisa jadi pengingat buat kalian, kadang masalah yang kelihatan sepele itu cuma gejala paling atas dari sesuatu yang lebih dalam.

Gejala Pertama, Tab Agent Kosong

Screenshot yang saya terima nunjukin satu baris server di VPS List, lengkap dengan info plan, IP, sama metrics Zimbra yang bilang No data yet. Tapi bagian status command agent yang biasanya nampilin versi dan status online, sama sekali tidak ada.

Cek pertama saya ke database. Dan ternyata agent nya ada, sehat, baru aja lapor beberapa jam sebelumnya. Jadi bukan agent nya mati, cuma UI nya yang tidak nampilin apa apa. Aneh.

Bug Pertama, Tampilan yang Numpang di Kondisi yang Salah

Setelah ngulik kode frontend nya, ketemu penyebabnya. Komponen status agent itu ditaro di dalam blok kondisional yang cuma render kalau data Zimbra Metrics ada isinya.

{metrics ? (
  <div>...tile Users, Disk, Last Updated, Agent...</div>
) : (
  <p>No data yet</p>
)}

Padahal command agent sama Zimbra Metrics itu dua sumber data yang sama sekali beda. Satu dari heartbeat agent, satu lagi dari collector metrics terpisah. Server yang saya cek ini agent nya hidup normal, cuma metrics nya belum pernah masuk sama sekali, jadi seluruh blok termasuk status agent ikut ketutup.

Fix nya gampang, pindahin komponen status agent keluar dari kondisional itu, jadi dia render sendiri terlepas dari ada tidaknya data metrics. Saya tes lokal pakai skenario yang sama persis, agent ada tapi metrics kosong, dan tile nya langsung muncul normal. Deploy, kelar, atau begitu pikir saya.

Bug Kedua, Metrics yang Memang Tidak Pernah Dikirim

Begitu bug tampilan kelar, muncul pertanyaan lanjutan yang lebih penting. Kalau agent nya sehat, kenapa Zimbra Metrics nya dari awal memang tidak pernah ada datanya sama sekali, bukan cuma telat.

Saya cek tabel metrics di database, dan hasilnya jelas. Dari beberapa server yang satu grup, cuma satu yang pernah ngirim metrics, server lainnya nol selamanya. Nelusurin ke kode agent, ketemu dua syarat yang harus kepenuhi bareng sebelum fitur report metrics jalan, satu ID server, satu lagi token autentikasi yang sifatnya shared, bukan per server.

Dua syarat ini aslinya dulu dipasang manual lewat script lama yang terpisah, satu per satu ke tiap server. Server yang pernah kepasang script lama itu, metrics nya jalan. Yang tidak pernah kepasang, diam selamanya, tanpa ada log error yang jelas, cuma berhenti diam diam di baris pengecekan paling awal.

Daripada nyuruh orang pasang manual lagi satu satu, saya putuskan masukin dua nilai itu ke proses instalasi otomatis yang sudah ada, jadi server baru otomatis lengkap begitu diinstall lewat satu baris perintah, tanpa perlu langkah tambahan terpisah.

Bug Ketiga, HAProxy yang Kirim Data Lewat Jalur yang Salah

Perbaikan kedua ini saya coba langsung di salah satu server yang bermasalah. Jalanin perintah instalasi yang sudah diperbarui, dan hasilnya malah error baru.

curl: (22) The requested URL returned error: 400

Giliran dicoba pakai mode verbose, kelihatan body responsenya.

400 The plain HTTP request was sent to HTTPS port

Yang bikin bingung, endpoint lain di domain dan port yang sama justru jalan normal. Berarti bukan masalah jaringan putus total, tapi sesuatu yang lebih halus.

Saya coba curl langsung dari server utama ke domain publiknya, hasilnya sukses. Tapi dari server yang lapor error, gagal terus. Kedua request itu kelihatannya nuju ke alamat yang sama, tapi hasilnya beda. Dari situ saya curiga ada perbedaan jalur DNS.

Benar saja. DNS publik sama DNS internal resolve domain itu ke dua tempat yang beda sama sekali. Dari dalam jaringan sendiri, domain itu langsung ngarah ke server backend nya. Dari luar, domain itu ngelewatin HAProxy dulu di server terpisah, baru diterusin ke backend. Jadi test saya yang dari server utama tadi sebenarnya ngelewatin HAProxy sama sekali tanpa saya sadari, makanya kelihatan sukses padahal belum nguji jalur yang sebenarnya dipakai client dari luar.

Begitu saya minta config HAProxy nya buat dicek, ketemu akar masalahnya di satu baris.

listen port-3001-agent-ems
    bind 0.0.0.0:3001 ssl crt /etc/webmin/miniserv.pem alpn h2,http/1.1
    mode http
    ...
    server api-kizuna 192.168.0.1:3001 check

HAProxy nya buka koneksi HTTPS dari client, bongkar enkripsinya, terus nerusin ke backend pakai HTTP biasa, tanpa dienkripsi ulang. Masalahnya, backend yang dituju itu nunggu HTTPS juga di port yang sama. Jadi yang terjadi, HAProxy udah bongkar enkripsi di depan, terus kirim data polos ke pintu yang justru nunggu data terenkripsi. Dari sisi backend, itu kelihatan kayak ada yang nyasar ngirim HTTP ke port yang khusus HTTPS, makanya errornya persis bilang begitu.

Fix nya cuma nambah dua kata di baris paling belakang.

server api-kizuna 192.168.0.1:3001 check ssl verify none

ssl bikin HAProxy enkripsi ulang sebelum nerusin ke backend, verify none perlu karena sertifikat yang dipakai backend itu buat domain yang beda, bukan buat alamat IP internal yang dipakai di baris itu, jadi kalau diverifikasi ketat malah gagal karena mismatch.

Setelah config itu di reload, bukan cuma endpoint yang tadinya saya sibukin ngetes, agent di server lain yang lagi mentok coba konek ke jalur fallback pun langsung jalan lagi.

Tiga Bug, Satu Gejala

Kalau diliat ke belakang, tiga masalah ini sebenarnya tidak nyambung satu sama lain secara teknis. Satu bug di logika render komponen frontend. Satu lagi proses instalasi yang belum lengkap kondisinya. Satu lagi konfigurasi jaringan di layer yang beda sama sekali, bahkan di server yang beda. Tapi ketiganya numpuk jadi satu gejala yang sama di permukaan, status agent tidak muncul.

Kalau saya cuma puas begitu bug pertama kelar, karena tile nya udah muncul lagi, saya bakal kelewatan dua masalah lain yang jauh lebih penting. Dan kalau saya langsung curiga ke jaringan dari awal tanpa ngecek data di database dulu, saya mungkin bakal buang waktu di tempat yang salah.

Pelajaran yang saya bawa dari sini sederhana. Begitu nemu fix pertama, jangan langsung anggap selesai cuma karena gejala yang paling kelihatan udah ilang. Tanya lagi, apa benar ini akar masalahnya, atau cuma lapisan paling atas yang paling gampang keliatan. Dan kalau ada dua lingkungan yang hasilnya beda padahal harusnya sama, curiga dulu ke jalur yang dilewatin, jangan buru buru nyalahin kode.