Belajar 9router - Observability at Scale

#Pendahuluan

Di episode 19 konfigurasi 9router mengalir lewat pipeline otomatis dan setiap perubahan bisa di-rollback cepat. Tapi otomasi tanpa penglihatan sama seperti menyetir dengan mata tertutup: bisa saja melaju cepat — sampai tabrakan. Observability yang diperkenalkan di episode 7 membahas dasar-dasar metrik, log, dan tracing untuk request AI. Episode 20 menaikkannya ke skala produksi.

Roadmap episode ini: pertama mendefinisikan metrik yang wajib dipantau, kedua membangun dashboard untuk route, model, dan tool, ketiga mendeteksi anomali pada keputusan routing, lalu merancang alerting yang tidak berisik tapi tepat sasaran.

#Metrik yang Wajib Dipantau

Observability yang baik dimulai dari memilih metrik yang benar — bukan merekam segalanya. Untuk AI routing gateway, metrik terbagi tiga lapisan.

Lapisan route. Ini kesehatan fungsi utama gateway: volume request, success rate, fallback rate, dan confidence classifier intent. Fallback rate yang tinggi adalah alarm dini — bisa berarti model utama bermasalah atau rule matching mulai salah arah.

Lapisan model. Performa per provider: latency p50/p95/p99, jumlah token, biaya per request, dan frekuensi rate limit. Di sinilah trade-off cost dan latency dari episode 15 bisa diukur, bukan diperkirakan.

Lapisan tool. Setiap tool invocation punya metriknya sendiri: latency pemanggilan, error rate, dan cache hit ratio. Tool yang lambat memperlambat seluruh agentic flow meskipun modelnya sempurna.

Semua metrik ini diekspos 9router lewat endpoint /metrics dan bisa dicek cepat dengan 9router metrics check. Contoh query untuk mengukurnya dalam bahasa PromQL:

sum(rate(router_requests_total{route="chat-main"}[5m]))
histogram_quantile(0.95, sum by (le) (rate(router_latency_seconds_bucket[5m])))
sum(rate(router_fallback_total[5m])) by (route)
sum(rate(router_cost_usd_total[5m])) by (model)

Biasakan melihat tiga metrik ini bersamaan: volume, error, dan fallback. Volume naik wajar di jam sibuk; volume naik bersamaan dengan fallback yang naik adalah masalah.

#Dashboard Route, Model, dan Tool

Dashboard adalah tempat metrik menjadi bisa dibaca. Di Grafana, susunan efektif untuk gateway AI biasanya tiga baris. Baris pertama "Routing Overview": request rate per route, success rate, dan fallback rate. Baris kedua "Model Performance": latency histogram per provider dan estimasi biaya. Baris ketiga "Tool Health": error rate dan latency per tool.

Panel yang wajib ada di antaranya:

• Request volume per route — melihat distribusi traffic dan mengidentifikasi route yang tidak wajar.
• Latency p95 per provider — p95 lebih jujur daripada rata-rata; rata-rata menyembunyikan lonjakan.
• Fallback rate — metrik ini layak diberi panel tersendiri, bukan disembunyikan di metrik lain.
• Cost per model — mencegah tagihan bulanan menjadi kejutan.

Panel latency p95 per provider bisa ditulis seperti ini:

histogram_quantile(
  0.95,
  sum by (le, provider) (
    rate(router_latency_seconds_bucket[5m])
  )
)

Tambahkan variabel route dan provider pada dashboard agar bisa difilter tanpa mengedit query. Dashboard yang baik adalah yang bisa dijawab oleh siapa pun — tidak butuh satu orang tertentu untuk menafsirkan grafik.

#Mendeteksi Anomali pada Keputusan Routing

Metrik yang sehat pun bisa menyembunyikan anomali yang berbahaya. Anomali pada routing tidak selalu berbentuk error; kadang berupa pergeseran halus:

• Fallback rate melonjak diam-diam dari 1 persen ke 15 persen tanpa alert error.
• Confidence classifier turun — intent sering salah dikategorikan, traffic tersebar ke route yang tidak tepat.
• Traffic redistribusi drastis — satu route kehilangan volume dalam hitungan menit tanpa perubahan deploy.

Deteksi anomali bekerja dengan membandingkan kondisi saat ini dengan baseline. Beberapa pendekatan yang bisa dipakai:

1. Threshold statis — sederhana, misalnya fallback rate di atas 20 persen.
2. Persentase perubahan — membandingkan nilai 5 menit terakhir dengan periode yang sama minggu lalu.
3. Prediksi baseline — memakai data historis untuk memprediksi nilai yang diharapkan, lalu menghitung deviasi.

Contoh query yang membandingkan dengan baseline satu minggu lalu:

(
  sum(rate(router_fallback_total[5m]))
  /
  clamp_min(sum(rate(router_requests_total[5m])), 1)
)
/
(
  sum(rate(router_fallback_total[1h] offset 1w))
  /
  clamp_min(sum(rate(router_requests_total[1h] offset 1w)), 1)
)
> 2

Query ini bernilai true ketika fallback rate saat ini dua kali lebih tinggi daripada periode yang sama minggu lalu. Teknik semacam ini menangkap anomali yang lolos dari threshold sederhana.

#Alerting untuk Route yang Gagal dan Terdegradasi

Alerting adalah bagian yang paling mudah digeneralisasi dan paling mudah salah. Aturan utamanya: setiap alert harus bisa ditindaklanjuti, dan setiap alert harus jarang berbunyi. Alert yang terlalu sensitif akan diabaikan — dan pada akhirnya mengalahkan tujuannya.

Contoh aturan alert yang sehat:

groups:
  - name: 9router-routes
    rules:
      - alert: RouteHighErrorRate
        expr: router_success_rate < 0.95
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Error rate route tinggi dalam 5 menit"
 
      - alert: FallbackRateElevated
        expr: fallback_rate_ratio > 0.2
        for: 10m
        labels:
          severity: ticket
        annotations:
          summary: "Fallback rate tinggi, periksa provider utama"
 
      - alert: DegradedModeActive
        expr: router_degraded_mode > 0
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "Gateway masuk degraded mode"

Perhatikan for pada tiap aturan — alert hanya dibunyikan jika kondisi bertahan selama durasi tersebut, sehingga pager tidak terbakar oleh lonjakan sesaat. Severity dibedakan dengan bijak: page untuk kondisi yang butuh manusia sekarang (degraded mode, error rate tinggi), ticket untuk kondisi yang perlu diselidiki tapi tidak darurat (fallback rate).

Terakhir, hubungkan setiap alert dengan runbook lewat annotation. On-call yang dibangunkan tengah malam tidak boleh menebak-nebak langkah; runbook itulah topik episode 21.

#Penutup

Episode 20 melengkapi mata produksi kalian: metrik berlapis route, model, dan tool; dashboard yang bisa dibaca siapa saja; teknik deteksi anomali yang membandingkan kondisi dengan baseline; serta alerting yang jarang berbunyi tapi selalu tepat sasaran.

Inti yang harus dibawa pulang:

• Fallback rate adalah metrik paling penting yang jarang dipantau — beri dashboard khusus untuknya.
• Dashboard harus bisa dijawab oleh siapa pun, bukan hanya pembuatnya.
• Anomali sering berupa pergeseran halus, bukan error; bandingkan dengan baseline untuk menangkapnya.
• Alert harus jarang berbunyi dan selalu bisa ditindaklanjuti; for mencegah pager terbakar.
• Setiap alert wajib merujuk ke runbook — on-call tidak boleh menebak.

Di episode 21 kita menyusun fondasi operasionalnya: operational readiness dan runbook — menulis prosedur insiden routing, menetapkan ownership dan batas dukungan, serta mendokumentasikan standar route dan policy. Sampai jumpa!