Belajar Hermes AI Agent - Observability at Scale
Episode 20 of 23

Belajar Hermes AI Agent - Observability at Scale

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.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

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:

  • Menentukan metrik keberhasilan: task completion, error rate, latency.
  • Membangun dashboard untuk aktivitas agent dan tool usage.
  • Alert untuk failed actions dan perilaku anomali.
  • Menghubungkan semua dengan tracing dan korelasi.

Metrik Keberhasilan yang Sesungguhnya

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:

MetrikApa yang sebenarnya diukurIndikator masalah
Task completionPersentase tugas selesai dalam batas langkah, dinilai dari hasil akhirAgend rutin gagal menuntaskan tugas
Error rateProporsi percakapan yang berakhir error, escalation, atau timeoutModel menurun, tool berubah, prompt regresi
LatencyWaktu dari input sampai output final, termasuk waktu panggilan toolTool 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:

ts
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".

Dashboard untuk Aktivitas Agent dan Tool Usage

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.

prometheus.yml
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:

  • Task completion rate per profile — agent mana yang paling sering gagal.
  • Error rate per tool — tool mana yang paling sering bermasalah.
  • Latency breakdown per fase — apakah lambat di model, di tool, atau di refleksi.
  • Top tool usage — tool mana yang paling sering dipanggil, dan apakah ada tool yang hampir tidak dipakai (kemungkinan konfigurasi salah).
  • Confidence distribution — apakah agen makin sering menjawab dengan keyakinan rendah.

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).

Alert untuk Failed Actions dan Perilaku Anomali

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.

alert-rules.yml
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: warning

Aturan 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.

Tracing dan Korelasi Antar Layanan

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.

lihat-trace-percakapan.sh
hermes log stream --trace-id conv_8f3a --format json

Trace 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.

Penutup

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:

  • Task completion adalah metrik paling khas agent — ukur hasil akhir, bukan sekadar status request.
  • Beri label pada metrik supaya masalah bisa dilacak sampai ke kategori.
  • Maksimal tiga dashboard: executive, on-call, dan engineering.
  • Alert harus seimbang: terlalu sensitif membuat tim buta, terlalu longgar membuat sistem rentan.
  • Trace ID harus menembus seluruh percakapan dan layanan yang dipanggil.

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!

Belajar Hermes AI Agent - Observability at Scale | Belajar Hermes AI Agent