OpenTelemetry¶
CNCF project providing vendor-neutral APIs, SDKs, and the Collector for generating, collecting, processing, and exporting telemetry. This topic distills the official guidance program — the "Managed Telemetry Platforms for Kubernetes Workloads" blueprint and the three published production reference implementations (Adobe, Mastodon, Skyscanner) — into reusable architecture patterns.
Overview¶
The OpenTelemetry docs organize their best-practice material in two distinct categories under Guidance:
| Category | Nature | Purpose |
|---|---|---|
| Blueprints | Living documents, tightly scoped to one environment/problem | Solve common OTel adoption challenges; several may need combining |
| Reference implementations | Point-in-time snapshots of real organizations' pipelines | Ground blueprints in fact rather than theoretical advice; explicitly not actively maintained |
The reference-implementations initiative is driven by the Developer Experience (DevEx) SIG and was announced May 2026 with exactly three published entries. The End-User SIG runs the blueprint program; its "centralized telemetry platform" work item (sig-end-user issue #246) became the published K8s-workloads blueprint via site PR #10107 (merged 2026-06-24). This distinction matters operationally: blueprint guidance evolves with the project, while a reference implementation describes how one organization succeeded at a point in time.
Every claim distilled into this topic survived unanimous 3-vote adversarial verification against the live pages on 2026-08-27. See Architecture for the full pattern breakdown and Operations for deployment recipes.
Reference Implementations¶
| Organization | Tagline | Signature pattern | Scale |
|---|---|---|---|
| Adobe | An OTel pipeline designed for simplicity at scale | Three-tier pipeline with immutable sidecar + signal-isolated managed namespace | Enterprise, voluntary adoption |
| Mastodon | Running Collectors in production with a small team | One all-signals Collector per namespace as an Operator CR, deployed by Argo CD | ~300k daily actives, ~10M req/min |
| Skyscanner | Managing Collectors across 24 production clusters | Single DNS entry point + Istio nearest-available routing over Gateway/Agent tiers | 1,000+ microservices, 24 clusters, 6 platform engineers |
Evaluation¶
Quick pattern selection from the three cases plus the blueprint:
- Platform-engineering org running heterogeneous multi-tenant clusters → follow the managed-platforms blueprint: centralized horizontally scaled Collector Gateways, OTLP-only export, secrets confined to the gateway tier, Operator-first auto-instrumentation.
- Want zero restart risk for instrumented applications → Adobe's immutable sidecar config is specifically designed so config changes never bounce application pods.
- Tiny team, global scale, minimal moving parts → Mastodon proves one Collector per namespace behind the Operator + GitOps is "more than sufficient" — no tiers, no custom tooling.
- Migrating off fragmented vendors to a single backend without lock-in → Skyscanner's vendor-agnostic DNS endpoint keeps collector topology stable across backend swaps (they migrated 300+ services off OpenTracing by bumping one library version).
Position In The Vault¶
- OTel Collector — sibling component topic covering the engine internals (pdata, distributions, autoscaling, tail-sampling placement) that these organizational patterns deploy.
The patterns here produce telemetry that every backend topic in this domain consumes:
- SigNoz — OpenTelemetry-native unified platform on ClickHouse
- LGTM Stack — Grafana's Tempo/Mimir/Loki receiving OTLP directly
- Victoria Stack — VictoriaTraces/Logs accepting OTLP as drop-in replacements
- Apache SkyWalking — accepts OTLP alongside its own agent format
- Observability 2.0 — the wide-event critique of exactly the three-pillar pipeline this guidance standardizes
Relation to the Domain Hub
The domain hub's Key Concepts section describes the Collector receiver → processor → exporter pipeline generically; this topic covers the deployment topologies (gateway tiers, sidecars, per-namespace CRs) that that pipeline gets packaged into.
Sources¶
All URLs verified HTTP 200 on 2026-08-27 unless noted.
| Source | Kind | Note |
|---|---|---|
| Managed Telemetry Platforms for Kubernetes Workloads | Primary — blueprint | Core page researched here |
| Adobe reference implementation | Primary — ref impl | Published 2026-04-08 |
| Mastodon reference implementation | Primary — ref impl | Modified 2026-05-02 |
| Skyscanner reference implementation | Primary — ref impl | Modified 2026-07-14 |
| Guidance index | Primary | Defines blueprints vs reference implementations |
| Blueprints index | Primary | Lists published blueprints |
| Reference implementations index | Primary | Confirms exactly three RIs as of 2026-08-27 |
| Introducing OTel Blueprints and Reference Implementations | Primary — blog | Program announcement, 2026-05-12 |
| DevEx blog: Adobe | Primary — blog | Companion post |
| DevEx blog: Mastodon | Primary — blog | Companion post |
| DevEx blog: Skyscanner | Primary — blog | Companion post |
| Operator automatic instrumentation | Primary — docs | Verifies annotation names |
| Skyscanner Engineering on Medium | Primary — company post | Names New Relic; bot-gated (403 to non-browser clients), open in browser |
| InfoQ: Skyscanner observability migration | Secondary | Independent corroboration |
Questions¶
- Which concrete backends/exporters does Adobe's routing-connector setup support today, and can teams switch backends purely through Helm values? → see Architecture
- How do these pipelines handle gateway-tier failure modes — persistent queuing, memory-limiter tuning, cross-regional failover when Istio's "nearest available" pool degrades? → see Architecture
- Have the other two End-User SIG blueprints (non-Kubernetes instrumentation, Kubernetes observability) published since mid-2026, or has a fourth reference implementation joined the list? → re-check the blueprints index