The Challenge
A global commerce platform built around microservices generates observability data everywhere — logs, infrastructure and container telemetry, distributed traces, application metrics and cloud monitoring streams. As engineering teams move independently, instrumentation evolves independently as well.
More telemetry does not automatically create better observability. During a cross-service incident, engineers can still struggle to reconstruct the path from a customer-facing symptom to the infrastructure or service dependency that caused it, while the organization pays to ingest, process and retain a growing volume of data.
The challenge is therefore both operational and financial: how do you collect less unnecessary telemetry while making the remaining signals more useful during an incident?
Establishing a Common Telemetry Layer
OpenTelemetry provides an opportunity to separate instrumentation from the backend where telemetry is ultimately analyzed. Instead of allowing every team and vendor agent to define its own collection architecture, a common telemetry layer standardizes how logs, metrics and traces enter the observability platform.
Collectors provide controlled points for processing and routing, so the organization can decide which signals should be enriched, filtered, sampled or sent to different destinations without requiring every application team to redesign its instrumentation each time the backend changes. The objective is not OpenTelemetry adoption for its own sake — it is control over the telemetry pipeline.
Reducing Duplicate and Low-Value Telemetry
Once telemetry flows through a more consistent architecture, duplication becomes easier to identify: container logs repeating application events, infrastructure metrics collected by several agents, or traces captured at a sampling rate that makes sense technically but not economically.
The platform can apply policy closer to collection — high-value production signals remain available, repetitive or low-value data is filtered before expensive downstream processing, and trace sampling varies according to service criticality and error rate rather than a single global rate.
Improving Cross-Service Context and Team Guardrails
Cost reduction alone would not justify a telemetry redesign — the same architecture must improve incident investigation. Consistent service identity, environment metadata and correlation context make it easier to connect signals generated by different parts of a distributed transaction, reducing the manual correlation engineers perform during incidents.
A microservices organization cannot depend on one central team manually reviewing every new metric or log statement. Common semantic conventions, service naming, required resource attributes, sampling policies and pipeline standards create a baseline so teams can remain autonomous while telemetry stays sustainable — and a standardized layer also reduces coupling between instrumentation and any single observability vendor.
The Outcome
The target model creates a simpler relationship between application instrumentation and observability platforms:
- Common OpenTelemetry collection patterns
- Reduced duplicate and low-value telemetry
- Sampling and routing based on workload requirements
- Consistent service and environment context
- Better correlation across logs, metrics and traces
- Guardrails that scale across autonomous teams
- Reduced dependency between instrumentation and backend choice
- More predictable telemetry cost as the service landscape grows
The objective of a mature microservices observability platform is not maximum telemetry. It is the minimum telemetry architecture that still gives engineers the context required to diagnose production behavior quickly.