OpenTelemetry guidance urges products to make telemetry exports vendor-neutral

# OpenTelemetry guidance urges products to make telemetry exports vendor-neutral

The OpenTelemetry project has published design guidance for software vendors that want customers to export operational data to third-party observability systems without being locked into one monitoring provider. The guidance, available on the event date, recommends treating OpenTelemetry Protocol support as a native product capability rather than a later integration.

The central recommendation is to let users configure an OTLP endpoint and push telemetry to it. OpenTelemetry currently centers that export pattern on logs, traces and metrics. A fourth signal, profiling, entered public alpha on March 26, 2026, but the guidance focuses on the three mature categories that products commonly generate today.

The implementation differs depending on where software runs. For products installed in a customer's own data center, cloud account or Kubernetes environment, the project recommends shipping built-in OpenTelemetry instrumentation and exposing standard endpoint configuration. The customer's copy of the application then sends telemetry directly to the destination they control. The guidance points to Kuma and Keycloak as examples of this model.

Platforms that run customer workloads on their own infrastructure need a different interface. In that case, the provider can offer telemetry drains or observability destinations, collecting data from hosted workloads and forwarding it to the customer's configured OTLP endpoint. Cloudflare and Heroku are cited as examples of the platform-operated approach.

The common design principle is push-based export with customer control over the destination. A product may support one, two or all three main signals, but the guidance argues that planning for logs, traces and metrics at the outset avoids a difficult retrofit. It also notes that products vary in how they expose settings: some use one shared endpoint for several signals, while others allow users to select signals independently.

Keycloak, for example, can send data to a collector endpoint from the process itself and provides switches for individual signals as well as settings for headers and transport protocol. Kuma exposes telemetry controls for its service-mesh deployments. For hosted workloads, Cloudflare's Observability Destinations can forward Workers traces and logs, although the cited implementation does not yet support metrics.

The guidance presents portability as both an operational and commercial requirement. Customers may need to centralize data, meet compliance obligations or control monitoring costs, and a fixed dashboard or restricted vendor list can become an obstacle. Native OTLP support gives product teams a common transport contract while allowing customers to retain their preferred storage and analysis tools.

This is architectural guidance rather than a new protocol release. Its significance lies in urging vendors to make interoperable export part of the core product design, with consistent configuration and clear ownership of where telemetry is produced and forwarded.