OpenLLMetry: OpenTelemetry Instrumentation for LLM Applications
Open-source observability for your GenAI or LLM application, based on OpenTelemetry
At a glance
- What is it?
- OpenLLMetry is a set of OpenTelemetry extensions and instrumentations for LLM providers and vector databases, maintained by Traceloop. It is the right choice when you already run an OTLP pipeline and want LLM spans to land in it, and the wrong choice when you want a self-contained tracing UI.
- Who is it for?
- Adopt OpenLLMetry if you already run an OpenTelemetry collector or a backend that speaks OTLP and you want LLM spans in the same pipeline as your service traces. Do not adopt it if you want a tracing UI, evaluation runs or prompt management in the same install: the README describes instrumentation and export, not a product.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What OpenLLMetry Adds on Top of OpenTelemetry
The README is explicit about the framing: OpenLLMetry is a set of extensions built on top of OpenTelemetry, and the repository holds standard OpenTelemetry instrumentations for LLM providers and vector DBs. That distinction matters more than it looks. This is not a new tracing system with its own agent, protocol and storage. It produces OpenTelemetry spans, which means the destination problem is already solved if you have one.
The audience is narrow and identifiable. You have a Python service that calls OpenAI, Anthropic, Bedrock or another provider, and you already ship traces somewhere over OTLP. Without instrumentation, those calls are invisible: the HTTP client span may exist, but the prompt, the completion, the model name and the token accounting are not attached to anything. OpenLLMetry fills that gap. The README also notes that if you already have OpenTelemetry instrumented, you can add any of the instrumentations directly rather than adopting the SDK.
That second path is the one experienced teams tend to take. The SDK is a convenience wrapper; the instrumentations are the substance. If you have an existing TracerProvider configured with your own resource attributes, sampler and exporter, pulling in a provider-specific instrumentation package keeps your setup intact. Taking the SDK means accepting its initialization defaults, which the README shows as a single call with no arguments.
How Spans Flow from Provider Call to Your Backend
The data flow described in the README is short. Your code calls a provider SDK. An instrumentation package wraps that call and emits spans using the OpenTelemetry API. Those spans go to whatever exporter your TracerProvider is configured with, which in the SDK case is set up by Traceloop.init(). The README states that the output is standard OpenTelemetry data that can be connected to your observability stack.
Two consequences follow. First, the exporter is not a lock-in point. The README lists a long set of supported destinations, including Traceloop itself, Datadog, Honeycomb, Grafana, Dynatrace, New Relic, SigNoz, Splunk, Azure Application Insights, Google Cloud, Oracle Cloud, Tencent Cloud, Sentry and a plain OpenTelemetry Collector. The list is described as supported and tested, with per-destination instructions in the docs. Second, sampling, retention and cost control are your problem, not the project's. Nothing in the README suggests OpenLLMetry filters or summarizes spans before export.
The README also notes that the project's semantic conventions are now part of OpenTelemetry, with a link to the community discussion. That is a meaningful signal about where the attribute names are heading, but it also means attribute naming is a moving target across versions. If you build dashboards against specific span attributes, pin your version and read the changelog before upgrading.
Installing OpenLLMetry and Sending a First Trace
The README gives the shortest possible path. Install the SDK with pip, then call Traceloop.init() before the code you want traced. The documentation states that this is enough to start tracing.
pip install traceloop-sdkThen, in your application entry point, initialize before any provider client is constructed. The README shows exactly this pair of lines.
from traceloop.sdk import Traceloop
Traceloop.init()If you are running locally and want to see spans as they happen rather than in batches, the README gives an explicit option for that. This is the setting you want while you are confirming that instrumentation is working at all.
Traceloop.init(disable_batch=True)The README does not document the environment variables that Traceloop.init() reads, the default endpoint it exports to, or what happens when no endpoint is configured. Those details live in the linked getting-started page rather than the repository README. Read that page before you run this in anything but a scratch environment, because a default exporter pointed at a hosted service is a decision you want to make deliberately, not by omission.
The alternative path the README describes is to skip the SDK entirely and add individual instrumentations to an existing OpenTelemetry setup. In that case you configure your own exporter and the instrumentations attach to your provider. The README does not spell out that configuration, so treat the SDK route as the documented one and the direct-instrumentation route as the one you reconstruct from the OpenTelemetry Python documentation.
Where OpenLLMetry Is the Wrong Tool
OpenLLMetry instruments and exports. It does not store, query or display anything on its own. If you install traceloop-sdk expecting a local UI where you can click into a trace, you will get an exporter with nowhere to send data unless you have configured a destination. The README's supported destinations list is the answer to that problem, and every entry on it is a separate system with its own account, ingest pricing and retention rules.
There is a second limitation that is easy to miss. The README describes instrumentations for LLM providers and vector databases, and lists Aleph Alpha, Anthropic and Bedrock among them. The list is long but it is finite. If your stack depends on a provider or a vector store that is not on it, you are writing your own instrumentation against the OpenTelemetry API, and the project gives you no scaffold for that beyond the semantic conventions it has contributed upstream.
Cost is the third issue. LLM spans are large. Prompts and completions are text, and a busy application produces a lot of it. Nothing in the README describes sampling, redaction or truncation before export, so the volume that reaches your backend is the volume your application generates. Teams that adopt OpenLLMetry without a sampling strategy usually discover this on their first invoice rather than in a design review.
OpenLLMetry Compared with Langfuse and OpenInference
The comparison people search for most is OpenLLMetry versus Langfuse, and the difference is architectural rather than feature-level. Langfuse is a tracing and evaluation platform that you run or subscribe to; it has its own data model and its own UI, and instrumentation exists to feed that platform. OpenLLMetry is instrumentation that emits OTLP. It has no data model of its own beyond the semantic conventions it contributed to OpenTelemetry, and no UI at all.
That makes the two overlap less than the search volume suggests. If you want a self-hosted trace viewer with prompt management and evaluation runs, OpenLLMetry does not give you that and was not designed to. If you already pay for Datadog or run a Grafana stack and want LLM spans next to your service traces, adopting Langfuse means running a second observability system alongside the first.
The OpenInference comparison is closer, because both projects instrument LLM libraries and both target OpenTelemetry. The practical difference for a Python team is the package layout and the attribute conventions each one emits. OpenLLMetry's distinguishing claim in the README is that its semantic conventions are now part of OpenTelemetry itself, which is a bet on standardization over a proprietary attribute schema. Whether that bet pays off depends on how quickly your backend vendor adopts the upstream conventions.
Maintenance, Licence and Upgrade Cost
The repository is not archived, and the last push was on 2026-08-10, with release 0.62.3 published the same day. Releases 0.62.2 and 0.62.1 came on 2026-08-09 and 2026-06-28, so the cadence through the summer of 2026 has been uneven: two releases a day apart, then a gap of roughly six weeks. That pattern is worth knowing if you depend on a fix landing quickly.
The licence situation needs a careful reading rather than a summary. The README states that OpenLLMetry is released under the Apache-2.0 License, and the repository's LICENSE file is the authoritative text. The package.json at the repository root declares "license": "MIT", but that file describes the Nx workspace tooling, not the published Python packages. Do not treat the root package.json as the licence of the instrumentations. If licence terms matter to your legal review, check the LICENSE file and the metadata of the specific package you install, and get that confirmed by your own counsel rather than from an article.
Upgrade cost is dominated by span attribute stability. The README points to the OpenTelemetry semantic conventions work as an ongoing discussion, which means attribute names can change as the upstream conventions settle. Any dashboard, alert or saved query you build against those attributes is a thing you re-verify on upgrade. The project publishes a CHANGELOG.md at the repository root, and that is where to look before bumping the version in a production service.
Editorial conclusion
Adopt OpenLLMetry if you already run an OpenTelemetry collector or a backend that speaks OTLP and you want LLM spans in the same pipeline as your service traces. Do not adopt it if you want a tracing UI, evaluation runs or prompt management in the same install: the README describes instrumentation and export, not a product. Before you commit, verify two things against the current docs: which of the listed destinations you are actually pointing at, and whether the specific provider or vector DB you use has an instrumentation package in the repository.
Frequently asked questions
What is OpenLLMetry used for?
It instruments LLM provider calls and vector database calls so they emit OpenTelemetry spans. Those spans go to whatever observability backend you already export to, which the README lists as including Datadog, Honeycomb, Grafana and a plain OpenTelemetry Collector.
How do I use OpenLLMetry?
Install the SDK with pip install traceloop-sdk and call Traceloop.init() before your provider clients are constructed. The README notes that if you already have OpenTelemetry instrumented, you can add individual instrumentations directly instead of using the SDK.
What is the difference between OpenLLMetry and OpenTelemetry?
OpenLLMetry is a set of extensions built on top of OpenTelemetry, not a replacement for it. It supplies instrumentations for LLM providers and vector databases and emits standard OpenTelemetry data, so it plugs into an existing OpenTelemetry pipeline.
Is OpenTelemetry free?
The README states that OpenLLMetry is built and maintained by Traceloop under the Apache-2.0 license. Note that the destination you export spans to is a separate system with its own terms, and the README lists many such destinations.
What are the alternatives to OpenLLMetry?
Langfuse and OpenInference cover overlapping ground with a different approach. Langfuse is a tracing and evaluation platform with its own UI and data model, while OpenInference is closer to OpenLLMetry in that it also instruments LLM libraries and targets OpenTelemetry.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/traceloop-openllmetry)