OpenLLMetry-JS: OpenTelemetry Instrumentation for JavaScript LLM Stacks
Sister project to OpenLLMetry, but in Typescript. Open-source observability for your LLM application, based on OpenTelemetry
At a glance
- What is it?
- OpenLLMetry-JS wraps OpenTelemetry with instrumentations for LLM providers, vector databases and agent frameworks, plus a Traceloop SDK that bootstraps the whole pipeline in two lines. It is a sensible fit if you already run an OTLP backend; it is the wrong tool if you want a managed eval or prompt-management product.
- Who is it for?
- Adopt OpenLLMetry-JS if you already operate an OTLP-compatible backend and want LLM spans flowing into it without writing provider-specific instrumentation yourself. Do not adopt it expecting an evaluation harness, prompt registry or dataset tooling; the repository is instrumentation and export, nothing more.
- 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 90 days ago.
- What is it written in?
- Mainly TypeScript, 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
The gap OpenLLMetry-JS fills between generic tracing and LLM calls
Standard OpenTelemetry instrumentation for Node.js covers HTTP clients, database drivers and framework internals. It does not know that a fetch call to api.openai.com carries a prompt, a completion, a token count or a model name. That is the gap this repository targets. The README describes it as a set of extensions built on top of OpenTelemetry that gives you observability over your LLM application, and states that because it uses OpenTelemetry under the hood it can connect to existing observability solutions such as Datadog and Honeycomb. The audience is therefore narrow and specific: teams already running an OTLP collector or a commercial APM backend who want LLM spans in the same place as their HTTP and database spans, rather than in a separate LLM-only dashboard. If you have no tracing infrastructure at all, the value proposition shrinks considerably, because you would be adopting OpenTelemetry and its collector configuration at the same time as the LLM layer.
What the repository actually ships: instrumentations plus a bootstrap SDK
The repo contains two distinct things. The first is a set of OpenTelemetry instrumentations for LLM providers and vector databases. The second is the Traceloop SDK, published as @traceloop/node-server-sdk, which wires those instrumentations together so you do not have to register each one by hand. The README is explicit that the instrumentations emit standard OpenTelemetry data and that if you already have OpenTelemetry instrumented you can add any of the instrumentations directly. That distinction matters for dependency management: pulling in the SDK pulls in the full set, while consuming individual instrumentations lets you keep the dependency surface smaller. The provider list covers OpenAI, Azure OpenAI, Anthropic, Cohere, Vertex AI and Bedrock, with Replicate and HuggingFace marked as in progress. Vector database coverage lists Pinecone, Chroma and Qdrant as supported, with Weaviate and Milvus in progress. Frameworks listed are LangChain and LlamaIndex. Anything outside those lists is not covered by this repository, and the README does not claim otherwise.
Initialization order is the constraint that breaks traces silently
The README gives a two-line setup: install @traceloop/node-server-sdk, then import the module and call traceloop.initialize(). It follows that with an instruction that carries most of the operational risk: make sure to import the SDK before importing any LLM module. This is a monkey-patching pattern, the same one OpenTelemetry uses for its own auto-instrumentation. If an LLM client library is loaded before the SDK, the patching has nothing to wrap and spans are never produced. There is no error, no warning in the documented flow, just an empty trace view. This is the single most common way a setup like this fails, and it interacts badly with bundlers and frameworks that hoist or reorder imports. The README also notes that for local runs you may want to disable batch sending so traces appear immediately, using traceloop.initialize({ disableBatch: true }). That flag is a development convenience; leaving it on in production changes the export behaviour, and the documentation does not spell out the throughput consequences of doing so.
Export destinations and the OTLP escape hatch
The README lists supported and tested destinations: Traceloop, Dynatrace, Datadog, New Relic, Honeycomb, Grafana Tempo, HyperDX, SigNoz, Splunk and the OpenTelemetry Collector. The word tested is doing real work in that sentence, and it is the only quality signal in the README worth trusting, because it describes a verification step rather than a popularity metric. For anything not on that list, the OpenTelemetry Collector entry is the general path: point the SDK at a collector and let the collector's exporter configuration handle the rest. That is the honest answer for teams on an in-house backend. It also means the export layer is not something this project controls. If your collector pipeline drops attributes or samples aggressively, the LLM-specific fields the instrumentations attach may not survive to the backend, and nothing in this repository prevents that.
Where OpenLLMetry-JS is the wrong tool
This is instrumentation, not an LLM platform. It does not run evaluations, store prompt versions, manage datasets or score outputs. Teams that need those capabilities are looking at a different category of product, and the README makes no claim in that direction. A second limitation is language scope. The repository is the TypeScript sibling of a Python project, and the supported provider and vector database lists are shorter than what a Python-first team might expect. If your stack is Python with a small TypeScript edge service, instrumenting only the edge gives you a partial trace, and partial traces are often worse than none because they invite confident wrong conclusions about where latency sits. A third consideration is the telemetry note in the README, which states that the SDK and instrumentations no longer log or collect telemetry and that users should be on v0.21.1 or above. Anyone pinned to an older version should treat that as a reason to upgrade rather than a background detail.
How this differs from vendor-native LLM tracing SDKs
The closest alternative in approach is a vendor SDK that ships its own tracing client, for example the tracing utilities bundled with a specific LLM platform, or a self-hosted LLM observability server with its own agent. Those tools typically give you a purpose-built UI for prompts and completions out of the box, and they own the whole path from instrumentation to storage. OpenLLMetry-JS takes the opposite position: it produces OpenTelemetry spans and stops there, leaving storage, query and visualisation to whatever backend you already run. The practical difference shows up in two places. First, correlation: because the spans are ordinary OTel spans, an LLM call can appear in the same trace as the database query that fed it, which vendor-specific agents generally cannot do without custom work. Second, feature depth: a vendor SDK will usually ship prompt-level views and comparison tooling that you would have to build yourself on top of raw OTel data. Choosing between them is really a question of whether your organisation already treats OpenTelemetry as the standard, or whether you want the LLM-specific UI more than you want trace correlation.
Maintenance cost, versioning and licence terms
Recent releases show a steady cadence: 0.25.0 in April 2026, 0.26.0 a few days later, 0.27.0 in late May 2026, with the last push to the default branch in June 2026. The version numbers are still pre-1.0, which in practice means minor releases can carry breaking changes and you should read release notes before bumping. Pinning an exact version in package.json is the low-effort mitigation. The licence is Apache-2.0, which permits commercial use and modification and includes a patent grant; it also requires that you preserve copyright and licence notices and state significant changes if you redistribute modified versions. That is a summary of the licence identifier, not legal advice, and any organisation with a formal open source review process should route it through that process. One structural risk worth naming: the SDK and the hosted Traceloop product share a maintainer. The README's telemetry note and the separate instrumentation packages are evidence that the open source path is usable without the hosted service, but the commercial relationship is the thing to keep in view when assessing long-term direction. There is no published support commitment in the material available here.
Editorial conclusion
Adopt OpenLLMetry-JS if you already operate an OTLP-compatible backend and want LLM spans flowing into it without writing provider-specific instrumentation yourself. Do not adopt it expecting an evaluation harness, prompt registry or dataset tooling; the repository is instrumentation and export, nothing more. Before committing, verify that your provider appears in the supported list (Replicate, HuggingFace, Weaviate and Milvus are marked as in progress), confirm the SDK import ordering works with your bundler, and check whether you need the Traceloop SDK at all or can consume the individual instrumentations directly.
Community notes