Belajar OpenClaw - Observability Essentials

#Pendahuluan

Di episode 6 kalian sudah memperkuat keamanan: mTLS aktif, policy service-to-service berjalan, dan audit trail mencatat semuanya. Tapi ada satu masalah — kalian percaya policy itu bekerja, tapi belum bisa membuktikannya. Berapa banyak request yang ditolak policy payment-access-policy? Service mana yang paling sering di-block? Jawaban pertanyaan-pertanyaan itu ada di ranah observability.

Episode ini adalah jendela pengamatan OpenClaw. Roadmap-nya: pertama kita kenali jenis metrics dan logs yang dihasilkan OpenClaw, kedua integrasikan dengan Prometheus untuk penyimpanan metrik, ketiga bangun dashboard Grafana untuk visualisasi, dan terakhir kita bedah cara memvisualisasikan policy hits dan traffic flows sebagai bahan pengambilan keputusan.

#Metrics dan Logs OpenClaw

#Empat Jenis Telemetri

OpenClaw menghasilkan telemetri yang bisa dikelompokkan menjadi empat kategori: metrics berupa angka kumulatif seperti jumlah request dan latency; logs berupa peristiwa diskrit seperti keputusan policy; traces yang mengikuti perjalanan satu request melintasi service; dan access logs yang mencatat detail tiap request masuk dan keluar. Keempatnya saling melengkapi — metrics untuk tren, logs untuk detail, traces untuk jejak.

Untuk saat ini kita fokus pada dua yang paling mendasar: metrics dan logs. Keduanya paling mudah dipasang dan paling cepat memberikan nilai. Contoh metrik penting yang selalu layak dipantau:

openclawctl telemetry metrics list
openclawctl telemetry logs tail --follow --since 1h

Dari output perintah pertama kalian akan melihat nama-nama metrik seperti openclaw_policy_eval_total, openclaw_policy_deny_total, openclaw_mtls_handshake_failures, dan openclaw_http_request_duration_seconds. Metrik inilah bahan baku untuk semua analisis kita nanti.

#Kontrol Kartinalitas

Satu hal yang wajib kalian pahami sejak awal: label metrik itu kuat tapi berbahaya. Setiap kombinasi label baru (namespace, policy name, source, destination) membuat Prometheus harus menyimpan rangkaian data terpisah. Kalau label dipakai tanpa kontrol, jumlah rangkaian metrik bisa meledak — kondisi yang disebut high cardinality — dan itu akan membebani Prometheus serta memperlambat query.

apiVersion: openclaw.io/v1
kind: TelemetryConfig
metadata:
  name: cluster-telemetry
spec:
  metrics:
    enabled: true
    labels:
      - namespace
      - policyName
      - result
    excludedLabels:
      - clientIp
      - userAgent
  accessLogging:
    mode: LOG
    sampleRate: 100

Dengan membatasi label ke namespace, policyName, dan result, kalian menolak label berkarakter unik seperti clientIp dan userAgent yang kartinalitasnya tak terbatas. Ini keputusan desain yang menyelamatkan infrastructure observability kalian di produksi.

#Integrasi dengan Prometheus

#Menyiapkan Endpoint Scraping

Prometheus bekerja dengan pola pull: ia menjemput metrik dari endpoint /metrics yang dibuka oleh OpenClaw. Jadi yang kalian butuhkan adalah memastikan endpoint tersebut aktif dan memberi tahu Prometheus alamatnya. Jika memakai kube-prometheus-stack, kalian cukup menambahkan ServiceMonitor — objek yang memberi tahu Prometheus apa yang harus di-scrape.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: openclaw-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: openclaw
  endpoints:
    - port: metrics
      interval: 30s
      path: /metrics

Setelah ServiceMonitor diterapkan, Prometheus otomatis mulai menarik metrik setiap 30 detik. Verifikasi lewat kubectl port-forward -n openclaw svc/openclaw-metrics 9090:9090 dan buka query UI Prometheus, atau langsung cek dengan perintah berikut:

kubectl get servicemonitor -n monitoring
kubectl port-forward -n openclaw svc/openclaw-metrics 9090:9090

Jika semua sehat, kalian bisa menjalankan query PromQL pertama: rate(openclaw_policy_deny_total[5m]) untuk melihat deny rate per menit. Ini query dasar yang akan sering kalian pakai.

#Dashboard Grafana

#Template Dashboard OpenClaw

Metrik yang tersimpan di Prometheus belum terasa gunanya sampai divisualisasikan. Di sinilah Grafana berperan sebagai papan pemantau. OpenClaw menyediakan template dashboard yang bisa diimpor langsung ke Grafana — biasanya berupa file JSON yang berisi panel-panel siap pakai. Kalian cukup impor melalui menu Dashboards lalu Import, atau lewat provisioning file.

apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-datasource
  namespace: monitoring
  labels:
    grafana_datasource: "1"
data:
  datasource.yaml: |
    apiVersion: 1
    datasources:
      - name: Prometheus
        type: prometheus
        url: http://prometheus-operated.monitoring:9090
        access: proxy
        isDefault: true

#Panel yang Wajib Ada

Dashboard yang baik tidak menampilkan semua hal — ia menampilkan hal yang penting. Setidaknya ada empat panel yang harus ada di dashboard OpenClaw kalian: total policy evaluations per detik, deny rate per policy, mTLS handshake failure (indikasi masalah sertifikat), dan request duration histogram untuk latency p95. Keempatnya menjawab pertanyaan operasional sehari-hari: apakah policy membebani, dan apakah ada yang aneh di jaringan.

# Deny rate per policy
sum(rate(openclaw_policy_deny_total{namespace="billing"}[5m])) by (policyName)
 
# Latency p95 request yang diizinkan
histogram_quantile(0.95,
  sum(rate(openclaw_http_request_duration_seconds_bucket[5m])) by (le))

Dua query PromQL di atas adalah titik awal yang solid. Panel pertama menunjukkan deny per policy sehingga kalian langsung tahu policy mana yang paling banyak menolak; panel kedua memberi tahu seberapa cepat request diizinkan berjalan.

#Memvisualisasikan Policy Hits dan Traffic Flows

#Dashboard Policy Hits

Policy hits adalah hitungan berapa kali sebuah policy dievaluasi dan apa hasilnya — ALLOW, DENY, atau SKIP. Memvisualisasikannya sebagai grafik batang bertumpuk per policy memungkinkan kalian melihat beban tiap policy sekaligus anomali: tiba-tiba sebuah policy melonjak deny count-nya? Itu bisa berarti serangan, bisa juga berarti bug pada aplikasi.

sum(rate(openclaw_policy_eval_total[5m])) by (policyName, result)

Query ini menghasilkan rangkaian per kombinasi policy dan hasil evaluasi. Gabungkan dengan label selector namespace untuk memperkecil lingkup: {namespace="billing"}. Dari situ kalian bisa membuat panel time series untuk melihat deny rate naik turun sepanjang hari.

#Visualisasi Traffic Flows

Metrik bisa memberi tahu ada masalah, tapi belum tentu memberi tahu di mana. Untuk itu kalian perlu melihat traffic flows — siapa berbicara dengan siapa, lewat port apa, dan dengan hasil apa. Grafana bisa memvisualisasikan ini sebagai grafik hubungan (node graph): setiap service menjadi node, dan setiap garis antar node mewakili traffic dengan ketebalan sesuai volume.

openclawctl observability flows --namespace billing --output json

Output perintah di atas berisi daftar pasangan source-destination beserta volume dan statusnya. Data yang sama bisa diumpankan ke panel node graph Grafana. Dengan satu pandangan, kalian langsung melihat service mana yang paling banyak bicara, dan apakah ada jalur traffic yang seharusnya tidak ada — misalnya billing yang tiba-tiba mengakses storage service padahal tidak ada policy yang mengizinkannya.

#Penutup

Pada episode 7 ini kalian telah membuka mata OpenClaw: mengenali empat jenis telemetri dengan fokus pada metrics dan logs, mengontrol kartinalitas label agar tidak menghancurkan Prometheus, mengintegrasikan ServiceMonitor untuk scraping, membangun dashboard Grafana dari template hingga panel custom, dan memvisualisasikan policy hits serta traffic flows untuk deteksi anomali.

Inti yang harus dibawa pulang:

• Metrics, logs, traces, dan access logs saling melengkapi; mulailah dari metrics dan logs.
• Jaga kartinalitas label — jangan pernah memasukkan label berkarakter unik seperti IP klien ke dalam metrik.
• ServiceMonitor adalah jembatan OpenClaw ke Prometheus; pastikan endpoint /metrics selalu bisa di-scrape.
• Dashboard wajib berisi policy evaluations, deny rate, mTLS failure, dan latency p95.
• Traffic flow graph membantu menemukan jalur komunikasi yang mencurigakan yang tidak terlihat dari angka agregat.

Di episode 8 selanjutnya kita masuk Fase 3 — advanced policy authoring. Kalian akan menulis policy template yang bisa dipakai ulang, membuat parameterized rules dengan policy inheritance, serta memakai conditionals dan service labels dalam rule. Sampai jumpa!