Belajar A2A - Observability & Auditing

#Pendahuluan

Di episode 14 kita memetakan ancaman dan merancang mitigasi. Sekarang muncul pertanyaan praktis: bagaimana kita tahu mitigasi itu bekerja? Jawabannya: observability. Jaringan multi-agent yang tidak terpantau adalah kotak hitam — kalian hanya tahu task gagal setelah user komplain.

Observability untuk A2A punya tantangan unik. Satu permintaan user bisa berubah menjadi puluhan task yang tersebar di banyak agent, di berbagai proses dan framework berbeda. Untuk melacaknya, kita butuh dua hal: tracing untuk melihat perjalanan task, dan audit log untuk merekam apa yang terjadi sebagai catatan permanen.

Roadmap episode ini: kita mulai dari alasan observability penting, lalu membangun tracing OpenTelemetry untuk task lifecycle, mempelajari korelasi task parent-child, dan merancang audit log yang memenuhi kebutuhan compliance.

#Mengapa Observability Menjadi Krusial

Bayangkan sebuah task yang dikirim orchestrator ke tiga agent: satu berhasil, satu menggantung, satu mengembalikan hasil aneh. Tanpa telemetry, menyelidikinya berarti membuka log masing-masing service satu per satu dan mencocokkan secara manual — tidak realistis di skala produksi.

Dengan tracing yang baik, kalian bisa menjawab pertanyaan seperti:

• Berapa lama sebuah task berada di state working sebelum selesai?
• Agent mana yang menjadi bottleneck saat fan-out?
• Apakah task yang lambat selalu mengikuti jalur routing yang sama?
• Di titik mana sebuah task gagal dan apa penyebabnya?

Pola khas multi-agent: sebuah task menghasilkan sub-task (task parent-child). Di episode 17 kita akan membahas pola fan-out ini lebih dalam; di episode kali ini kita siapkan alat untuk mengamatinya.

#OpenTelemetry untuk Task Lifecycle

OpenTelemetry (OTel) adalah standar observability untuk metric, logs, dan traces. Konsep intinya adalah span: satuan kerja yang memiliki nama, waktu mulai-selesai, dan atribut. Untuk A2A, kita bisa memetakan task lifecycle ke dalam span-span yang berurutan.

Pemetaan state task menjadi span:

task.submitted ─▶ task.working ─▶ task.completed
                                  └─▶ task.failed
                └─▶ task.input-required ─▶ task.working ─▶ task.completed

Instalasi SDK OTel cukup dengan pip install opentelemetry-api opentelemetry-sdk.

Contoh membuat span ketika server menerima message/send:

instrument.py — span untuk task lifecycle

from opentelemetry import trace
 
tracer = trace.get_tracer("a2a.task")
 
def handle_message_send(payload, parent_ctx=None):
    with tracer.start_as_current_span(
        "task.submitted",
        context=parent_ctx,
        attributes={
            "task.id": payload["params"]["message"]["taskId"],
            "a2a.method": "message/send",
            "peer.agent": payload["headers"].get("agent_id", "unknown"),
        },
    ) as span:
        task_id = payload["params"]["message"]["taskId"]
        result = execute_task(task_id)
        if result.ok:
            span.set_attribute("task.state", "completed")
        else:
            span.set_attribute("task.state", "failed")
            span.record_exception(result.error)
        return result

Atribut pada span menjadi kunci pencarian: task.id, a2a.method, dan peer.agent memungkinkan kalian menelusuri semua operasi yang menyentuh satu task. State transisi lain — working, input-required — dapat direpresentasikan sebagai child span atau update atribut sesuai kebutuhan.

#Korelasi Task Parent-Child

Satu permintaan user biasanya menyebar menjadi rantai task. Orchestrator mengirim task ke agent A, agent A mengirim task baru ke agent B, dan seterusnya. Agar rantai ini terlihat sebagai satu aliran, setiap agent harus meneruskan konteks trace ke agent berikutnya.

Mekanisme standarnya adalah trace context propagation melalui header HTTP traceparent. Header ini membawa trace-id, parent-span-id, dan flag sampling. Ketika client agent mengirim message/send, ia menyisipkan header traceparent dari konteks saat ini; server agent membaca header itu dan menjadikannya sebagai parent context untuk span-spannya.

Alur propagasi antar agent:

user ─▶ orchestrator ──trace-id: 4bf92f57──▶ agent-a ──trace-id: 4bf92f57──▶ agent-b
          │                                    │                              │
        span A                               span B                          span C

Contoh pengiriman dari client agent:

curl -X POST https://agent-b.example.com/ \
  -H "Content-Type: application/json" \
  -H "traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01" \
  -d '{"jsonrpc":"2.0","id":"5","method":"message/send","params":{}}'

Dengan korelasi yang benar, tools seperti Jaeger atau Grafana Tempo bisa menampilkan waterfall yang menunjukkan urutan dan durasi tiap agent dalam satu rantai — dari submit sampai complete.

#Audit Log: Apa yang Harus Dicatat

Tracing fokus pada debugging dan performa. Audit log adalah catatan permanen untuk accountability dan compliance. Perbedaannya krusial: trace boleh dibuang setelah beberapa hari, sedangkan audit log sering harus disimpan bertahun-tahun sesuai regulasi.

Setidaknya, audit log untuk A2A harus merekam:

• Identity — siapa pengirim: tenant, agent id, atau user yang memicunya.
• Aksi — method yang dipanggil (message/send, tasks/cancel, dan lain-lain).
• Task id dan status — seluruh transisi state.
• Keputusan — hasil yang dipilih agent, termasuk alasan jika ada.
• Data yang ditransfer — jumlah part, tipe part, dan ukuran data.
• Metadata trace — trace-id untuk menghubungkan audit log dengan tracing.

Contoh satu baris audit log terstruktur:

{
  "timestamp": "2026-08-03T09:12:33.102Z",
  "event": "task.completed",
  "task_id": "task-4821",
  "parent_task_id": "task-4800",
  "tenant_id": "acme-corp",
  "actor": "agent:orchestrator-prod",
  "action": "message/send",
  "status": "completed",
  "parts_count": 3,
  "bytes_transferred": 12480,
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Perhatikan parent_task_id: field ini menghubungkan audit kejadian dengan rantai task induknya, melengkapi korelasi yang dibangun di tracing.

#Implementasi Audit Trail yang Bisa Dipertanggungjawabkan

Audit log tidak cukup hanya ditulis ke stdout. Untuk benar-benar bisa dipercaya, ada beberapa syarat:

1. Append-only — catatan tidak boleh diedit atau dihapus setelah ditulis.
2. Tamper-evident — perubahan catatan harus terdeteksi, misalnya dengan rantai hash antar baris log.
3. Waktu terpercaya — timestamp harus konsisten, biasanya memakai NTP atau sumber waktu tersinkron.

Rantai hash bekerja dengan menyertakan hash dari baris sebelumnya di setiap baris baru:

audit.py — log dengan rantai hash

import hashlib, json
 
prev_hash = ""
 
def write_audit(event: dict):
    global prev_hash
    record = {
        **event,
        "prev_hash": prev_hash,
    }
    payload = json.dumps(record, sort_keys=True)
    current_hash = hashlib.sha256(payload.encode()).hexdigest()
    prev_hash = current_hash
    append_to_audit_store(json.dumps({**record, "hash": current_hash}))

Dengan cara ini, jika seseorang mengubah baris di tengah log, hash semua baris setelahnya menjadi tidak cocok dan kecurangan terlihat. Untuk data yang paling sensitif, audit log bisa ditulis ke object storage dengan mode append dan akses terbatas, atau bahkan ke sistem terpisah dari runtime agent.

#Penutup

Pada episode ini kita membangun lapisan observability untuk jaringan A2A. OpenTelemetry memetakan task lifecycle dari submit hingga complete menjadi span yang bisa ditelusuri, propagasi traceparent menghubungkan task parent-child antar agent menjadi satu rantai, dan audit log menyimpan catatan permanen tentang siapa berbuat apa dengan data apa — lengkap dengan metadata trace untuk menghubungkan keduanya.

Inti yang harus dibawa pulang:

• Span OTel memetakan setiap transisi state task dan menyimpan atribut seperti task.id dan peer.agent untuk pencarian.
• Header traceparent harus diteruskan antar agent agar rantai task terlihat sebagai satu trace.
• Audit log membedakan diri dari tracing: permanen, append-only, dan untuk compliance.
• Setiap catatan audit wajib menyertakan identity, aksi, status, dan trace-id.
• Rantai hash membuat audit log tamper-evident dan bisa dipertanggungjawabkan.

Dengan observability yang baik, kalian tahu apa yang terjadi di jaringan agent. Namun memantau tetap lebih mudah jika jumlah agent sedikit dan alamatnya sudah dikenal. Bagaimana jika agent bertambah terus dan alamatnya berubah-ubah?

Di episode 16 selanjutnya kita akan membahas Registry & Discovery Service: service registry sebagai Agent Card store, katalog agent ekosistem dengan dynamic discovery, serta pola routing untuk memilih agent berdasarkan capabilities, rating, dan latency — seperti pola latency-aware ala Twilio. Sampai jumpa!