OpenLLMetry: open-source OpenTelemetry instrumentation for LLM apps

OpenLLMetry is the open-source instrumentation layer that turns calls to models, vector databases and agent frameworks into standard OpenTelemetry spans. Traceloop builds it, but it is deliberately not tied to Traceloop: the same spans go to Langfuse, Phoenix, Datadog, Grafana or any OTLP endpoint. The Python packages are at 0.62.4 (29 September 2026).

OpenLLMetry has two parts:

• Instrumentation packages. One standard OpenTelemetry instrumentation per library, named opentelemetry-instrumentation-<library>. Python covers the LLM providers OpenAI and Azure OpenAI, Anthropic, Bedrock, Vertex AI, Gemini, Cohere, Mistral, Groq, Ollama, Together, Replicate, SageMaker, watsonx, Hugging Face, Aleph Alpha and WRITER; the vector databases Chroma, LanceDB, Marqo, Milvus, Pinecone, Qdrant and Weaviate; the frameworks LangChain, LangGraph, LlamaIndex, Haystack, CrewAI, Agno, the OpenAI Agents SDK, LiteLLM and Langflow; and MCP.
• The SDK (traceloop-sdk). Traceloop.init() sets up an OpenTelemetry tracer provider and exporter, detects which of those libraries you have installed and instruments them, and adds decorators for your own workflows, tasks, agents and tools.

In the stack it is the instrumentation at the bottom of the observability pipeline. It produces the data; a collector moves and filters it; a backend stores and shows it.

The README lists tested destinations including Traceloop, Datadog, Dynatrace, Grafana, Honeycomb, New Relic, Splunk, SigNoz, Sentry, Google Cloud, Azure Application Insights, IBM Instana, Laminar, Braintrust and any OpenTelemetry Collector. Langfuse and Arize Phoenix accept the same OTLP traffic.

OpenLLMetry is Apache-2.0. ServiceNow completed its acquisition of Traceloop in 2026, and Traceloop's announcement says OpenLLMetry will remain open source and that the team will keep contributing to OpenTelemetry. Python releases continue, with every package in the monorepo sharing one version number. The JavaScript project (@traceloop/node-server-sdk, 0.27.0) has released less often since mid-2026, and the Go and Ruby SDKs are marked beta.

Pick OpenLLMetry when:

• You want instrumentation you will not have to redo when you change backends. Changing the exporter endpoint is the whole migration.
• You already run OpenTelemetry for your services and want LLM calls in the same traces, next to your HTTP and database spans.
• You need coverage beyond model calls: vector database queries, framework steps and MCP tool calls, all auto-instrumented.
• You evaluate two backends side by side. A collector can fan the same spans out to both.

Look elsewhere when:

• Arize Phoenix is your main backend. Phoenix gives OpenInference spans its full UI; use OpenInference instrumentors there.
• You want strictly the newest official GenAI attribute names on every span today. The official OpenTelemetry GenAI instrumentations track the draft conventions most closely; OpenLLMetry is still moving some packages from older names.
• Your stack is mostly TypeScript and you need fast fixes for new provider features. Check the JavaScript release cadence first.
• A framework already emits its own OpenTelemetry spans. Adding OpenLLMetry on top doubles every span and token count.

OpenLLMetry and the OpenTelemetry GenAI conventions. Traceloop's docs say its LLM conventions became part of OpenTelemetry and that Traceloop led the working group that standardized them. The official conventions now live in their own repository, open-telemetry/semantic-conventions-genai, at Development status, so names can still change. OpenLLMetry emits gen_ai.* attributes, adds traceloop.* attributes for workflow structure, and is migrating its instrumentations to the official attribute set: its conventions package still carries aliases for older names such as gen_ai.prompt, gen_ai.completion and gen_ai.usage.prompt_tokens. Check which names your backend reads before you build dashboards on them.

Traceloop.init() builds a tracer provider with a batch span processor and an exporter. The endpoint comes from api_endpoint or TRACELOOP_BASE_URL and defaults to https://api.traceloop.com. An endpoint starting with http or https uses OTLP over HTTP, anything else gRPC, and /v1/traces is always appended, the same way OTEL_EXPORTER_OTLP_ENDPOINT works. TRACELOOP_API_KEY is sent as a bearer token; TRACELOOP_HEADERS (comma-separated key=value pairs, spaces as %20) replaces it for backends with other auth schemes.

The instrumentations wrap each library's client methods. A chat completion becomes a span with the provider, model, token usage, latency and, by default, the prompt and completion text. Your own code gets structure from four decorators in traceloop.sdk.decorators: @workflow for a top-level flow, @task for a step, @agent and @tool for agent code. Each sets traceloop.span.kind and names the span. Traceloop.set_association_properties({"user_id": ..., "chat_id": ...}) attaches your own IDs to the trace so you can filter by user or conversation.

You can skip the SDK entirely. Install only the instrumentation packages you need, configure your own OpenTelemetry tracer provider, then call OpenAIInstrumentor().instrument() and its siblings. You keep full control of exporters, samplers and processors.