Belajar OpenClaw - Observability at Scale

#Pendahuluan

Di episode 19 kalian sudah memastikan semua perubahan policy mengalir lewat GitOps. Episode 20 ini menjawab pertanyaan yang muncul begitu OpenClaw tumbuh: bagaimana melihat semua policy di banyak cluster tanpa tersesat? Di episode 7 kalian membangun observability essentials dasar. Sekarang waktunya men-scaling observability itu sendiri.

Roadmap episode 20: scaling metrics dan dashboards di banyak cluster, mengorelasikan policy events dengan service health, membangun alerting untuk perilaku abnormal, dan menjaga volume log tetap terkendali.

#Scaling Metrics dan Dashboards

Saat cluster bertambah, metrik OpenClaw bertambah juga — tiap policy, tiap service, tiap target ikut menyumbang deretan label. Masalah terbesar di observability skala besar bukan volume, tapi cardinality: kombinasi label yang meledak. Sebuah metrik dengan label per-service dan per-policy bisa menghasilkan jutaan deret yang menyiksa storage.

Metrik policy dengan label

{
  "name": "openclaw_policy_decision_total",
  "labels": {
    "cluster": "prod-eu-1",
    "namespace": "billing",
    "policy": "payment-access-policy",
    "action": "DENY"
  },
  "value": 4217,
  "timestamp": 1764800000000
}

Kendalikan cardinality sejak awal. Jangan menaruh nilai yang selalu berganti (seperti user ID atau nama pod) ke dalam label. Agregatkan di sisi exporter, simpan label yang benar-benar dipakai untuk grouping, dan pisahkan metrik berlabel banyak dari metrik yang perlu disimpan detail. Prometheus federation dan remote write ke storage jangka panjang seperti Thanos atau Mimir memisahkan data panas untuk query cepat dari data dingin untuk retensi panjang.

Dashboard untuk tiap audiens. Satu dashboard raksasa tidak membantu siapa pun. Buat tiga lapis: dashboard platform (kesehatan control plane, sinkronisasi policy), dashboard per-tim (policy milik tim itu, denials, status mTLS), dan dashboard eksekutif (SLO dan tren). Gunakan annotation untuk menandai kapan policy di-deploy lewat GitOps — nanti saat metrik aneh muncul, kalian langsung bisa menghubungkannya dengan deployment terakhir.

Satu pola yang perlu diperhatikan: jangan menyalin dashboard dari environment lain secara membabi buta. Trafik staging dan production punya baseline berbeda; dashboard yang dipakai untuk debug di staging bisa saja menyembunyikan masalah di production. Selalu verifikasi threshold dan rentang waktu terhadap lingkungan tujuan.

#Mengorelasikan Policy Events dengan Service Health

Metrik policy berdiri sendiri tidak banyak artinya. Nilainya muncul saat dikorelasikan dengan service health: apakah denial policy berkaitan dengan error 5xx? Apakah peningkatan latensi bertepatan dengan perubahan rate limit? Kunci korelasinya adalah label bersama — namespace, service, cluster — dan trace identifier yang menempel di policy event.

Policy event dengan trace context

{
  "event": "policy_denied",
  "service": "payment-service",
  "namespace": "billing",
  "traceId": "8f1a0c1e00000001",
  "reason": "rate_limit_exceeded",
  "statusCode": 429
}

Dengan membawa traceId di setiap policy event, kalian bisa melompat dari metrik denial ke trace yang sama, lalu ke log. Inilah alur three pillars yang dibahas di episode 14: metrik memberi tahu ada masalah, trace menunjukkan jalur request, log memberi detail. Saat denial rate naik bersamaan dengan SLO error budget yang menipis, kalian tahu bukan sekadar angka yang aneh, tapi ada pengalaman pengguna yang terdampak.

#Alerting pada Perilaku Abnormal

Alerting yang baik bukan soal banyak alert, tapi alert yang hanya berbunyi saat benar-benar perlu tindakan. Mulai dengan baseline: ketahui nilai normal denial rate, sync lag GitOps, dan error rate mTLS di tiap environment. Alert dipicu oleh penyimpangan dari baseline, bukan dari angka absolut yang asal diambil.

Rule alert untuk lonjakan denial

groups:
  - name: openclaw-policy.rules
    rules:
      - alert: PolicyDenialSpike
        expr: |
          rate(openclaw_policy_decision_total{action="DENY"}[5m])
          > 3 * rate(openclaw_policy_decision_total{action="DENY"}[5m] offset 1h)
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Lonjakan denial pada policy"

Rule di atas membandingkan denial rate lima menit terakhir dengan denial rate satu jam lalu. Penyimpangan tiga kali lipat selama sepuluh menit memicu alert — ini menangkap anomali (policy terlalu ketat, service diblokir, atau bahkan percobaan abuse) tanpa berisik karena kondisi normal. Kalian bisa memakai openclawctl alert list untuk melihat status alert dari sisi OpenClaw, lalu menautkannya dengan Alertmanager untuk routing dan deduplication.

Warning

Alert fatigue itu nyata. Setiap alert baru yang tidak berujung tindakan mengikis kepercayaan tim pada semua alert lain. Kalau sebuah alert tiga bulan tidak pernah menangkap masalah, evaluasi ulang — matikan atau ubah threshold-nya.

#Mengelola Volume Log dan Retention

Policy event di skala besar bisa membanjiri pipeline log. Kontrol volume dimulai dari sumber: log OpenClaw dibedakan berdasarkan kepentingan — decision log (setiap keputusan policy), audit log (perubahan konfigurasi), dan log runtime. Tidak semuanya butuh retensi yang sama.

Filter, sampling, dan retensi log

logging:
  sinks:
    - type: loki
      url: https://loki.internal/loki/api/v1/push
  include:
    - AUTH_EVENTS
    - CONFIG_CHANGE
    - POLICY_EVENTS
  sampling:
    POLICY_EVENTS: 0.1
  retentionDays:
    AUTH_EVENTS: 365
    POLICY_EVENTS: 30

Sampling POLICY_EVENTS di angka 10 persen mengendalikan volume tanpa kehilangan gambaran, sementara AUTH_EVENTS dan CONFIG_CHANGE disimpan penuh untuk kebutuhan audit dan compliance. Ingat trade-off dari episode 6: detail yang dibuang saat logging tidak bisa didapatkan lagi. Sampel yang seimbang lebih baik daripada log penuh yang berhenti dikirim karena overload.

Selain itu, pastikan sink log punya buffer dan retry. Saat sink penuh, log yang gagal dikirim sebaiknya di-drop dengan sadar daripada menggantung seluruh pipeline; dan pantau apakah sink mengejar ketertinggalan lewat metrik lag. Log yang tertunda berhari-hari nilainya mendekati nol untuk investigasi.

#Penutup

Pada episode 20, kalian men-scaling observability OpenClaw: mengendalikan cardinality metrik, membuat dashboard yang benar-benar dipakai orang, mengorelasikan policy events dengan service health lewat trace dan label bersama, membangun alert berbasis baseline, dan menjaga volume log tetap terkendali lewat sampling dan retensi bertingkat.

Inti yang harus dibawa pulang:

Cardinality adalah musuh utama metrik skala besar — kendalikan label sejak awal.
Nilai observability muncul saat metrik, trace, dan log dikorelasikan, bukan berdiri sendiri.
Alert berbasis penyimpangan dari baseline jauh lebih berguna daripada threshold statis.
Dashboard harus dibuat per audiens; dashboard raksasa tidak dibaca siapa pun.
Retensi dan sampling harus diputuskan dengan sadar: detail yang dibuang tidak bisa kembali.

Di episode 21, kalian menyiapkan tim dan prosesnya — Operational Readiness & Runbooks. Kalian akan menyusun runbook untuk insiden policy, mendefinisikan ownership dan support boundaries, serta membangun audit rutin dan compliance reviews. Sampai jumpa!