Key takeaways
- Standard telemetry does not automatically create a coherent observability platform.
- Use repeatable collector and gateway patterns instead of per-team infrastructure.
- Govern cardinality, retention, sampling, and sensitive data at shared boundaries.
- Measure observability by faster operational decisions—not total signal volume.
The hard part moved from instrumentation to operation
OpenTelemetry standardised how applications emit and transport traces, metrics, and logs. As adoption expanded across browsers, mobile applications, services, Kubernetes, virtual machines, and databases, organisations discovered a second problem: every environment could be technically valid while the overall system remained inconsistent and expensive.
The OpenTelemetry Blueprints initiative responds with scenario-based architecture guidance and reference implementations. This is an important maturity signal. Enterprises need supported patterns for operating telemetry infrastructure, not another collection of component options.
Separate collection, processing, and storage responsibilities
A common cloud-native pattern uses node-local collectors for host, container, and log signals, then centralised collector gateways for batching, enrichment, filtering, sampling, and routing. Application teams instrument against stable OTLP endpoints while a platform team manages the shared processing layer.
The same principle applies outside Kubernetes. Local collection should remain close to sources that need buffering or host context; shared gateways should apply organisational policy before signals reach one or more observability backends.
- Keep application SDK configuration consistent and centrally supportable.
- Enrich resource identity once using agreed service, environment, region, and tenant attributes.
- Route security, audit, and high-value business signals under explicit retention policy.
- Avoid making every application know the credentials and schema of every backend.
Telemetry needs a data contract
Uncontrolled attributes create cardinality growth, accidental sensitive-data exposure, and dashboards that cannot be compared across teams. A platform should publish semantic conventions, approved enrichment, redaction rules, and ownership for high-value signals.
Sampling is also a product decision. Head sampling controls volume cheaply but lacks outcome context. Tail sampling can retain errors, slow transactions, or important customer journeys, but requires centralised state and capacity planning. The right design reflects investigation needs and cost constraints.
Run observability as an internal product
A successful platform has users, service levels, documentation, onboarding, change management, and cost visibility. Teams should know how to instrument a new service, diagnose missing signals, request a new attribute, and understand what the platform retains.
Platform owners should measure adoption quality rather than collector count: percentage of services with stable identity, trace-log correlation, actionable alerts, documented objectives, and tested incident workflows.
Start with one operational journey
Choose a critical request path that crosses the frontend, APIs, queues, workers, and database. Define service identity, propagate trace context, correlate logs, establish useful latency and error dimensions, and test the investigation workflow with operators.
Once the pattern works end to end, package it as a reusable blueprint. Standardisation becomes credible when it captures a proven operating decision, not when it is only a configuration repository.
Sources and further reading
About the author
Centillion Edge Engineering
Our engineering team writes about the architecture, security, data, and delivery decisions behind dependable enterprise systems.