Five Ways to Use OpenTelemetry Beyond Observability

OpenTelemetry graduated from the CNCF in May 2026 as, in the foundation’s own words, the de facto observability standard. The JavaScript API package alone did 1.36 billion downloads in twelve months.

That kind of win has a side effect nobody plans for. Once a wire format is everywhere, has a receiver for every source, a transform language, and an agent your platform team already operates, people start putting things on it that have nothing to do with knowing whether a service is healthy.

This is a field guide to what those things are. Five uses of OpenTelemetry that are not observability, why each one works, and the specific way each one bites.

First, the part that is official

Some of the expansion is sanctioned. The semantic conventions now cover CI/CD pipelines, feature flag evaluations, hardware, browser and mobile client events, and CloudEvents compatibility. Profiles entered public alpha as a fourth signal. Entities define a model for what exists rather than what happened.

The sharpest break is GenAI. Those conventions standardize capturing prompt and completion content on spans. That is payload inside telemetry, not metadata about telemetry, and it is the first time the project has blessed the pattern at the center of most of the trouble below.

1. The Collector as a general-purpose data pipeline

What people do: run the Collector where they used to run Fluentd, Logstash or Vector. Security and audit logs to a SIEM, compliance data routed to cold storage, sampling and redaction in the middle to cut backend spend. Much of this data never reaches an observability tool at all.

Why it works: receivers for nearly every source, OTTL for transforms, one agent to operate instead of three. This is mainstream enough that Gartner now maintains a Telemetry Pipelines peer insights category, and the Collector-versus-Cribl-versus-Vector comparison is a whole genre.

Where it bites: the Collector is designed to shed load. Queues fill, batches drop, and the default posture is to protect the pipeline rather than the data. That is correct for metrics and wrong for an audit trail. If the data has a retention obligation, you need a durable queue in front of the Collector, not the Collector as the durable queue.

flowchart LR
    A[App telemetry] --> R[OTLP receiver]
    B[Security logs] --> R
    C[Audit records] --> R
    R --> P[Processors and OTTL]
    P --> Q[Batch queue]
    Q -->|queue full| D[Dropped by design]
    Q --> E1[Observability backend]
    Q --> E2[SIEM or cold storage]

2. Entity events as inventory

What people do: treat entity events as a live inventory of hosts, services, volumes and their relationships. Entity state arrives as OTLP log records carrying identity, descriptive attributes and lifecycle, event-sourced and bi-temporal, so you can ask what you knew about a resource at a given moment.

Why it works: this is genuinely a gap. Metrics, logs and traces describe behavior and say almost nothing about what exists. A CMDB that updates itself from the same agent already running everywhere is an easy sell.

Where it bites: event sourcing plus at-least-once delivery means duplicate state events are normal, not exceptional. Deduplication and ordering are your problem, and most log backends will happily bill you per record while you figure that out. The entities spec is also still moving.

3. Baggage as a routing and experimentation channel

What people do: put tenant IDs, experiment assignments, sandbox routing keys and canary markers in baggage, then have infrastructure act on them. Walmart’s Expo system propagates experimentation units through the baggage header and has an Envoy WASM filter assign requests to experiments from it, pushing assignment out of the edge and into individual services.

Why it works: you already have context propagation wired through every service. Adding a second header system to carry routing decisions is redundant, so people reuse the one that is already there. This is the clearest case of OTel acting as a control plane rather than a data plane.

Where it bites: the W3C Baggage spec requires propagation when the result is 64 list members or fewer and 8192 bytes or less. Past that, entries may be discarded, and a platform that cannot propagate everything must not propagate partial members. There is no normative guidance on which keys survive, which is exactly the gap Walmart hit and is now writing guidelines for. If a routing decision depends on a key that another team’s library evicted, you get a silent misroute rather than an error. Baggage also crosses process boundaries by design, so anything you put in it is one careless egress away from leaving your perimeter.

4. Metrics as a metering feed

What people do: emit usage counters through OTel and point a billing system at them.

Why it works: the instrumentation already exists. If you are counting API calls for a dashboard, counting them for an invoice looks like the same problem.

Where it bites: it is not the same problem, and the OTLP specification is unusually direct about why. On reconnections and network interruptions a client cannot know whether data was delivered, so it resends: “This is a deliberate choice and is considered to be the right tradeoff for telemetry data.” At-least-once with expected duplicates is a fine contract for a rate graph and a terrible one for an invoice. Billing vendors draw this line explicitly, distinguishing auditable from operational usage data. You can build metering on OTel, but the deduplication, idempotency keys and reconciliation are entirely yours.

5. Spans as a payload store

What people do: attach request and response bodies, SQL statements, LLM prompts and completions to spans, so the trace holds enough detail to debug from.

Why it works: in the moment, nothing else is as convenient. The span already exists, the attribute API takes arbitrary strings, and the GenAI conventions now make part of this official.

Where it bites: three ways at once.

Constraint	Default	Consequence
Attribute count per span	128	Payload-shaped data gets silently dropped
Attribute value length	unlimited	Nothing stops you, so your backend bill finds out first
Cardinality pricing	vendor-specific	High-cardinality payload fields are the most expensive data you can send

And the fourth problem is not technical. Payloads carry PII, tokens and customer data across a trust boundary into a telemetry vendor, usually with no review, because it went out as an attribute rather than as a data transfer.

Three questions before you put non-telemetry data on OTel

1. What breaks if 1% goes missing? If the answer is “nothing, the graph is still right,” OTel is a good fit. If the answer involves a customer, an auditor or a regulator, you need guarantees the protocol explicitly declines to make.
2. Is the cardinality bounded? Attributes are not a schema. Anything unbounded — user IDs, request bodies, generated text — is priced as your most expensive data.
3. Does it cross a trust boundary? Telemetry leaves your perimeter by default. Data that needed a review to be exported does not stop needing one because it left as a span attribute.

flowchart TD
    S[Data headed for OTel] --> Q1{Is any loss acceptable?}
    Q1 -->|No| X1[Durable queue, not OTel]
    Q1 -->|Yes| Q2{Is cardinality bounded?}
    Q2 -->|No| X2[Aggregate before sending]
    Q2 -->|Yes| Q3{Crosses a trust boundary?}
    Q3 -->|Yes| X3[Redact at the Collector]
    Q3 -->|No| OK[OTel is a good fit]

If you need the payload, capture the traffic

The most common reason teams end up stuffing bodies into spans is that they want to reproduce something. A trace tells you a call took 4,218 milliseconds and returned a 500. It does not tell you what was in the request that caused it, and when the incident is over the trace is not something you can run again.

That is a different tool. Speedscale captures real application traffic and replays it, keeping the full request and response along with the dependency calls around them, which turns an incident into something you can rerun after a fix instead of a span you can only read. We wrote about that distinction in your observability stack found the fire and about the handoff itself in from telemetry to traffic. The short version: use telemetry to find out that something happened, and use captured traffic when you need the bytes.

Common questions

Can OpenTelemetry be used for data other than traces, metrics and logs?

Yes, and it routinely is. The Collector is widely deployed as a general-purpose data pipeline, entity events model infrastructure inventory, baggage carries routing and experiment assignment, and some teams feed usage metrics into billing. The project has also expanded its own scope with profiles, CI/CD conventions, feature flag evaluations and GenAI conventions that capture prompt and completion content.

Is OpenTelemetry safe to use for billing or audit data?

Not on its own. OTLP provides at-least-once delivery and the specification calls duplicate data a deliberate, correct tradeoff for telemetry. Collectors drop under backpressure by design. Anything needing completeness or exactly-once semantics requires deduplication and a durable queue you add yourself.

What are the limits on OpenTelemetry baggage?

The W3C Baggage specification requires propagation when the result is 64 list members or fewer and 8192 bytes or less. Past those limits entries may be discarded, and a platform that cannot propagate everything must not propagate partial members. The spec gives no guidance on which keys to drop first.

Should you put request and response payloads in spans?

Usually not. The default limit is 128 attributes per span, backends price on cardinality, and payloads carry PII across a trust boundary. If the goal is reproducing what happened, capture the traffic itself.