Observability
Agent-to-Agent (A2A) traffic uses the same telemetry pipelines as model traffic. Usage-event fields identify the caller, agent, method, and outcome, while Prometheus labels let you separate agent traffic from model traffic.
Use these signals to measure agent call volume and monitor failures. Rate limits, budgets, and upstream errors appear in the same observability tools you already use for model traffic.
Usage Events
AISIX emits an A2A usage event once the gateway can attribute the request to an enabled agent and caller. This includes calls rejected by unsupported upstream authentication, rate limits, budgets, or upstream failures. Malformed request bodies can be rejected before a usage event is emitted.
The event goes into the same sink as model usage and identifies the caller, agent, method, outcome, and timing:
| Field | Value |
|---|---|
inbound_protocol | a2a |
a2a_agent_name | The registered agent that was called. |
a2a_method | The JSON-RPC method invoked, such as message/send, when AISIX can read it from the request body. |
api_key_id | The caller API key that made the call. |
status_code | The call's outcome status. |
latency_ms | End-to-end call latency. |
request_id, occurred_at | Correlation id and timestamp. |
A2A calls do not carry model tokens, so token and cost fields remain zero. Use a2a_agent_name and a2a_method for per-agent call-volume attribution rather than token or spend analytics.
The event does not include request or response message content. It also does not currently expose task identifiers, such as task id and context id, or task state as separate fields.
A2A usage events follow the same delivery paths as model usage events. In managed deployments, they flow to the same usage sink as model traffic. They also fan out to any configured OTLP, SLS, or Datadog exporters, so A2A traffic appears alongside the rest of your gateway traffic.
Metrics
A2A requests appear in the gateway's Prometheus metrics with labels that distinguish them from model traffic. Use the labels below to filter the relevant metric series:
| Goal | Metric | Filter |
|---|---|---|
| Count A2A requests by outcome. | aisix_requests_total | provider="a2a" and model="a2a" |
| Track active A2A requests. | aisix_proxy_in_flight_requests | endpoint="/a2a" and inbound_protocol="a2a" |
| Check A2A usage-event emission. | aisix_usage_events_emitted_total | handler="a2a" |
For usage-event emission, filter by handler. The emission counter keeps its protocol label bounded and groups A2A events under other.
This label behavior applies only to the Prometheus emission counter. The delivered usage event still identifies the traffic as A2A and includes the agent name and method.
Metrics are exposed on GET /metrics through the dedicated metrics listener. For the full metric catalog and label semantics, see Metrics Reference.
Verify Metrics
To verify that A2A metrics are emitted, send one A2A call through the gateway, then scrape the dedicated metrics listener. The example below uses the default listener address and path. If your startup configuration sets a different observability.metrics.prometheus.addr, use that address instead.
Metric families register on first observation, so the A2A series appears only after a call is recorded:
curl -sS "http://127.0.0.1:9090/metrics" | grep -E 'handler="a2a"|provider="a2a"'
The output should include both metric samples:
| Metric | Label |
|---|---|
aisix_usage_events_emitted_total | handler="a2a" |
aisix_requests_total | provider="a2a" |
Next Steps
You now know where A2A calls appear in usage events and metrics. Use these guides to review the full metric catalog or adjust the traffic that produces those signals:
- Metrics Reference: review the full metric catalog and label semantics.
- Rate limits and budgets: apply request limits, concurrency limits, and budgets to A2A calls.
- Control agent access: scope caller API keys to specific agents or every agent.