Belajar MetalLB - Observability & Monitoring

#Pendahuluan

MetalLB adalah sistem yang bekerja dalam senyap — sampai tiba-tiba sebuah Service tidak bisa diakses dan kalian bertanya apa yang terjadi. Jawaban untuk hampir semua pertanyaan itu sudah disediakan MetalLB dalam bentuk metric Prometheus, events, dan log. Episode 11 mengajarkan cara memanfaatkan ketiganya untuk memantau dan mendiagnosis cluster.

Observability bukan pelengkap; ini garis depan troubleshooting. Dengan metric yang tepat, kalian bisa melihat pool mendekati penuh sebelum Service gagal dialokasikan, atau sesi BGP yang flapping sebelum traffic putus. Pemantauan proaktif inilah yang membedakan operasional profesional dari yang reaktif.

#Metric Prometheus dari Speaker dan Controller

#Endpoint Metric di Port 7472

Baik speaker maupun controller mengekspos metric Prometheus pada port 7472. Formatnya standar Prometheus, sehingga bisa langsung di-scrape oleh Prometheus server mana pun:

kubectl get pods -n metallb-system
kubectl port-forward svc/metallb-controller 7472:7472 -n metallb-system

Setelah kubectl port-forward svc/metallb-controller 7472:7472 berjalan, buka http://localhost:7472/metrics untuk melihat daftar metric. Perhatikan bahwa saat di-scrape, port-nya adalah 7472 untuk controller dan 7472 juga untuk speaker.

#Metric yang Paling Berguna

Beberapa metric inti yang sering dipakai:

• metallb_allocator_allocated_ip_total: jumlah IP yang sedang dialokasikan.
• metallb_allocator_addresses_in_use_total: IP yang sedang terpakai dari sebuah pool.
• metallb_allocator_addresses_total: total IP yang tersedia di sebuah pool.
• metallb_bgp_session_up: status sesi BGP (1 untuk up, 0 untuk down).
• metallb_speaker_announced_prefixes_total: jumlah prefix yang sedang di-announce.

Dengan metallb_allocator_addresses_in_use_total dan metallb_allocator_addresses_total dari pool yang sama, kalian bisa membuat alert ketika sebuah pool sudah mencapai, misalnya, 90 persen kapasitas.

#Memasang ServiceMonitor untuk Prometheus

#Scraping Otomatis dengan Prometheus Operator

Jika cluster memakai Prometheus Operator, cara paling rapi adalah membuat ServiceMonitor. Helm chart MetalLB menyediakan Service dan label yang siap dipakai:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: metallb
  namespace: metallb-system
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: metallb
  endpoints:
    - port: metrics
      interval: 30s

ServiceMonitor dengan selector label bawaan chart ini akan menargetkan endpoint metric controller dan speaker sekaligus. Setelah diterapkan dan Prometheus reload, metric MetalLB mulai masuk ke TSDB.

#Memeriksa Apakah Scrape Berhasil

Untuk memastikan target ter-scrape:

kubectl get servicemonitor -n metallb-system
curl -s http://localhost:7472/metrics | head -20

curl -s http://localhost:7472/metrics menampilkan baris metric dalam format teks Prometheus. Jika sudah terlihat, konfigurasi scraping sudah benar.

#Grafana Dashboard

#Visualisasi Alokasi dan Peering

Meskipun belum ada dashboard resmi yang di-maintain tim MetalLB di halaman grafana.com, banyak dashboard komunitas yang bisa diimpor — cari dengan kata kunci metallb. Panel yang paling berguna biasanya:

• Penggunaan IP per pool dalam bentuk gauge.
• Status sesi BGP per peer.
• Jumlah Service yang memakai LoadBalancer.
• Tingkat announcement per speaker.

curl -sL https://grafana.com/api/dashboards/14035/revisions/1/download > metallb-dashboard.json

curl -sL https://grafana.com/api/dashboards/14035/revisions/1/download mengunduh salah satu dashboard komunitas yang populer. Setelah itu impor file JSON tersebut di Grafana melalui menu Dashboards.

#Events dan Logging untuk Diagnosis

#Events Sebagai Alur Narasi

Events adalah catatan kejadian yang paling mudah dibaca. Untuk Service bermasalah, events menceritakan apa yang terjadi secara berurutan:

kubectl get events --all-namespaces | grep -i metallb
kubectl describe svc nginx

kubectl get events --all-namespaces | grep -i metallb menampilkan semua event yang melibatkan komponen MetalLB — dari alokasi IP hingga kegagalan yang terjadi.

#Log Speaker dan Controller

Saat events tidak cukup, log adalah sumber berikutnya. Log speaker menampilkan detail announcement dan peering, sedangkan log controller menampilkan keputusan alokasi:

kubectl logs -n metallb-system -l component=speaker --tail=50
kubectl logs -n metallb-system -l component=controller --tail=50

kubectl logs -n metallb-system -l component=speaker --tail=50 menampilkan baris seperti Announcing 192.168.1.200 from node worker-1 atau error peering BGP. Kombinasi events dan log ini adalah alat diagnosis utama yang akan kita pakai lagi secara mendalam di episode 19.

#Penutup

Episode 11 menuntaskan observability MetalLB: metric Prometheus di port 7472, ServiceMonitor untuk scraping otomatis, Grafana dashboard untuk visualisasi, serta events dan log sebagai alat diagnosis harian.

Inti yang harus dibawa pulang:

• Speaker dan controller mengekspos metric Prometheus di port 7472.
• metallb_allocator_addresses_in_use_total dan addresses_total untuk memantau kapasitas pool.
• metallb_bgp_session_up untuk memantau status peering BGP.
• ServiceMonitor memudahkan scraping jika memakai Prometheus Operator.
• Events dan log speaker/controller adalah sumber utama diagnosis.
• Dashboard Grafana komunitas bisa diimpor untuk visualisasi cepat.

Di episode 12 selanjutnya kita akan membahas integrasi Ingress & Nginx — meng-expose Ingress Controller sebagai Service LoadBalancer, membandingkan LoadBalancer versus NodePort untuk Ingress, dan membangun alur end-to-end dari aplikasi menuju Ingress dan keluar lewat MetalLB.