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

A solid export story has a few clear properties for every signal you support:

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.

Your 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).

Your 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.

If 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.

Whether 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:

Keycloak 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:

When 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.

Because 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:

Heroku takes a slightly different, highly configurable approach with Telemetry
Drains. Users add a destination by specifying the endpoint, transport protocol
and headers, and then explicitly choose which signals to export.

Heroku’s platform then gathers data from both the user’s application (via the
OTel SDK) and first-party services (like their Router) and pushes it to the
destination.

heroku telemetry:add  --app  --signals traces,metrics,logs --transport http --headers '{"Authorization": "ingestion key"}'

Giving users granular control over which signals to export is a pragmatic design
pattern, especially for teams looking to manage data volume and ingestion costs.

Further reading:

Across the three essential telemetry signals, the fundamental architectural
question remains the same: will your platform require the user to poll an API
for the data at regular intervals, or will it deliver the telemetry
directly to a user-defined endpoint?

Platforms have traditionally exposed telemetry by providing APIs that users must
poll at regular intervals, handle pagination for, and ingest the results into
their own backends.

It’s a reasonable starting point if you already have a mature, well-tested API
for logs or metrics, since extending it is often easier than building a new push
path. However, it comes with real costs:

• You shift a significant operational responsibility onto your users. They must
  now build scalable polling systems that can manage polling intervals, paginate
  API responses, retry on failures, and backfill missing data.
• Users might build custom solutions that don’t scale, don’t adhere to your
  standards, and require significant upkeep on their end as your API schema
  develops alongside your platform.
• Achieving near real-time delivery becomes significantly harder, which is often
  a critical requirement for latency-sensitive signals like traces and metrics.

For developer-focused, real-time telemetry, OTLP push has become the dominant
pattern.

Instead of waiting to be asked, your service (or an OpenTelemetry Collector you
run) actively exports logs, traces, and metrics directly to the user’s
configured endpoint using OTLP (over HTTP or gRPC).

It uses one vendor-neutral, industry-standard protocol for all telemetry,
meaning you avoid reimplementing telemetry delivery logic for each distinct
signal you support.

Further, OTLP provides first-class support for structured data and metadata,
helping it automatically preserve crucial context, such as linking specific log
records to their parent trace IDs.

From the user’s perspective, it is practically plug-and-play. Any
OTel-compatible backend can ingest the data in near real-time without requiring
custom polling logic.

When implementing the export model in your product, seek to maximize flexibility
with minimal configuration.

Start by letting users provide their own OTLP endpoint and any necessary
authentication headers (like an ingestion key).

But don’t stop there!

To allow users to control export volume, simplify data management, and reduce
costs, let users explicitly toggle which signals they want to export — following
Heroku’s example.

Under the hood, you have two main options: use the OpenTelemetry SDK directly
within your services to emit data, or run an internal OTel Collector that
gathers your system’s telemetry and re-exports it to the user’s endpoint.

As you design the configuration UI for your users, you’ll need to decide how
granular your telemetry routing should be. You generally have two paths, each
catering to a different type of user.

For the vast majority of users, a single endpoint configuration is ideal. Here,
the user inputs one base URL, and your exporter appends the standard OTLP paths
(v1/traces, v1/metrics, and v1/logs) internally.

Large-scale customers, or those managing complex observability setups, may wish
to send telemetry signals to different platforms.

Once you’re pushing OTLP (for any combination of logs, traces, metrics), you
still need to decide how to run Collectors to manage multiple tenants.

If your architecture already isolates tenants at the infrastructure level, you
can deploy a dedicated Collector instance for each customer. In this case, every
instance has a dedicated configuration pointing directly to that specific
customer’s export endpoint.

This provides strong logical isolation guarantees. Slowdowns or
misconfigurations in one customer’s pipeline do not affect other customers.

Here, “static” means each tenant’s pipeline and routing rules are defined
up-front in the Collector’s configuration file, rather than provisioned
dynamically at runtime.

When the choice is between making your users poll custom APIs and letting them
ingest over a shared standard, most modern, developer-focused platforms should
opt for the latter. Reach for custom polling APIs if standardization isn’t an
option.

OpenTelemetry’s unified protocol preserves rich context, delivers data in near
real-time, and has been proven at scale across cloud and self-hosted deployments
by Cloudflare, Heroku, Kuma, and Keycloak. Plus, OpenTelemetry’s independence
from a particular vendor means users have the freedom to switch between
observability backends based on their business needs, without requiring a
complete overhaul of their telemetry pipelines.

OpenTelemetry adoption does not come for free, though, as your team must invest
time to learn and implement OpenTelemetry, and build necessary documentation to
guide users and internal teams on best practices.

To conclude, you don’t need to build bespoke integrations to let your users
export telemetry to their own backends.

If you’re ready to implement OTel-native export in your application, here’s a
summary of the key architectural and design steps to follow:

• Decide which telemetry signals to support out of logs, traces, and metrics.
  You should ideally support all three, but start with what your product
  generates.
• Use OTLP to export those signals via the OTel SDK or a Collector. The same
  push-based architecture works for all three signals.
• Let users configure a destination endpoint and optional auth headers. Consider
  per-signal endpoints for teams with more complex setups.
• Allow users to enable or disable individual signals to control data volume and
  costs.
• Document your endpoint format (gRPC/HTTP), required headers, and
  attribute/schema semantics per signal so users can confidently rely on the
  data in their backends.
• Choose a Collector topology: one Collector per tenant for strong isolation, or
  a shared Collector with per-tenant pipelines for lower operational overhead.
• Provide an example config or env var snippet so users can get started quickly.

The points above also encapsulate the golden rules that Cloudflare (except for
metrics), Heroku, Kuma, and Keycloak follow: default to push, stay
vendor-neutral, and document the contract.

Designing for all three signals using open standards from the start removes
friction, reduces your engineering overhead, and empowers customers to make the
best use of their data on their own terms.