Belajar Multigress - Observability at Scale

#Pendahuluan

Di episode 7 kita belajar dasar observability. Episode 20 menaikkan levelnya: observability at scale — memantau performa route dan latensi dengan tepat, menghubungkan trace dari ingress sampai backend, dan membangun dashboard untuk SLI traffic yang benar-benar dipakai tim.

Pada skala besar, jumlah data melimpah. Tantangannya bukan mengumpulkan metrik, melainkan mengubahnya menjadi sinyal yang bisa diambil keputusan.

#Monitoring Performa Route dan Latency

#Metric Kunci Gateway

Beberapa metrik layak dijadikan baris pertama dashboard: request total, error rate per status, dan latensi. Latensi paling berguna dalam bentuk histogram karena memungkinkan perhitungan percentile.

histogram_quantile(0.95,
  sum(rate(multigress_http_request_duration_seconds_bucket[5m])) by (le, route))

Query histogram_quantile(0.95, ...) menghitung P95 dari histogram durasi request per route. Angka ini jauh lebih berguna daripada rata-rata, karena menampakkan anomali latensi yang menimpa sebagian pengguna.

#Alert Berbasis Latensi

Latensi yang memburuk harus memicu alert, bukan hanya terlihat di dashboard. Buat PrometheusRule yang menghitung P95 secara berkelanjutan.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: multigress-latency
  namespace: monitoring
spec:
  groups:
    - name: gateway-latency
      rules:
        - alert: GatewayHighP95
          expr: |
            histogram_quantile(0.95,
              sum(rate(multigress_http_request_duration_seconds_bucket[5m])) by (le, route))
            > 1
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "P95 latency tinggi pada {{ $labels.route }}"

Jika P95 melewati 1 detik selama 10 menit, alert GatewayHighP95 menyala dengan label route sebagai konteks. Alert ini menjadi bahan utama SLI di episode 21.

#Trace Correlation Melalui Ingress dan Backend

#Mengaktifkan Tracing di Multigress

Metrik memberi tahu ada masalah; trace menjelaskan di mana. Multigress bisa mengirim trace ke backend OTLP seperti Tempo atau Jaeger.

helm upgrade multigress multigress/multigress \
  --namespace multigress-system \
  --set tracing.enabled=true \
  --set tracing.exporter=otlp \
  --set tracing.otlpEndpoint=tempo.tracing.svc.cluster.local:4317

Konfigurasi di atas mengirim trace ke Tempo melalui gRPC di port 4317. Mulai dari sini, setiap request yang melewati gateway bisa diikuti sampai ke service backend.

#Propagasi Konteks Trace

Agar trace bersambung sampai backend, konteks trace harus dipropagasi lewat header seperti traceparent. Gateway menginjeksi header saat request masuk, dan service lain meneruskannya.

Dengan propagasi yang benar, kalian bisa melihat dari trace satu request: waktu di gateway, waktu di aplikasi, hingga waktu di database. Segmentasi inilah yang mempersingkat investigasi insiden latensi.

#Membangun Dashboard untuk Traffic SLI

#Panel Dashboard Grafana

Dashboard yang baik menampilkan SLI langsung, bukan seratus metrik mentah. Mulai dari error rate dan latensi per route, lalu tambahkan detail sesuai kebutuhan.

- title: Error rate per route
  targets:
    - expr: |
        sum(rate(multigress_http_requests_total{status=~"5.."}[5m])) by (route)
        / sum(rate(multigress_http_requests_total[5m])) by (route)

Panel Error rate per route menampilkan proporsi status 5xx per route. Satu panel seperti ini lebih bermakna daripada dua puluh panel yang jarang dipandang.

#Dashboard sebagai Kesepakatan Tim

Dashboard terbaik adalah yang dipakai saat insiden. Sertakan panel untuk traffic, error, dan latensi pada halaman yang sama, sehingga kronologi insiden terbaca tanpa berpindah tab.

#Penutup

Episode 20 membangun observability yang bisa diandalkan: metrik histogram untuk latensi yang akurat, trace yang menghubungkan gateway dan backend, serta dashboard yang menampilkan SLI sebagai kesepakatan tim.

Inti yang harus dibawa pulang:

• Histogram memungkinkan perhitungan percentile latensi yang akurat.
• Alert berbasis P95 mendeteksi degradasi sebelum pengguna ramai mengeluh.
• Tracing OTLP mengikuti request dari gateway sampai database.
• Propagasi header trace menjaga trace tetap bersambung.
• Dashboard yang baik menampilkan SLI, bukan metrik mentah.
• Simpan dashboard sebagai kode agar bisa di-review.

Di episode 21 selanjutnya kita akan membahas SLOs, runbooks & operational readiness — mendefinisikan SLI untuk ingress dan routing, membuat runbook untuk kegagalan dan perubahan route, serta pola on-call untuk operasional gateway. Metrik dan dashboard dari episode ini akan dirangkai menjadi target yang terukur.