By OpenTelemetry is in 95% of enterprise stacks, but the dirty secret is that most teams got there by copying configs from Stack Overflow and hoping for the best. The same project that solved observability vendor lock-in created a new problem: every team deploys it differently, context propagation breaks at service boundaries, and “just read the docs” isn’t an answer when the docs span 400 pages across 12 language SDKs. This week, OTel’s End User SIG shipped Blueprints — prescriptive, opinionated deployment patterns backed by real-world configurations from Adobe, Mastodon, and Skyscanner. It’s the “how you actually do it” layer that was always missing.
The Problem Blueprints Is Actually Solving
OTel’s complexity comes in two flavors. Essential complexity is unavoidable — the project spans applications, Kubernetes, infrastructure, databases, mobile clients, and a dozen languages. Accidental complexity is the problem: when teams adopt OTel organically, without centralized standards, you get fragmented telemetry pipelines, inconsistent semantic conventions, and context propagation that silently breaks at service boundaries.
The Collector deployment question alone trips up most teams. Kubernetes gives you three patterns — DaemonSet (one collector per node), Gateway (centralized aggregation deployment), and Sidecar (per-pod isolation). The recommended architecture is a two-tier DaemonSet-to-Gateway setup, but nothing in the official docs communicates that clearly or explains what to do when your security team demands sidecars. OTel field teams put it plainly: “Users often struggle building working configurations for real-world deployments.”
What a Blueprint Actually Is
Blueprints are not new documentation. That distinction matters. They’re connective tissue — pulling together existing architecture guidance, operational best practices, and implementation steps into a single, end-to-end playbook for a specific scenario.
Each Blueprint has three sections. The summary scopes the target audience and the specific challenges being addressed, so you know immediately whether it applies to you. The general guidelines provide architecture diagrams and design patterns proven to solve those challenges. The implementation section translates those patterns into concrete actions, with links to the existing docs that cover each step in depth.
They’re also living documents, not static configs. As tooling and operational practices change, the Blueprints evolve with them — which is the right call given how fast the OTel ecosystem moves.
What’s Available Now
Three Blueprints launched with the initiative:
- Kubernetes observability — The flagship. Covers monitoring your K8s clusters and control plane, which is where most teams have the deepest gaps.
- Non-Kubernetes infrastructure — For teams instrumenting bare metal, VMs, or managed services outside the cluster.
- Centralized telemetry platform architecture — The organizational pattern for teams building internal observability platforms.
Alongside Blueprints, OTel also launched a reference implementations library — a distinct but complementary concept. Where Blueprints are prescriptive patterns, reference implementations are snapshots of how real organizations actually set things up. Adobe, Mastodon, and Skyscanner have contributed their configurations, making this a community knowledge base that should compound in value as more organizations contribute.
Why This Is Happening Now
The timing isn’t random. Splunk’s OTel Collector v0.154.0 (June 16) dropped its legacy Agent Bundle, accelerating industry-wide consolidation on modern OTel patterns. AI agent observability is driving new requirements — async, non-deterministic traces that don’t fit neatly into existing patterns. Platform engineering teams building internal developer platforms need canonical configs to standardize across hundreds of services.
Blueprints for AI observability pipelines will almost certainly come next. The groundwork is being laid now.
What Developers Should Do Today
If you’re running OTel in Kubernetes, start with the Kubernetes Blueprint and compare it against your current Collector deployment. Most teams will find gaps — and now there’s a canonical answer for how to close them.
If your organization has invested deeply in OTel, the reference implementations are worth contributing to. The End User SIG accepts proposals via issue templates in the sig-end-user repository. The more real-world configurations in that library, the more useful it becomes for everyone.
OTel spent years building the standard. Blueprints is the project acknowledging that standards alone aren’t enough — you also have to be opinionated about how people use them. That’s a healthy sign of maturity, and it’s long overdue.
