Is your feature request related to a problem? Please describe.
In our company, we are piloting the Agent Development Kit to run AI agents entirely on-prem (inside an air-gapped Google Distributed Cloud rack).
While opentelemetry-api and opentelemetry-sdk are part of ADK’s dependencies, the current documentation only explains how telemetry is emitted when agents run on Vertex AI Agent Engine. There is no guidance or helper for configuring OTLP exporters when we deploy agents on our own Kubernetes cluster.
Describe the solution you’d like
- A simple
telemetry config block (or CLI flags) that lets us specify:
- OTLP endpoint / headers
- Service name / version
- Sampling strategy
- Optional automatic instrumentation for:
- LLM requests (
trace_call_llm)
- Tool invocations (
trace_tool_call)
- Agent-to-agent (A2A) messaging
- Docs + example showing how to push traces to an on-prem collector (Jaeger, Tempo, GCP Ops Agent in hybrid mode, etc.).
Describe alternatives you’ve considered
- Manually initialising the OTEL SDK in our
main.py and decorating each callback.
Works, but duplicates boilerplate and misses deeper internals (e.g. planner traces).
- Exporting logs only – doesn’t give us span correlation across micro-services.
Additional context
We already have an OpenTelemetry collector running inside our data-centre; exposing ADK spans would let us view agent reasoning latency alongside the rest of our CI/CD traces.
Thanks for considering!
Is your feature request related to a problem? Please describe.
In our company, we are piloting the Agent Development Kit to run AI agents entirely on-prem (inside an air-gapped Google Distributed Cloud rack).
While
opentelemetry-apiandopentelemetry-sdkare part of ADK’s dependencies, the current documentation only explains how telemetry is emitted when agents run on Vertex AI Agent Engine. There is no guidance or helper for configuring OTLP exporters when we deploy agents on our own Kubernetes cluster.Describe the solution you’d like
telemetryconfig block (or CLI flags) that lets us specify:trace_call_llm)trace_tool_call)Describe alternatives you’ve considered
main.pyand decorating each callback.Works, but duplicates boilerplate and misses deeper internals (e.g. planner traces).
Additional context
We already have an OpenTelemetry collector running inside our data-centre; exposing ADK spans would let us view agent reasoning latency alongside the rest of our CI/CD traces.
Thanks for considering!