OTel-Native by Design – Building Products That Export to Any Observability Stack

Building products that export telemetry data to any OpenTelemetry (OTel)-compatible backend is a vendor-neutral and future-proof practice. This approach allows users to choose their preferred observability stack and helps avoid unnecessary friction when sending logs, traces, and metrics. To support OTel export for your product, you can either instrument the application or system that generates the telemetry (for self-hosted software or SaaS products) or add a platform feature that allows customers to configure telemetry destinations (for products where customers deploy their own apps or use managed services).

OpenTelemetry defines four signal types – logs, traces, metrics, and profiles – which can be exported using the standard OpenTelemetry Protocol (OTLP). When designing your product's export story, consider the following properties for every supported signal:

1. Configuration ease: Ensure users can configure OTLP endpoints through environment variables, config files, or other standard configuration options.

2. Centralized export: Let users configure a single OTLP endpoint for all supported signals if possible.

3. Flexibility: Allow users to choose which signals to export based on their needs (e.g., Heroku's --signals option).

Two primary deployment contexts for OTel export are:

1. User-deployed software: In this case, focus on built-in instrumentation and an endpoint configuration for customers to run OpenTelemetry in their environments.

2. Platform you operate: Here, focus on configurable export destinations that your infrastructure uses to forward data from the user's workload.

When designing your OTel export story, it's essential to support all three signals (logs, traces, and metrics) whenever possible, as it provides users with greater flexibility to create a comprehensive observability picture in their chosen backend. Examples of products that natively support OTel export include Kuma, Keycloak, Cloudflare, and Heroku, and you can learn from their approaches to designing effective telemetry export experiences.