Kenapa Metrics di Topology Consul Carbonio Kosong?

Pernah nggak sih kalian membuka halaman Topology di Consul, melihat semua service Carbonio sudah saling terhubung, tapi bagian metrics-nya malah menampilkan No Metrics Available? Saya baru saja menemukan kondisi ini pada environment Carbonio single server. Topologinya tampil dengan benar, relasi antara carbonio-proxy dan carbonio-catalog terlihat jelas, bahkan status health check-nya menunjukkan 100%. Tapi begitu Consul mencoba memuat metrics, hasilnya tetap kosong.

Awalnya saya mengira Consul belum berhasil terhubung ke Prometheus. Setelah dicek lebih dalam, ternyata masalahnya bukan pada koneksi sama sekali. Prometheus aktif dan menyimpan ratusan metrics Consul. Masalah sebenarnya justru ada pada jenis metrics yang dibutuhkan oleh halaman Topology, dan itu yang akan saya urai pelan-pelan di tulisan ini.

Menghubungkan Consul UI ke Prometheus

Consul sebenarnya sudah punya metrics provider bawaan untuk Prometheus, dan konfigurasinya diletakkan pada file /etc/zextras/service-discover/config.json. Karena Prometheus berada di server yang sama, konfigurasi yang saya pakai kurang lebih seperti ini:

{
  "bind_addr": "192.168.10.201",
  "ui_config": {
    "enabled": true,
    "metrics_provider": "prometheus",
    "metrics_proxy": {
      "base_url": "http://127.0.0.1:9090"
    }
  }
}

Ada satu jebakan kecil di sini yang gampang bikin gagal. Blok ui_config harus berada di dalam object JSON utama dan dipisahkan dengan koma dari key sebelumnya, dan URL-nya harus berupa URL polos, bukan format Markdown seperti [http://localhost:9090](http://localhost:9090). Kesalahan sepele di bagian ini bisa bikin seluruh konfigurasi ditolak.

Karena itu, sebelum merestart service, saya selalu validasi dulu file JSON-nya, baru kemudian merestart Carbonio Mesh kalau outputnya bersih.

jq . /etc/zextras/service-discover/config.json

systemctl restart service-discover
systemctl status service-discover --no-pager

Sampai tahap ini, Consul UI sudah bisa mencoba mengambil data dari Prometheus. Tapi pada kasus saya, kartu service-nya tetap keras kepala menampilkan No Metrics Available, jadi perjalanannya belum selesai.

Memastikan Prometheus Benar-Benar Aktif

Langkah berikutnya adalah memastikan Prometheus bukan sekadar aktif menurut systemd, tapi benar-benar siap menerima query. Ini penting supaya saya tidak salah menuduh, karena “aktif” dan “siap melayani” itu dua hal yang berbeda.

curl -fsS http://127.0.0.1:9090/-/ready

Hasilnya jelas, Prometheus Server is Ready. Untuk lebih yakin, saya juga memeriksa semua service yang terlibat dalam rantai monitoring ini sekaligus.

systemctl is-active 
  service-discover 
  carbonio-prometheus 
  grafana-server 
  carbonio-prometheus-consul-exporter

Semuanya dalam kondisi active. Artinya alur dari Consul UI menuju Prometheus sudah benar, dan dugaan soal masalah koneksi resmi bisa saya coret dari daftar tersangka.

Metric Consul Ada, Metric Envoy Tidak Ada

Bagian inilah yang akhirnya membuka jawabannya. Saya mulai dengan menghitung berapa banyak seri metrics Consul yang benar-benar tersimpan di Prometheus.

curl -sS -G http://127.0.0.1:9090/api/v1/query 
  --data-urlencode 'query=count({__name__=~"consul_.*"})'

Prometheus mengembalikan angka 692, jadi metrics dengan nama consul_* memang tersedia dan berhasil dikumpulkan oleh carbonio-prometheus-consul-exporter. Sampai sini semuanya terlihat sehat. Lalu saya menjalankan query yang sama untuk metrics Envoy.

curl -sS -G http://127.0.0.1:9090/api/v1/query 
  --data-urlencode 'query=count({__name__=~"envoy_.*"})'

Dan hasilnya berupa vector kosong.

{
  "status": "success",
  "data": {
    "resultType": "vector",
    "result": []
  }
}

Di titik inilah root cause-nya ketemu. Ternyata Consul UI tidak memakai metrics consul_* untuk mengisi statistik pada kartu Topology, melainkan mengharapkan metrics dari Envoy sidecar. Sementara Prometheus Carbonio pada environment ini tidak memiliki satu pun seri envoy_*. Jadi wajar kalau topologinya tetap tampil, karena Consul tahu registrasi service, sidecar, dan relasinya, begitu juga health check yang datanya berasal dari Consul. Yang tidak bisa muncul justru statistik traffic seperti jumlah request, error rate, dan success rate, karena angka-angka itu semua bergantung pada telemetry Envoy.

Kenapa Tidak Langsung Mengaktifkan Metrics Envoy?

Secara teknis, Envoy memang bisa dikonfigurasi agar membuka endpoint Prometheus lewat envoy_prometheus_bind_addr, lalu Prometheus tinggal melakukan scrape ke endpoint setiap sidecar. Terdengar sederhana, tapi di lapangan tidak sesederhana itu.

Masalahnya, satu server Carbonio bisa menjalankan banyak Envoy sidecar dalam network namespace yang sama, dan setiap endpoint butuh kombinasi alamat dan port yang tidak bentrok. Memasang satu port global tanpa perencanaan matang bisa membuat beberapa sidecar berebut port dan malah gagal berjalan. Karena konfigurasi sidecar Carbonio juga dikelola oleh paket dan workflow Carbonio Mesh, saya memilih tidak memaksakan perubahan global hanya demi membuat angka muncul di Consul UI. Buat saya, nilai operasionalnya tidak sebanding dengan risiko mengganggu komunikasi internal Carbonio.

Ada Temuan Lain di Port 9115

Sambil menelusuri target Prometheus, saya menemukan masalah lain yang sebenarnya terpisah dari kasus utama. Beberapa target Carbonio mencoba memakai Blackbox Exporter lewat 127.0.0.1:9115, padahal tidak ada proses yang mendengarkan port tersebut. Pengecekannya cukup sederhana.

ss -lnt 'sport = :9115'

Tidak ada listener yang muncul, dan paket carbonio-prometheus-blackbox-exporter memang belum terpasang walaupun tersedia di repository Zextras. Temuan ini bukan penyebab kosongnya metrics Envoy di Consul UI, tapi dampaknya tetap penting, karena target TCP yang mengandalkan Blackbox Exporter akan berstatus DOWN di Prometheus. Jadi perbaikannya saya perlakukan sebagai pekerjaan monitoring tersendiri, bukan bagian dari kasus ini.

Solusi yang Lebih Masuk Akal

Untuk monitoring Carbonio sehari-hari, saya akhirnya memilih membiarkan tiap tool bekerja sesuai perannya masing-masing. Consul UI saya pakai untuk melihat registrasi service, relasi topology, node, dan health check. Prometheus saya andalkan untuk mengumpulkan dan menyimpan metrics Carbonio. Dan Grafana saya gunakan untuk visualisasi lengkap lewat dashboard Carbonio.

Kebetulan Carbonio sudah menyediakan dashboard bernama Carbonio Service Discover status dengan ID 20032, yang memang dirancang untuk menampilkan kondisi server dan service yang terdaftar di Consul. Tombol Configure dashboard di halaman Consul pun bisa diarahkan ke Grafana, sehingga Consul tetap berfungsi sebagai ringkasan cepat, sementara analisis metrics yang lebih dalam dilakukan di tool yang memang dibangun untuk observability.

Kesimpulan

Jadi, tulisan No Metrics Available pada Topology Consul tidak selalu berarti konfigurasi Prometheus rusak. Pada kasus ini, koneksi Consul ke Prometheus sehat dan metrics Consul tersedia, yang tidak ada justru telemetry Envoy yang secara spesifik dibutuhkan oleh provider bawaan Consul UI. Intinya, gunakan Consul untuk memahami struktur dan kesehatan service, lalu gunakan Prometheus dan Grafana untuk membaca kondisi Carbonio secara lebih lengkap.

Setupnya memang terlihat seperti beberapa tool yang berdiri sendiri-sendiri. Tapi begitu setiap tool dipakai sesuai perannya, troubleshooting jadi jauh lebih jelas dan risiko perubahan yang tidak perlu bisa dihindari. Kalau kalian pernah mencoba menampilkan metrics Envoy dari seluruh sidecar Carbonio tanpa mengganggu konfigurasi bawaannya, boleh banget berbagi pendekatannya di kolom komentar.

TutuLore