Created on 2025-09-02 14:56
Published on 2025-09-08 10:30
If you’ve worked on-call this year, you’ve probably noticed the same vibe: OpenTelemetry (OTel) is no longer the scrappy side project in the observability booth. It’s the de facto data plane for logs, metrics, and traces in cloud-native systems. Vendors are racing to make adoption easier. Mobile engineers are finally joining the party. And SREs are quietly muttering “about time” while retiring one-off agents with names they’d rather forget.
This piece explores what’s actually happening: OTel’s practical maturity (including easier auto-instrumentation), the “OTel everywhere” vendor moves (with third-party coverage), and what the new wave of mobile adoption means for SRE and DevOps teams. Along the way, we’ll unpack trade-offs, share tactics that won’t blow up your pager, and poke at the very human tendencies that still derail the cleanest telemetry plans.
The project positions itself as a vendor-neutral standard supported by dozens of platforms and backends, and the docs increasingly read less like an experiment and more like a contract. That broad support is precisely why platform teams are standardizing the “pipes” first, and choosing visualization/storage backends second.
The question SREs asked for years was simple: “Is OTel stable enough to bet on in production?” For many, the answer in 2025 is “yes, with eyes open.”
Two milestones matter. First, the Logs data model is marked Stable—crucial for correlating logs with traces without bespoke shims. Second, the Metrics data model is also Stable, tightening semantics across exporters and backends. These are the kind of boring-but-needed commitments that let platform teams design once and roll out everywhere instead of arguing about field names during an outage.
OTel’s governance/process around client stability gives additional confidence. You still have to read the fine print for each language, but the direction is clear: long-lived guarantees beat heroic dashboard archaeology at 04:00.
The least fun part of OTel has always been the initial lift: adding SDKs, propagators, and semantic conventions without redeploying the universe. That’s changing, fast.
On the “zero-code” side, the Java agent can attach to any Java 8+ app to capture common frameworks out of the box—an easy on-ramp for brownfield services. Meanwhile, the community’s newer eBPF-powered path (OpenTelemetry eBPF Instrumentation, aka OBI) can capture HTTP/gRPC spans and RED metrics with no code changes in Linux environments. For Go, a β auto-instrumentation effort uses eBPF to reduce toil further. The theme is consistent: lower the barrier to “first useful telemetry,” then iterate.
Reality check? eBPF is powerful and low-friction but not magic. InfoQ’s guidance still applies: validate tools, understand overhead characteristics, and verify behaviors under failure—ideally with a bit of chaos testing—before you blanket-enable across prod. (And yes, eBPF’s security cat-and-mouse continues; plan accordingly.)
At KubeCon + CloudNativeCon Europe 2025 in London, several vendors doubled-down on “OTel first” experiences, smoothing away boilerplate and promising less glue code. One example that drew coverage: Splunk’s enhancements aimed at simpler OpenTelemetry adoption and auto-instrumentation—specifically framed as scaling OTel usage in large environments. The point here isn’t product cheerleading; it’s market confirmation that the center of gravity has shifted to OTel—and that vendors now win or lose on how well they integrate with it, not how effectively they wall it off.
The community signal was loud inside the conference agenda too: official OTel project updates, sessions on adopting OTel where incumbent tools dominate, and hallway talk about managing Collector fleets with OpAMP. When conference schedules start reading like internal platform roadmaps, you know the “should we?” phase is over.
Backend teams embraced OTel years ago, but mobile lagged for good reasons: power, bandwidth, device constraints, and UX cost of noisy collection. That’s changing. Recent reporting indicates mobile OTel adoption is set to triple in the next 12–24 months, driven by a desire to unify RUM/app telemetry with backend traces and standardize on one schema. For SRE and DevOps, that’s big: user-journey traces that cross device → edge → microservices mean fewer “works-on-my-cluster” debates and faster MTTR for real customer paths.
CNCF voices have also been highlighting how mobile differs—collection has to be careful about battery, network variability, and sampling choices—and the community is sharing patterns to make that workable. Translation: don’t copy/paste backend sampling to iOS/Android and expect a happy App Store rating.
Proponents say OTel’s vendor-neutral stance and broad support make it the safest long-term bet. Stable logs/metrics models plus OTLP everywhere let you move data between backends, correlate signals consistently, and reduce agent sprawl. Fewer bespoke pipelines means fewer brittle points during incidents—and more time for the SRE work that actually prevents them.
Skeptics point to operational complexity (collectors, processors, fleet management), evolving semantic conventions, and the “data tax” of shipping everything. The ecosystem gap surveys from CNCF echo this: distributed systems are hard, integration is non-trivial, and teams often feel stuck navigating docs and switching stacks. Add eBPF’s power with its own verification burden, and you can see why platform teams sometimes hesitate.
Both sides are right. The trick is to treat OTel like a product you operate—not a checkbox. When teams align on that mindset, the debates sound less like “OTel vs. <favorite-tool>” and more like “What’s the minimal, meaningful telemetry we need, and how do we manage it like any other tier?”
Resist the urge to instrument everything on day one. Pick critical journeys—checkout, sign-in, key APIs—and implement consistent spans/attributes using your language’s best-supported path (Java agent, auto-instrumentation, or manual where needed). Fold in eBPF where it truly reduces toil (e.g., heterogeneous services you’re not ready to touch). Make “first useful signal in a sprint” your bar, not “perfect coverage.” Then iterate.
In practice: we’ve seen SREs apply the Java agent to 70% of services in a week, then spend the next sprint adding custom spans to the 30% that matter most. It’s not glamorous, but it beats a six-month rewrite of the universe.
Collectors are the unsung hero, but at scale they can turn into a config zoo. Treat them as a managed fleet. OpAMP—the Open Agent Management Protocol—lets you push config, credentials, and updates from a control plane, so changes don’t require N different playbooks. You wouldn’t run your service mesh without a control plane; don’t run your telemetry fleet that way either. O
Anecdote: one platform team moved from “ssh into boxes and pray” to an OpAMP-backed rollout model and cut change-related incidents on the observability tier to near zero. The SRE who used to carry the “Collector Whisperer” pager now sleeps.
Yes, “monitor everything” sounds noble—until your budget line starts competing with your Netflix subscription. Use head or tail sampling where appropriate; standardize on exemplars for SLO burn-rate dashboards; drop low-value attributes early in the pipeline; enforce TTLs that align to how you troubleshoot. Above all, align SLOs to telemetry collection so you aren’t paying for data you never use during incidents. (The community has been increasingly vocal that chasing moredata misses the point; you want better questions, not bigger bills.)
Engineers coming from backend land often port their sampling and attribute schemes to mobile—and then wonder why battery and network blow up. Start with sparse but high-value spans, keep payloads small, and push as much correlation as possible server-side. Make “user journey traces that cross device → backend” your north star, not “every tap and gesture.” That aligns with what’s actually driving mobile teams to OTel now: standardized correlation across the full path.
This is where human nature in IT rears its head. If every team names the same thing differently, your dashboards turn into a linguistics class. Treat the OTel semantic conventions like lint rules: publish patterns, run lightweight checks in CI, and make it easy to do the right thing. Future-you (and next quarter’s incident commander) will thank you.
When OTel becomes the shared language, incident response speeds up in very human ways. The backend dev stops arguing with the mobile dev about where a failure started because they’re literally looking at the same trace. The SRE on primary doesn’t need a Rosetta Stone for span attributes because the conventions are consistent. And the platform lead can move backends without re-instrumenting apps because OTLP is the contract.
This is also why the “vendor move” headlines matter. At KubeCon EU this spring, third-party coverage emphasized vendor efforts to streamline auto-instrumentation and scale OTel in large environments. Whether you deploy those specific products or not, the signal is: the market is rewarding investments that reduce OTel friction. That’s good for everyone on-call.
Are we okay letting eBPF hide inside our kernels if it saves six weeks of manual instrumentation—or do we require the same rigor we demand of sidecars and agents? (Bonus: who owns that risk model on your team?)
If mobile OTel adoption really triples, how do we balance “enough client-side signal to debug” with “don’t murder battery and data plans”? Where’s the sweet spot for sampling that still supports SLO burn analysis?
Who should own semantic conventions in a platform org—the SRE team, a cross-functional guild, or the “whoever filed the last PR” method we pretend is a process?
What’s your opinionated default for Collector fleet rollout and config drift: GitOps with OpAMP, or a more centralized, control-plane UI? How do you prove compliance in an audit?
The best compliment you can pay a telemetry system is forgetting it exists. If OTel does its job, the plumbing disappears, the data shows up where you need it, and your team stops arguing about agents and starts arguing about SLIs. That’s when you know the standard has won: when your incident runbook opens directly to “Find the broken user journey,” not “Which exporter did we use for Node v14 again?”
Sleep tight, pager people. The pipes are finally lining up.