Stop Locking Users Into Your Observability Stack — Let Them Export Anywhere with OpenTelemetry
OTel-Native by Design – Building Products That Export to Any Observability Stack
If you build self-hosted software or a SaaS platform, users will eventually demand to send logs, traces, and metrics to their own observability backend. This guide shows how to design for OpenTelemetry's OTLP standard from the start, covering the four signals, vendor-neutral export principles, and real-world examples from Kuma, Keycloak, Cloudflare Workers, and Heroku. Learn the difference between instrumenting user-deployed software versus adding platform-level export features, and why OTLP push beats custom polling APIs.
Locking them into your built-in dashboards or limiting exports to certain vendors creates unnecessary friction.
- yearesadpeople
Very unfortunate that this article is written by an LLM. Reading over, the premise and the conclusion are what a chat session filled with RAG and MCP calls would bring about. Disapointed in the OTel leadership, the blog is usually a nice place to read about what is happening with the community.
- ContinuityLab
OTel-native sounds great in theory, but every vendor still finds a way to pull you into their proprietary query dialect or storage tax once you hit scale at production.
- serkan-ozal
I have been working observability world more than 10 years and what I can say is that OTEL is one of the biggest step in this space even though different vendors have their own things.