Skip to content
OrionHub Developer tooling and cloud development
Section
archive
Kind
Archive · commissioned
Reading time
8 min

OpenTelemetry Tightens Instrumentation Standards, Prioritizes Client-Side Observability

15 October 2026

OpenTelemetry, the open-source observability framework, is moving to stabilize and standardize its semantic conventions, with a major focus on client-side telemetry. In its latest roadmap, the project emphasizes the importance of consistent naming and event definitions for more precise observability data across traces, metrics, logs, and mobile/client instrumentation.

Structured Semantic Definitions Are Priority One

OpenTelemetry defines semantic conventions as the common names and metadata definitions for telemetry signals. These conventions span traces, metrics, logs, and events, and are crucial for correlating data from different parts of distributed systems.

"Consistency in semantic conventions is key to getting the most value from observability telemetry," said the OpenTelemetry roadmap, released earlier this year. "It allows users to reason about the data more intuitively, and observability systems to correlate related signals across different telemetry types."

To that end, OpenTelemetry's roadmap marks "Further Stabilizing Semantic Conventions" as a priority. The project has already defined conventions for tracing, metrics, and logs, but it plans to expand this to client-side instrumentation as well.

End-to-End Visibility through Client Instrumentation

One area where restricted or inconsistent semantic conventions have historically tripped up observability is on the client side - web pages, mobile apps, and any code running away from centralized servers. Client instrumentation captures telemetry from user interactions, network traffic, and device behavior, but different conventions across browsers and platforms have often made this hard to aggregate and analyze.

OpenTelemetry's Client Instrumentation Special Interest Group (SIG), established in late 2021, is charged with defining client-side telemetry conventions. Its work to date includes a semantic convention for mobile app lifecycle events, specifying an event name `device.app.lifecycle` for transitions like app start, background, and resign.

"Getting client-side telemetry right is essential for end-to-end observability," said the roadmap. "We want to raise the bar for real user monitoring (RUM) across all client environments, capturing latency metrics from internet to server to client-side code."

JavaScript SDK 2.0 Signals Progress for Mobile/Edge Observability

The latest OpenTelemetry JavaScript SDK, version 2.0 released March 26, promises improved support for modern JavaScript frameworks and cloud environments. The SDK now requires Node.js and TypeScript to be at least version 18, and shifts its transpilation default to ES2022 syntax.

"This upgrade is a big step for the OpenTelemetry JavaScript stack," said the 2.0 release announcement. "It positions the SDK for better performance and compatibility in mobile, browser, and edge environments."

The release specifies that in JavaScript and TypeScript, the stable OpenTelemetry semantic conventions will ship as a separate package. Developers wanting to use incubating or unstable conventions will need to import an additional package at their own risk.

Multiple Schemas, Consistent Naming

Underpinning this push for standardization is a revised approach to semantic conventions themselves. OTEP 4815, postponed last year then reactivated this spring, proposes a new schema format for defining conventions.

"Current OpenTelemetry semantic conventions are not specified in a way that gives consumers a full schema," the specification says. "Building a schema that offers one capability, plus dual schemas for stable and development conventions, is the solution."

In a call on March 21, OTEP 4815 authors planted the idea of creating different versions of a schema file to offer both a stable set of tried-and-tested semantic conventions, and a development one for conventions still in the experimental incubator. These would be published in sync with each OpenTelemetry major release, and act to squash all bugs in "official" semantics before introducing new metadata hooks for developers.

So What's Changed for Teams Using OpenTelemetry?

For teams already using OpenTelemetry, the focus on standardized conventions offers the promise of more consistent and actionable observability data. However, it may require projects to update their instrumentation to use the new convention definitions.

Developers working with the JavaScript SDK, in particular, should review the deprecations and breaking changes in the 2.0 release, as the SDK is raising minimum version requirements for the underlying Node.js and TypeScript frameworks.

One halo effect of OpenTelemetry's semantic convention project is easier integration with other telemetry-focused tools. "When we all agree on telemetry data structures, more third-party tools can automatically fetch and analyze that telemetry data," said the release announcement. In particular, the new semantic convention schema format "will offer more opportunities for automatic schema exploration, by now supporting multiple schema locations and clear field descriptions."

For enterprises integrating OpenTelemetry into their telemetry stack, working with the new conventions and schemas is crucial for taking full advantage of the tool's capabilities. Maturity of the semantic conventions is a key marker of the maturity of the OpenTelemetry toolkit itself, letting teams integrate telemetry data from vastly different environments and code stacks.

As OpenTelemetry continues to evolve its semantic conventions and SDKs, bringing greater standardization and client-side observability, the result will be a telemetry stack that's clearer, more consistent, and easier to leverage across the enterprise. Teams should start reviewing the 2.0 changes to see how best to incorporate them, so they can make the most of OpenTelemetry's continual improvements.