OpenTelemetry JavaScript: Adding Traces, Metrics, and Logs to Node.js

What it is for

OpenTelemetry JavaScript is the JavaScript client for OpenTelemetry, a framework for collecting traces, metrics, and logs from applications. It is a candidate for JavaScript and Node.js developers, platform engineers, observability teams, and library authors who want to expose telemetry through a common API. The repository is licensed under Apache License 2.0 and is not archived.

The README lists the APIs and SDKs for tracing, metrics, and logs as Stable. That status does not remove the need for deployment design. Teams still need to decide which signals to collect, where to export them, how to control volume, and how to handle sensitive attributes. The supplied project pages do not confirm specific production policies, so those decisions must be validated against the organization’s backend and governance requirements.

Known capabilities and integration model

The project separates its API, stable SDK packages, and experimental packages. Its Node.js example initializes a NodeSDK, defines resource attributes, configures a tracing exporter, and uses an auto-instrumentation meta package from opentelemetry-js-contrib. The example sends spans to the console through ConsoleSpanExporter. That is useful for checking initialization and signal generation; it should not be treated as a recommendation to send production telemetry directly to a console.

The documentation addresses both CommonJS and ECMAScript Modules, but notes that much of the documentation assumes a compiled application running as CommonJS. Applications using ESM, bundlers, or frameworks should verify module resolution and initialization order. Library authors are advised to rely only on the public API. Depending on SDK internals can make a library break when an application uses a different SDK implementation.

Limitations before adoption

For Node.js, the README says that only Active or Maintenance LTS versions are supported. Older versions may work, but they are not tested or guaranteed by the project. If adopting v3.0.0, note that the minimum supported Node.js version is now >=22.15.0, while Node.js 18 and 20 support was dropped. The release also includes public interface changes and requires experimental package version 0.300.0 for compatibility. Review the runtime, lockfile, experimental packages, and internal wrappers before upgrading.

Version 3.0.0 also changes build output and package exports. Deep imports into build directories no longer resolve. Applications or libraries that depend on internal paths must move to public entry points; simply guessing a replacement file path is not sufficient. Browser client instrumentation remains experimental and is described as mostly unspecified. Its minimum language feature level is ECMAScript 2022, so older target environments require transpilation and any necessary polyfills. React Native and Expo use browser implementations and have Metro and React Native version requirements, so a Node.js deployment plan cannot be reused unchanged.

Deployment considerations

Start with one service and verify SDK initialization, resource attributes, the export path, and graceful shutdown before expanding the rollout. Diagnostic logging can help determine whether telemetry reaches a collector, but increased diagnostic output should be controlled in production. Manage dependencies according to the project’s compatibility matrix, keeping stable and experimental package lines distinct. Finally, assess the data collected, retention, access control, and operational cost. The supplied sources do not make specific guarantees in these areas, so support for a signal should not be interpreted as a complete production governance solution.

Sources

• GitHub repository metadata
• Project README
• Official release
• Official project page

Sources checked: 2026-10-23