OpenLLMetry: OpenTelemetry-based LLM observability without vendor lock-in
Open-source observability for your GenAI or LLM application, based on OpenTelemetry
At a glance
- What is it?
- OpenLLMetry adds LLM-aware spans to OpenTelemetry, so you can trace OpenAI, Anthropic, and vector DB calls into Datadog, Grafana, or any OTLP destination. The trade-off is that you must know which instrumentations you need and where your traces go.
- Who is it for?
- Adopt OpenLLMetry if you already run OpenTelemetry and want LLM-specific spans without switching to a proprietary APM. Skip it if you need a turnkey dashboard with built-in LLM metrics, because you must configure an exporter and a backend yourself.
- 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 37 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenLLMetry actually solves
The main value is that you can keep your existing observability stack. The README lists over twenty destinations, including Datadog, Honeycomb, Grafana, New Relic, and the OpenTelemetry Collector. If you already have a pipeline that accepts OTLP, you can plug OpenLLMetry into it. This is different from most LLM observability tools, which usually require you to send data to their own cloud. OpenLLMetry's approach is to make LLM calls visible in the same traces as your database queries and API calls, so you can correlate a bad LLM response with a slow database query or a failed upstream call.
How the instrumentation works under the hood
One important detail is that the semantic conventions are now part of OpenTelemetry. The README links to a community discussion about LLM semantic conventions. This means that OpenLLMetry is not inventing a proprietary data format. The spans you generate should be understandable by any tool that adopts the OTel LLM conventions. That is a strong point for long-term portability. However, the README does not show the exact span structure or attribute names, so you cannot know from this material what fields you will see in your traces. You would need to check the documentation or run a quick test to see the actual data shape.
Getting started: the two-line SDK path
For users who already have OpenTelemetry, the alternative path is to add individual instrumentations. The README mentions opentelemetry-instrumentation-openai as a separate package. That suggests you can avoid the SDK entirely and just install the specific instrumentation you need. This is a cleaner approach if you have a custom OpenTelemetry setup. The README does not give the exact pip command for that package, but it is referenced in the badge and in the text. The flexibility is there, but the documentation is thin in the README itself.
What gets instrumented: providers and vector DBs
The README lists a set of instrumented targets. For LLM providers, it mentions Aleph Alpha, Anthropic, and Bedrock (AWS), but the list is truncated. The full list is likely longer, but from this material you can confirm OpenAI and Anthropic are included, as well as Bedrock. For vector DBs, the README names Chroma, Pinecone, Qdrant, and Weaviate. It also says that OpenLLMetry can instrument everything that OpenTelemetry already instruments, such as database calls and API calls. That is a broad claim, but it is accurate in the sense that OpenLLMetry builds on the OTel contrib instrumentations. The practical meaning is that you can get a single trace that includes the vector DB query, the LLM call, and the surrounding application logic. The README does not specify which versions of each provider SDK are supported, nor does it mention LangChain or LlamaIndex. If you use a framework that is not in the list, you would need to check the repository or the docs. This is a limitation: the supported matrix is not fully visible in the README.
Where to send the traces: the destination list
The README includes a long list of supported and tested destinations. It covers major APM vendors like Datadog, New Relic, Dynatrace, and Splunk, as well as open-source backends like Grafana, SigNoz, and the OpenTelemetry Collector. It also includes cloud-specific options like Azure Application Insights, Google Cloud, and Oracle Cloud. There are also smaller players like Highlight, HyperDX, and KloudMate. The list is impressive, but it is a list of integrations that are documented, not a guarantee that every destination works flawlessly. The README says these are supported and tested, which is a stronger claim than just supported. Still, you should verify that your exact backend version is compatible. The README links to documentation for exporting to each destination, so the setup instructions are separate. The key point is that you are not forced to use Traceloop's own service. You can send data to the OpenTelemetry Collector, which gives you full control over routing and processing. That is a major advantage for teams that already run a Collector.
The real limitations: batching, configuration, and coverage
The README reveals one limitation directly: batch sending is the default, and you must disable it to see traces immediately. That is fine for development, but in production you want batching for performance. The trade-off is that traces may be delayed by the batch interval. That is standard for OpenTelemetry, but it is worth noting for debugging latency. A bigger limitation is that the README does not document the required environment variables or exporter configuration. The Traceloop.init() call with no arguments must read some configuration, but the README does not say what. New users will have to dig into the docs or read the source. Another limitation is the coverage list. The README is truncated, so you cannot see the full list of instrumented providers. If you use a less common provider, it may not be supported. The README also does not mention any support for self-hosted LLMs or local models like Llama.cpp. That is a significant gap for teams running open-source models. Finally, the project is maintained by a commercial company, Traceloop. Even though the code is Apache-2.0, the roadmap may be influenced by Traceloop's business interests. That is not a flaw, but it is a consideration for long-term independence.
Alternatives: the standalone instrumentation packages and vendor SDKs
The most direct alternative is to use the individual OpenTelemetry instrumentation packages that OpenLLMetry publishes, such as opentelemetry-instrumentation-openai. This gives you the same spans without the Traceloop SDK. The difference is that you have to configure the OpenTelemetry SDK yourself, including setting up a resource, a span processor, and an exporter. That is more work, but it removes the dependency on the Traceloop SDK. Another alternative is to use a vendor-specific LLM observability SDK, such as LangSmith or Phoenix. Those tools provide a user interface with LLM-specific features like prompt tracing and evaluation, but they often require you to send data to their platform. OpenLLMetry's approach is the opposite: it sends standard OTel data to any backend. If you compare OpenLLMetry to a tool like LangSmith, you are comparing a generic instrumentation layer to a full LLM development platform. OpenLLMetry gives you raw traces, not a dashboard. You would need to build or buy the dashboard yourself. For teams that already have a monitoring stack, that is fine. For teams that want an all-in-one LLM observability tool, OpenLLMetry is not enough.
Maintenance and license considerations
The repository shows active maintenance. The last push was in August 2026, and there are recent releases at 0.62.3, 0.62.2, and 0.62.1. The version number 0.62 suggests a fast release cadence, which could mean frequent bug fixes and new instrumentations. However, it also means that the API may change between minor versions. The project is not archived, and the README mentions a CI badge and a contributing guide, so it is open to contributions. The license is Apache-2.0, which is permissive. You can use it in commercial products, modify it, and distribute it, as long as you preserve the license notice. There is no copyleft obligation. The README also mentions that the semantic conventions are now part of OpenTelemetry, which is a good sign for the longevity of the data format. Even if the project were discontinued, the spans you generate would still be valid OpenTelemetry spans. That is a strong advantage. The maintenance cost for you is mostly in keeping up with new releases and checking that your instrumentations still work after upgrade. The fast release cadence means you should pin your dependency and test before upgrading.
Editorial conclusion
Adopt OpenLLMetry if you already run OpenTelemetry and want LLM-specific spans without switching to a proprietary APM. Skip it if you need a turnkey dashboard with built-in LLM metrics, because you must configure an exporter and a backend yourself. Before committing, verify that the instrumentations you need (provider, vector DB, framework) are on the supported list and that your chosen destination is in the tested list. Check the release cadence: the repo shows frequent releases, but confirm that your pinned version still receives updates. If you only need OpenAI traces, consider the standalone opentelemetry-instrumentation-openai package instead of the full SDK.
Community notes