Designing Products for OpenTelemetry Export to Any Observability Stack

The Need for Vendor-Neutral Observability Export

Self-hosted software and SaaS products often face user requests to send logs, traces, and metrics to their own observability stacks. This is driven by needs such as compliance, cost management, and centralizing observability data. Restricting exports to specific vendors or built-in dashboards creates friction for users.

OpenTelemetry as a Solution

Supporting export to any OpenTelemetry (OTel)-compatible backend offers a vendor-neutral and future-proof approach. This gives users the freedom to choose their preferred observability stack. The article details how to design products to allow users to export their telemetry data to an OTel backend.

OpenTelemetry Signal Types

OpenTelemetry defines four signal types carried over the standard OpenTelemetry Protocol (OTLP): logs (event records, request/access logs), traces (distributed traces and spans), and metrics (counters, gauges, histograms). A fourth signal type, profiles, entered public alpha on March 26, 2026, to capture resource usage patterns. The article focuses on logs, traces, and metrics, noting that the same export principles apply to all three.

Implementing OTLP Export

For each supported signal (logs, traces, metrics), products should allow users to configure an OTLP endpoint and push telemetry to it. Many platforms supporting OTel export already support traces and logs, with increasing support for metrics. Designing for all three signals from the outset is recommended to avoid later retrofitting.