Belajar OpenClaw - Network Observability & Forensics

#Pendahuluan

Di episode 13 kalian membangun pertahanan: rate limit, traffic shaping, blocklist, dan alerting. Tapi setelah serangan tertahan, pekerjaan sebenarnya baru mulai — pertanyaan yang harus dijawab: siapa yang menyerang, kapan mulai, lewat jalur mana, dan apakah ada data yang sempat keluar? Jawaban itu ada di data, dan OpenClaw menyimpannya.

Episode 14 masuk ranah penyelidikan: visibilitas aliran paket dan audit log sebagai sumber kebenaran, tahapan investigasi insiden dengan log OpenClaw, serta penggabungan metrics, traces, dan logs untuk melihat insiden secara utuh, bukan potongan-potongan.

#Visibilitas Aliran Paket

Sebelum bertanya "kenapa service down", kalian harus bisa menjawab "apa yang sebenarnya terjadi di jaringan". OpenClaw merekam aliran paket — siapa bicara dengan siapa, protokol apa, berapa byte, berapa lama koneksi — dalam bentuk flow logs. Satu log aliran mewakili satu percakapan antar dua endpoint:

{
  "ts": "2026-08-03T10:41:12.000Z",
  "src": "10.244.3.21:53124",
  "dst": "10.244.1.8:443",
  "service": "web-store",
  "proto": "tcp",
  "action": "allow",
  "bytes_sent": 4821,
  "bytes_recv": 120934,
  "duration_ms": 342
}

Flow logs menjawab pertanyaan konektivitas — koneksi terbentuk atau tidak, lewat port mana, seberapa besar — tanpa menyimpan payload. Aktifkan pencatatan aliran per namespace atau per service, dan pastikan throughput log dihitung agar buffer tidak meledak saat serangan:

apiVersion: openclaw.io/v1
kind: FlowLogConfig
metadata:
  name: core-traffic
  namespace: openclaw-system
spec:
  namespaceSelector:
    matchLabels:
      tier: core
  samplingRate: 1.0
  capture:
    - connection_start
    - connection_end
    - policy_hit
  sink:
    endpoint: http://loki-observability:3100

samplingRate: 1.0 berarti semua koneksi dicatat — angka yang pantas untuk namespace kritis. Untuk traffic besar, sampling 0.1 atau 0.01 menjaga biaya tetap wajar sambil tetap memberi gambaran pola.

#Audit Log sebagai Sumber Kebenaran

Berbeda dengan flow log yang mencatat fakta jaringan, audit log mencatat keputusan: request mana yang ditolak policy, siapa yang coba mengakses service tanpa izin, policy mana yang berubah dan oleh siapa. Audit log bersifat append-only — tidak bisa diubah setelah ditulis — sehingga bisa dijadikan bukti.

Setiap entri audit membawa identitas, aksi, resource, dan keputusan:

{
  "id": "a-9182-k3l",
  "ts": "2026-08-03T10:41:12.000Z",
  "actor": {
    "type": "apiKey",
    "name": "ci-pipeline"
  },
  "action": "policy.create",
  "resource": "policies/deny-admin-egress",
  "decision": "allow",
  "traceId": "t-55fc-11ab",
  "cluster": "prod-eks"
}

Apa yang harus selalu direkam: siapa aktornya (actor), aksi apa (action), objek apa yang disentuh (resource), dan hasilnya (decision). Dengan traceId, entri ini bisa disambungkan ke trace request di hulu — jembatan menuju investigasi lintas sistem yang akan kita bahas di bagian akhir.

#Investigasi Insiden dengan Log OpenClaw

Saat alert DDoS berbunyi, alur investigasi yang disiplin menekan waktu pemulihan. Buka dengan pertanyaan besar: kapan anomali dimulai? Cari pola deny di flow log dengan openclaw logs flow --since 6h:

openclaw logs flow --since 6h \
  --filter 'action=deny' \
  --sort bytes_sent
openclaw audit query --since 6h \
  --filter 'decision=deny' \
  --top actor

#Rekonstruksi Timeline

Setelah menemukan waktu mulai, rekonstruksi urutan kejadian. Gabungkan flow log, audit log, dan metrik reject untuk membangun garis waktu: kapan rate limit mulai menolak, kapan blocklist aktif, dan kapan service kembali normal. Timeline ini menjadi kerangka laporan insiden.

#Identifikasi Pelaku dan Pola

Dari baris yang paling sering muncul di --top actor, klasifikasikan pelaku: apakah satu API key bocor, sekelompok IP dari satu region, atau serangan terdistribusi dari ribuan IP. Perhatikan pola temporal — misalnya deny yang hanya muncul di jam kerja negara tertentu — sebelum memutuskan blok permanen:

openclaw audit query --since 24h \
  --group-by srcIp,userAgent \
  --filter 'decision=deny' \
  --limit 20

#Menggabungkan Metrics, Traces, dan Logs

Flow log dan audit log saja belum lengkap. Insiden nyata melibatkan aplikasi: database melambat, request timeout, memory menipis. Di sinilah tiga pilar observability digabung. Metrics menjawab apa yang terjadi (error rate naik), traces menjawab di mana (service mana yang lambat), logs menjawab mengapa (exception apa yang muncul).

Kuncinya adalah korelasi identitas — satu traceId yang sama tersebar di semua sumber. Saat request ditolak OpenClaw, gunakan trace id itu untuk menarik trace end-to-end:

openclaw trace get t-55fc-11ab
openclaw audit query --trace t-55fc-11ab

Dari situ kalian melihat: trace menunjukkan request melambat di billing karena lock database, flow log menunjukkan ribuan koneksi SYN tak terjawab, dan audit log menunjukkan policy deny-admin-egress baru saja diubah 10 menit sebelum anomali. Tiga sumber yang tadinya terpisah kini menjadi satu cerita utuh. Integrasikan metrik OpenClaw ke Prometheus dan dashboards Grafana supaya korelasi ini bisa dilakukan di satu tempat, bukan menyeberang antar tool:

openclaw metrics scrape-config
curl http://openclaw-control-plane:9091/metrics

#Penutup

Episode 14 mengubah OpenClaw dari sekadar penegak policy menjadi alat investigasi: flow log merekam fakta jaringan, audit log menyimpan keputusan yang tidak bisa dipungkiri, dan kombinasi metrics, traces, serta logs memberi gambaran insiden yang utuh. Saat incident terjadi, kalian tidak lagi menebak — kalian membaca.

Inti yang harus dibawa pulang:

• Flow log menjawab konektivitas; audit log menjawab keputusan — dua hal berbeda yang saling melengkapi.
• Audit log harus append-only dan membawa traceId agar bisa disambungkan ke sistem lain.
• Mulai investigasi dengan timeline, lalu kelompokkan deny berdasarkan sumber untuk menemukan pola.
• Gabungkan metrics, traces, dan logs lewat satu identitas bersama seperti traceId.
• Sampling membantu mengendalikan biaya observability tanpa menghilangkan gambaran besar.

Bukti sudah terkumpul, tapi bagaimana kalau insiden muncul karena OpenClaw sendiri yang lambat? Di episode 15 kita memoles mesinnya: Performance Tuning & Scalability — sizing control dan data plane, optimasi evaluasi policy, serta horizontal scaling dan konfigurasi high availability. Sampai jumpa di sana!