Episode ini membawa observability agent ke skala production: menentukan metrik keberhasilan seperti task completion, error rate, dan latency; membangun dashboard untuk aktivitas agent dan penggunaan tool; serta memasang alert untuk tindakan gagal dan perilaku anomali.

Episode 19 mengajari kalian cara merilis agent dengan pipeline yang aman: bisa diuji, bisa di-rollback. Tapi pipeline yang aman tidak berguna jika tidak ada yang tahu apakah agent yang sudah rilis itu bekerja dengan baik di lapangan. Logging di episode 7 masih cukup untuk satu agent; untuk banyak agent yang melayani ribuan percakapan, kalian butuh observability di skala penuh.
Episode 20 membahas tiga pilar observability production: metrik yang menjawab "apakah agent sukses", dashboard yang menampilkan aktivitas dan penggunaan tool secara real-time, serta alert yang menandakan kegagalan dan perilaku anomali sebelum menjadi insiden besar. Peta jalan episode ini:
Kebanyakan aplikasi diukur dengan uptime dan status code HTTP. Agent tidak bisa diukur seperti itu — sebuah request bisa sukses secara teknis tapi menjawab dengan informasi yang salah. Karena itu, tiga metrik inti untuk agent harus dipahami berbeda dari aplikasi biasa:
| Metrik | Apa yang sebenarnya diukur | Indikator masalah |
|---|---|---|
| Task completion | Persentase tugas selesai dalam batas langkah, dinilai dari hasil akhir | Agend rutin gagal menuntaskan tugas |
| Error rate | Proporsi percakapan yang berakhir error, escalation, atau timeout | Model menurun, tool berubah, prompt regresi |
| Latency | Waktu dari input sampai output final, termasuk waktu panggilan tool | Tool lambat, model membengkak, loop refleksi tak terkendali |
Task completion adalah metrik yang paling membedakan agent dari aplikasi lain. Untuk mengukurnya, agent perlu menandai percakapannya sendiri dengan status hasil akhir, lalu menyimpannya bersama telemetry:
import { metrics } from "@hermes/telemetry";
await agent.run(input, {
onComplete(result) {
metrics.histogram("agent.latency_ms", result.latencyMs);
metrics.increment("agent.tasks_total", { outcome: result.outcome });
metrics.observeConfidence(result.confidence);
},
});Perhatikan pola metrik di atas: selalu beri label pada metrik (outcome, confidence) supaya dashboard bisa dipecah-pecah per kategori. Metrik tanpa label hanya memberi tahu "ada yang salah"; metrik berlabel memberi tahu "di mana yang salah".
Metrik mentah tidak berguna sampai divisualisasikan. Dashboard yang baik untuk agent punya dua lapis: lapisan ringkasan untuk tim operasional, dan lapisan detail untuk debugging. Untuk dashboard, Hermes mengekspor metrik dalam format Prometheus, yang bisa langsung dikonsumsi oleh Grafana atau stack observability favorit kalian.
scrape_configs:
- job_name: hermes-agents
metrics_path: /metrics
static_configs:
- targets: ["agent-api:9100"]Di Grafana, susun panel yang menjawab pertanyaan bisnis, bukan sekadar menampilkan grafik:
Satu dashboard untuk semua hal adalah resep kegagalan. Buat paling banyak tiga dashboard: satu untuk executive (ringkasan), satu untuk on-call (alert aktif), satu untuk engineering (detail trace).
Dashboard hanya berguna jika ada yang menontonnya. Di malam hari, tidak ada yang menonton — maka kalian butuh alert yang bekerja tanpa lelah. Ada dua kelas alert untuk agent: alert reaktif untuk kegagalan, dan alert proaktif untuk anomali yang belum menjadi kegagalan.
groups:
- name: agent-health
rules:
- alert: HighErrorRate
expr: rate(agent_errors_total[5m]) > 0.2
for: 10m
labels:
severity: page
- alert: ToolLatencySpike
expr: histogram_quantile(0.95, rate(agent_tool_latency_seconds_bucket[5m])) > 5
for: 5m
labels:
severity: warning
- alert: ConfidenceDrop
expr: avg(agent_confidence{phase="final"}) < 0.5
for: 30m
labels:
severity: warningAturan di atas menerjemahkan tiga sinyal yang sudah kita bahas: error rate yang tinggi, latency tool yang membengkak, dan kepercayaan diri yang anjlok. Untuk alert yang proaktif, pasang juga deteksi anomali sederhana: bandingkan metrik saat ini dengan baseline minggu lalu, lalu alert jika menyimpang beberapa standar deviasi — misalnya jumlah escalation tiba-tiba naik dua kali lipat, atau pola penggunaan tool berubah drastis tanpa rilis apa pun.
Warning
Alert yang terlalu sensitif akan dinonaktifkan oleh tim yang lelah, lalu seluruh sistem buta. Mulailah dengan ambang longgar dan page yang jarang, lalu keraskan seiring waktu. Alert yang baik adalah yang tidak mengganggu — sampai benar-benar dibutuhkan.
Metrik memberi tahu bahwa ada masalah, dashboard memberi tahu apa yang bermasalah, tapi untuk menemukan mengapa, kalian butuh tracing. Setiap percakapan agent harus punya trace ID yang mengikuti seluruh perjalanannya: dari input, perencanaan, tiap panggilan tool, refleksi, sampai output final.
hermes log stream --trace-id conv_8f3a --format jsonTrace ID ini juga harus muncul di log aplikasi lain yang dipanggil agent — kalau tidak, tidak mungkin menghubungkan keluhan pengguna dengan langkah tool yang salah. Dengan trace, penyelidikan insiden berubah dari "tonton dashboard" menjadi "ikuti jejak percakapan": langkah mana yang menghasilkan jawaban salah, tool mana yang mengembalikan data aneh, dan di fase mana agen memutuskan sesuatu yang keliru. Ini persis bekal yang kalian butuhkan untuk episode berikutnya tentang Ops & Governance.
Episode 20 membangun fondasi observability skala production: metrik keberhasilan yang membedakan sukses teknis dari sukses fungsional, dashboard berlapis yang menjawab pertanyaan berbeda di setiap level, alert reaktif dan proaktif yang menjaga malam, serta tracing yang menghubungkan semuanya menjadi satu cerita utuh per percakapan.
Inti yang harus dibawa pulang:
Di episode 21 berikutnya kita akan memakai semua sinyal observability ini untuk menjalankan operasi sehari-hari: playbook insiden, rollback dan safe mode, kebijakan governance untuk penggunaan agent, serta dokumentasi praktik responsible AI. Sampai jumpa!