Skip to main content
Where metrics give aggregate counters, telemetry emits one structured event per request, off the critical path, to Kafka. Each event captures everything needed to analyze cost, latency, routing, and policy decisions.

Configuration

Telemetry is configured globally by environment and refined per gateway.
VariableDefaultMeaning
TELEMETRY_ENABLEDtrueToggle telemetry.
TELEMETRY_KAFKA_TOPICagentgateway.requestsDestination topic.
TELEMETRY_ENABLE_REQUEST_TRACEStrueInclude request traces.
TELEMETRY_ENABLE_PLUGIN_TRACEStrueInclude per-policy traces.
TELEMETRY_TRUSTLENS_ENABLEDfalseForward to TrustLens.
TELEMETRY_TRUSTLENS_URLTrustLens endpoint.
Per gateway, telemetry can define its own exporters ({ name: "kafka", settings: { host, port, topic } }), static extra_params appended to every event, trace toggles, and a header_mapping that copies inbound headers into event fields.

The event

Events are versioned (schema_version) and include, among others:
GroupFields
Identitytrace_id, gateway_id, team_id, consumer, session_id, turn_id, ip.
Requestmethod, path, provider, registry id, requested vs resolved model, temperature, max tokens, stream flag, prompt tokens.
Responsestatus code, latency, completion tokens, finish reason, streaming.
Usageprompt / completion / total tokens, cached input, reasoning output.
Costprompt / completion / total USD.
Latencytotal, provider, policies, routing, gateway (ms).
Attemptsper-registry attempts with fallback/pinned/route/outcome.
Policy chainper-policy decision, stage, latency, score, flagged.

Using the stream

Point any Kafka consumer at the topic to build dashboards, billing, or anomaly detection; or enable the TrustLens integration to forward events to NeuralTrust’s analytics. The attempts and policy_chain arrays make it possible to reconstruct exactly how each request was routed and which policies fired.