With contributions from Dan Gomez Blanco(New Relic). If you are building self-hosted software or a SaaS product, users will eventually ask to send logs, traces, and metrics to their own observability stack. Locking them into built-in dashboards or limiting exports to certain vendors creates unnecessary friction.
Instead, supporting export to any Open Telemetry (OTel)-compatible backend is a vendor-neutral, future-proof practice that gives users the freedom to choose their observability stack. This post outlines how to design your product so users can export logs, traces, and metrics to an OTel backend when they want to. Open Telemetry defines four signal types carried over the standard Open Telemetry Protocol (OTLP): Logs (event records, request/access logs, application logs with timestamps and metadata), Traces (distributed traces and spans users can see request flows across services and correlate with logs), Metrics (counters, gauges, and histograms, e.g., request rates, latency, error rates), and Profiles (samples that show where applications consume resources during execution).
The same export story applies to all three signals: let users configure an OTLP endpoint and push telemetry to it. You can support one, two, or all three signals depending on what your product generates. Many platforms that support OTel export support at least traces and logs, and an increasing number now ship with metrics support.
Designing for all three from the start avoids having to retrofit later. A solid export story has a few clear properties for every signal you support: vendor-neutral, no deep custom development, rich context preserved, and support for semantic conventions. Two contexts exist: where does your product run? For self-hosted software, instrument your product with Open Telemetry and let customers configure an endpoint via environment variables or a config file.
For cloud platforms, add a platform feature to manage exports. Examples include Keycloak and Kuma.
Source: Hacker News · Summarized by HeadlinesBriefing