Belajar GitOps - FluxCD - Monitoring & Observability

#Pendahuluan

Di episode 24 kalian sudah belajar membuat Flux cepat dan andal di skala besar — horizontal sharding, vertical sharding, tuning interval, dan pola repository yang efisien. Klaster kini berjalan mulus, tetapi ada pertanyaan yang lebih dalam: bagaimana kita tahu ia benar-benar sehat? Jawaban jujurnya: kita tidak akan tahu sampai terjadi insiden, kecuali kita memiliki observability yang baik.

Perhatikan bahwa performa dan observability adalah dua sisi dari koin yang sama. Tanpa metrik, optimasi di episode kemarin hanyalah tebakan — kita tidak tahu controller mana yang menjadi bottleneck, kapan reconciliation memanjang, atau apakah sharding benar-benar membantu. Monitoring mengubah semua keputusan itu dari perasaan menjadi data.

Pada episode ini kita akan membangun fondasi observability untuk Flux secara menyeluruh: metrik Prometheus yang diekspos setiap controller, dashboard Grafana resmi dan kustom, logging serta agregasi log, distributed tracing dengan OpenTelemetry untuk menelusuri reconciliation, dan alerting agar masalah diketahui sebelum pengguna mengeluh.

#Metrik Flux dengan Prometheus

#Kontroller Menyediakan Metrik

Setiap controller Flux — source, kustomize, helm, dan notification — mengekspos endpoint metrik Prometheus pada port 8080 di path /metrics. Ini memudahkan Prometheus mengambil metrik langsung dari Pod controller, bahkan tanpa ekspor tambahan. Konfigurasi bootstrap Flux sudah menyertakan anotasi scraping sehingga Prometheus bisa menemukannya secara otomatis:

annotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "8080"

Dengan kube-prometheus-stack atau Prometheus Operator yang mengikuti ServiceMonitor, anotasi ini cukup untuk memulai scraping. Untuk instalasi Prometheus manual, tambahkan job scrape dengan target kustomize-controller:8080, source-controller:8080, dan seterusnya.

#Metrik Reconciliation dan Status

Metrik yang paling penting untuk dipantau adalah metrik yang berkaitan dengan siklus reconciliation. Beberapa di antaranya:

• gotk_reconcile_condition — status kondisi terakhir per resource (Ready, Available), dilabeli dengan type, status, reason, kind, dan namespace. Ini adalah metrik inti untuk tahu apakah reconciliation berhasil.
• gotk_reconcile_duration_seconds — histogram durasi setiap reconciliation. Pemicu awal untuk investigasi bottleneck.
• gotk_apply_duration_seconds — histogram durasi operasi apply ke Kubernetes API.
• gotk_source_info — informasi versi artifact source terakhir (revisi, hash commit).
• gotk_suspend_status — menandai resource yang sedang disuspend; resource suspend yang tidak disengaja sering terlihat di sini.

Untuk memeriksa metrik mentah langsung dari controller:

kubectl -n flux-system port-forward deploy/kustomize-controller 8080
curl -s localhost:8080/metrics | grep gotk_reconcile_condition | head

gotk_reconcile_condition dengan status="False" berarti reconciliation terakhir gagal — alarm yang harus segera diselidiki. Pada versi Flux terbaru, metrik ini dilaporkan sebagai gauge status terkini, sehingga bisa langsung dipakai dalam aturan alert.

#Metrik Status Resource

Selain metrik reconciliation, ada pula metrik yang menggambarkan status resource itu sendiri. gotk_resource_info merekam informasi resource yang di-reconcile, termasuk status kesehatan akhir. Kombinasi metrik reconciliation dan resource status memberikan gambaran lengkap: bukan hanya apakah proses berjalan, tetapi juga apakah hasil akhirnya benar-benar Ready.

Klasifikasi metrik yang perlu dibedakan saat membaca dashboard:

#Dashboard Grafana

#Dashboard Resmi Flux

Grafana adalah pasangan natural Prometheus, dan Flux menyediakan dashboard resmi di dalam repositori-nya. Dashboard ini bisa diimpor langsung ke Grafana dan sudah berisi panel-panel penting: kecepatan reconciliation, durasi, kegagalan, dan status per controller. Untuk menginstalnya, tambahkan dashboard tersebut ke provisioning Grafana atau impor secara manual melalui menu import dengan JSON yang diunduh dari repositori Flux.

Panel-panel yang terdapat di dashboard resmi antara lain:

• Reconciliation rate per controller — seberapa sering setiap controller mereconcile.
• Reconciliation duration — histogram 50th dan 99th percentile, untuk melihat perlambatan.
• Failed reconciliations — jumlah dan alasan kegagalan.
• Source status — kapan terakhir source berhasil di-fetch.

#Dashboard Kustom

Dashboard resmi adalah titik awal yang baik, tetapi setiap organisasi punya kebutuhan unik. Dashboard kustom dibuat dengan query PromQL yang menargetkan metrik spesifik. Contoh panel sederhana untuk menunjukkan Kustomization yang tidak siap:

- title: Kustomization not ready
  targets:
    - expr: |
        gotk_reconcile_condition{kind="Kustomization", type="Ready", status="False"}
      legendFormat: "{{kind}}/{{name}}"
  gridPos:
    h: 8
    w: 12

Query PromQL di atas menampilkan setiap Kustomization yang kondisi Ready-nya False — sekali pandang, tim langsung tahu mana yang bermasalah. Tambahkan panel serupa untuk GitRepository, HelmRelease, dan Receiver.

#Metrik Kunci yang Harus Dipantau

Beberapa metrik layak mendapat tempat permanen di dashboard karena selalu relevan:

• Rasio kegagalan reconciliation — persentase reconciliation yang gagal dari total; lonjakan tiba-tiba adalah tanda awal masalah.
• Durasi reconciliation p95 — jangan menunggu rata-rata; ekor (tail) yang panjang adalah indikator bottleneck.
• Waktu terakhir source di-fetch — source yang tidak pernah di-fetch ulang berarti webhook atau interval bermasalah.
• Status suspend — resource yang secara tidak sengaja disuspend adalah sumber kebingungan yang klasik.

#Logging

#Log Kontroller dan Event

Metrik memberi tahu apa yang terjadi; log memberi tahu mengapa. Setiap controller Flux menulis log ke stdout Pod-nya dan bisa dibaca dengan perintah biasa. Flux juga menyediakan CLI untuk mempermudah:

flux logs --level=debug
flux logs --all-namespaces --tail=50
kubectl -n flux-system logs deploy/kustomize-controller --tail=50

Selain log controller, Kubernetes Events adalah sumber informasi penting. Saat reconciliation gagal, Flux menulis event dengan pesan kesalahan yang detail:

kubectl get events -n flux-system --sort-by=.lastTimestamp

Event inilah yang sering menjadi petunjuk pertama saat debugging: alasan kegagalan, resource yang terlibat, dan waktu kejadian.

#Level Log

Flux mendukung beberapa level log: error, info, dan debug. Level debug menampilkan detail langkah demi langkah reconciliation — sangat berguna saat debugging, tetapi sangat bising di produksi. Atur level via flag --log-level pada controller atau saat bootstrap:

flux bootstrap github \
  --owner=devvnull \
  --repository=gitops-production \
  --branch=main \
  --log-level=debug

Gunakan info sebagai default produksi, dan naikkan ke debug hanya saat ada investigasi. Kustomize controller secara khusus memerlukan --log-level=debug untuk melihat detail diff yang diterapkan.

#Agregasi Log dengan Loki atau Elasticsearch

Di klaster dengan banyak Pod controller, membaca log per Pod tidak praktis. Di sinilah agregasi log berperan: kumpulkan semua log ke satu tempat pencarian. Dua pendekatan yang umum:

• Loki + Grafana — log disimpan di Loki, dicari dari Grafana dengan label (misal namespace dan nama controller). Ringan dan terintegrasi dengan dashboard yang sudah ada.
• Elasticsearch + Kibana — fitur pencarian penuh dan beban lebih berat; cocok jika organisasi sudah memakai stack ELK.

Dengan agregasi, debugging lintas controller menjadi mudah: telusuri satu reconciliation dari log source-controller sampai kustomize-controller tanpa berpindah-pindah Pod.

#Distributed Tracing dengan OpenTelemetry

#Mengaktifkan Tracing

Metrik dan log belum menjelaskan bagaimana waktu dihabiskan di dalam satu reconciliation. Distributed tracing memecahkan masalah ini: setiap reconciliation menghasilkan sebuah trace berisi span-spans (langkah-langkah) — fetching source, membangun manifest, apply ke Kubernetes, dan menunggu kesehatan. Flux mendukung OpenTelemetry Protocol (OTLP) dan dapat mengekspor trace ke backend seperti Tempo, Jaeger, atau Grafana Cloud.

Tracing diaktifkan per controller dengan flag --enable-otlp=true dan environment variable OTEL_EXPORTER_OTLP_ENDPOINT:

containers:
  - name: manager
    args:
      - "--enable-otlp=true"
    env:
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: "http://tempo.monitoring.svc:4317"

Setelah tracing aktif, setiap reconciliation menghasilkan trace baru yang bisa dicari berdasarkan nama resource dan revisi.

#Menelusuri Siklus Reconciliation

Dengan trace, pertanyaan yang sebelumnya sulit dijawab menjadi mudah. Lihat satu trace reconciliation Kustomization: berapa lama waktu fetch? Berapa lama render manifest? Berapa lama operasi apply? Di titik mana trace paling lambat?

Pola bottleneck yang sering muncul:

• Fetch lambat — sumber Git besar atau jaringan ke git host buruk; solusinya adalah OCIRepository atau sumber yang lebih dekat.
• Apply lambat — API server atau webhook admission memperlambat penerapan; periksa ValidatingWebhook yang menghambat.
• Menunggu kesehatan lambat — health assessment menunggu resource menjadi Ready terlalu lama; periksa readiness aplikasi.

#Alerting

#Alert Bawaan Flux: Provider dan Alert

Flux memiliki sistem alerting bawaan melalui dua CRD: Provider (definisi tujuan notifikasi, misalnya Slack, GitHub, atau webhook umum) dan Alert (aturan kapan dan untuk apa notifikasi dikirim). Contoh untuk mengirim notifikasi Slack saat ada reconciliation error:

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Provider
metadata:
  name: slack
  namespace: flux-system
spec:
  type: slack
  channel: gitops-alerts
  secretRef:
    name: slack-webhook

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Alert
metadata:
  name: reconciliation-failed
  namespace: flux-system
spec:
  providerRef:
    name: slack
  eventSeverity: error
  eventSources:
    - kind: Kustomization
      name: '*'

eventSources dengan name: '*' berarti semua Kustomization di namespace flux-system ikut dipantau. Setiap event dengan severity error langsung diteruskan ke Slack — deteksi instan tanpa menunggu interval monitoring.

#AlertManager dan Aturan Prometheus

Untuk alert yang lebih kompleks — misalnya berbasis tren atau periode — gunakan Prometheus AlertManager dengan aturan yang memakai metrik Flux. Contoh aturan untuk mendeteksi reconciliation yang gagal lebih dari lima menit:

groups:
  - name: flux.rules
    rules:
      - alert: ReconciliationFailed
        expr: |
          gotk_reconcile_condition{type="Ready", status="False"} == 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Reconciliation gagal untuk {{ $labels.name }}"

Kombinasikan AlertManager dengan aturan untuk sumber yang tidak tersedia (source controller gagal fetch berkali-kali) dan health check yang gagal (resource tidak menjadi Ready dalam batas waktu). Pembagian alert berdasarkan severity — warning untuk gangguan kecil, critical untuk failure yang berdampak pengguna — menjaga notifikasi tetap berguna.

#Penutup

Pada episode 25 ini kalian telah membangun fondasi observability untuk Flux: metrik Prometheus dari setiap controller dengan fokus pada gotk_reconcile_condition dan durasi reconciliation, dashboard Grafana resmi dan kustom, logging dengan level dan agregasi ke Loki atau Elasticsearch, distributed tracing dengan OpenTelemetry untuk menelusuri bottleneck di dalam satu reconciliation, serta alerting melalui notifikasi bawaan Flux dan aturan AlertManager.

Inti yang harus dibawa pulang:

• Metrik adalah bahasa kesehatan Flux — kenali gotk_reconcile_condition, gotk_reconcile_duration_seconds, dan gotk_apply_duration_seconds sebelum yang lain.
• Dashboard resmi Flux adalah titik awal yang baik, lalu perluas dengan panel kustom yang menjawab pertanyaan spesifik organisasi kalian.
• Log menjawab mengapa, metrik menjawab apa — gabungkan keduanya, dan agregasi log membuat debugging lintas controller praktis.
• Tracing dengan OpenTelemetry membuka isi reconciliation — aktifkan bertahap untuk menemukan bottleneck tanpa overhead yang berlebihan.
• Alert yang baik adalah alert yang sedikit dan tepat — kombinasi Alert bawaan Flux dan aturan AlertManager dengan severity yang terstruktur.

Sekarang kalian bisa melihat semuanya. Pertanyaan berikutnya: apa yang terjadi jika semuanya runtuh? Di episode 26 selanjutnya kita akan membahas Disaster Recovery & Backup — strategi backup dengan Git dan Velero, snapshot etcd, ekspor konfigurasi Flux, prosedur rebuild klaster dan re-bootstrap, hingga latihan DR dengan target RTO dan RPO yang terukur. Karena observasi terbaik pun tidak berarti tanpa rencana pemulihan. Pastikan tetap semangat!