OTel-Native by Design - Building Products That Export to Any Observability Stack
Pangram verdict · v3.3
We believe that this text is a mix of AI and human-written content.
AI likelihood · overall
MixedArticle text · 1,156 words · 2 segments analyzed
With contributions from Dan Gomez Blanco (New Relic).If you’re building self-hosted software or a SaaS product, your users will eventually ask to send logs, traces, and metrics to their own observability stack, whether to satisfy compliance, manage costs, or centralize all their observability data in one place.Locking them into your built-in dashboards or limiting exports to certain vendors creates unnecessary friction. Instead, supporting export to any OpenTelemetry (OTel)-compatible backend is a vendor-neutral, future-proof practice that gives users the freedom to choose their observability stack.This post outlines how you can design your product so users can export their logs, traces, and metrics to an OTel backend when they want to.The four observability signalsOpenTelemetry defines four signal types, all carried over the standard OpenTelemetry Protocol (OTLP):Logs: Event records, request/access logs, and application logs with timestamps and metadata.Traces: Distributed traces and spans so users can see request flows across services and correlate them with logs.Metrics: Counters, gauges, and histograms (e.g., request rates, latency, error rates).Profiles: Samples that show where applications consume resources during execution.The same export story applies to all three (logs, traces, and metrics): 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.What a “good” telemetry system looks likeA solid export story has a few clear properties for every signal you support:Vendor-neutral: Users can point at any OTel-compatible endpoint — a Collector instance, or one of the many backends that support OTLP directly — without building custom integrations for each.No deep custom development: External platforms (or your users’ tooling) can integrate using standard OTel SDKs and the OTLP protocol instead of proprietary APIs.Rich context preserved: Exported data should include metadata, timestamps, and trace/span correlation where available (e.g., log records linked to trace IDs), so users can debug and analyze data in their own backend without losing context.Support for Semantic Conventions: Adherence to the Semantic Conventions ensures that telemetry data remains standardized and is easily interpretable by any compatible backend. It also reduces the cognitive burden on the end-user to reason about how the software system works, be it a first-party or third-party system.If your design aligns with these principles for the signals you emit, you’re in step with how modern platforms think about observability export.Two contexts: where does your product run?The way you add OTel export depends on who owns the system that produces the telemetry. Getting this straight helps you choose the right approach.Self-hosted softwareYour product is an application or system (e.g., an identity server, a service mesh, a database) that customers install and run in their environment (their data center, their cloud, their Kubernetes cluster).Here, you instrument your product with OpenTelemetry. When the customer configures an endpoint (e.g., via environment variables or a config file), your application exports telemetry from the process they’re running.Since OpenTelemetry provides such standard configuration options, your users can expect the same configuration experience they already have with any other OTel-instrumented system.The export happens in the customer’s environment; they control the binary and the destination. Examples: Keycloak, Kuma.Cloud platformsYour product is a platform where customers deploy their own apps or use your managed services (e.g., PaaS, serverless, API gateway).
The workload runs on your infrastructure.Here, you add a platform feature, such as “Telemetry Drains” or “Observability Destinations” that lets customers configure where to send telemetry. Your platform collects telemetry from their workload (and from your own services, like routers) and forwards it to the customer’s OTLP endpoint.The export is done by your infrastructure, not by an application binary the customer runs. Examples: Heroku, Cloudflare.In short, user-deployed software → focus on built-in instrumentation and an endpoint config. A platform you operate → focus on configurable export destinations that your infrastructure uses to forward data.How others do itThis post focuses on four integrations — Kuma, Keycloak, Cloudflare, and Heroku — as representative examples across the two contexts above, but they’re far from the only ones already exporting telemetry natively via OTLP. The OpenTelemetry Integrations page features libraries and services that provide native instrumentation or first-class plugins.Below is how these four handle all three signals (or a subset) and what you can learn from them.PlatformLogsTracesMetricsDeployment ModeNotesKumaYesYesYesSoftware users deploySeparate policies per signal, all OTelKeycloakYes†YesYesSoftware users deploy†Logs in preview; same endpoint for allCloudflare WorkersYesYesNo*Platform*Metrics export not yet supportedHerokuYesYesYesPlatformUser chooses signals via --signalsThe self-hosted approach: Kuma and KeycloakIf your users deploy your software into their own environments, the best practice is to ship the application pre-instrumented with OpenTelemetry and expose configuration flags for their OTLP endpoints.KumaWhether customers run Kuma’s control and data planes on their own Kubernetes clusters or VMs, it comes pre-configured to emit logs, traces, and metrics to an OTel backend.Users configure the export, which runs from their Kuma deployments, through the mesh policies:MeshAccessLog: Routes access logs to an OTel Collector (endpoint + attributes such as mesh name, start time).MeshTrace: Handles distributed traces with configurable sampling and tagging.MeshMetric: Exposes control and data plane metrics. Integrates with OpenTelemetry and Prometheus.For example, sending traces to an OTel backend looks like this:# MeshTrace policy backends: - type: OpenTelemetry openTelemetry: endpoint: otel-collector:4317 Sending access logs follows the exact same pattern with a different policy:# MeshAccessLog policy backends: - type: OpenTelemetry openTelemetry: endpoint: otel-collector:4317 body: kvlistValue: values: - key: mesh value: stringValue: '%KUMA_MESH%' attributes: - key: start_time value: stringValue: '%START_TIME%' Further reading:Kuma MeshAccessLog – OpenTelemetryKuma MeshTrace (OpenTelemetry backend)Kuma observabilityKeycloakKeycloak is another example of self-hosted software providing great telemetry export functionality.Instead of requiring a separate sidecar or platform feature, users just pass a startup flag pointing to their Collector endpoint, and the Keycloak process itself handles the export.It uses a single telemetry endpoint but provides granular flags to toggle specific signals:Traces: tracing-enabled=true (covers HTTP requests, DB, LDAP, outbound HTTP/IdP).Metrics: Detailed metrics exposed via the same OTel integration.Logs: Currently in preview and disabled by default (--features=opentelemetry-logs --telemetry-logs-enabled=true, with --telemetry-logs-level for level filtering).Defining the endpoint, optional headers, and preferred protocol (gRPC or HTTP) looks like:bin/kc.sh start --telemetry-endpoint=http://my-otel-endpoint:4317 --telemetry-protocol=grpc Further reading:Keycloak Observability / TelemetryThe platform approach: Cloudflare and HerokuWhen you control the infrastructure, a straightforward user experience is to handle the export at the platform level, pulling data from the user’s workload and pushing it to their destination.Cloudflare WorkersBecause users run their code directly on Cloudflare’s infrastructure, it handles the export through the Observability Destinations platform feature. It offers users a streamlined design where they can configure an OTLP endpoint in their dashboard. From there, Cloudflare automatically pushes traces and logs from Workers to that destination.While metrics aren’t supported yet, the trace data provides deep, end-to-end visibility as it records handler calls, bindings, outbound fetch calls, and more. Users can also configure the sampling rate in their wrangler.toml.Further reading:Exporting OpenTelemetry data from WorkersCloudflare Workers and TracesHerokuHeroku takes a slightly different, highly configurable approach with Telemetry Drains.