The phrase "three pillars of observability" has been repeated so often that it risks becoming a platitude. Metrics, traces, and logs are necessary. They are not sufficient. In a microservice architecture with dozens or hundreds of services, the volume of telemetry is enormous and the relationships between signals are complex. An engineer investigating a latency spike needs to move from an anomalous metric to the specific traces that exhibit the problem to the log lines that explain it, all within minutes. If these signals live in separate systems with no correlation, the investigation becomes a manual join across three query interfaces. That is not observability. That is data archaeology.

This article examines what unified observability means in practice for microservice architectures, how OpenTelemetry provides a standardisation layer, where AI-assisted analysis is delivering genuine value (and where it is not), how to manage the cost of observability at scale, and the implementation patterns that make the difference between a telemetry pipeline and an operational tool. These themes build directly on the foundational observability concepts covered earlier, the request timing phases that traces need to capture, and the multi-cloud observability challenges that arise in heterogeneous infrastructure.

Beyond the three pillars

Metrics tell you that something is wrong. Traces tell you where in the request path the problem occurs. Logs tell you why. This framing is useful as a starting point but breaks down in several ways.

First, the signals overlap and interact. A metric showing elevated error rates is most useful when it links to example traces exhibiting those errors (exemplars). A trace is most useful when each span links to log entries generated during execution. Without these links, the three pillars are separate data stores that happen to describe the same system.

Second, there are signals that do not fit neatly into any pillar. Profiling data (CPU flame graphs, memory allocation traces) reveals problems that metrics detect but cannot explain. Runtime events (garbage collection pauses, thread pool exhaustion) are critical for diagnosing latency outliers but live outside the standard taxonomy.

Third, the volume problem is asymmetric. Metrics are compact. Traces generate enormous volumes at high fidelity. Logs can explode when debug logging is accidentally left enabled in production. A unified strategy must account for these different cost profiles.

The practical consequence is that "we have metrics, traces, and logs" is the beginning of an observability strategy, not the end. The value comes from the connections between signals.

Unified observability in practice

Unified observability means that an engineer can start from any signal and navigate to related signals without leaving the observability platform or performing manual correlation.

Exemplars attach trace IDs to metric data points. When a metric shows a p99 latency spike or error rate increase, the engineer clicks through to specific traces that contributed. This eliminates the guesswork of "which traces should I look at?" Prometheus supports exemplars natively, and most commercial platforms have adopted the pattern.

Trace-to-log linking embeds trace and span IDs into every log entry. When viewing a trace, the engineer can expand any span and see the log lines generated during that span's execution. OpenTelemetry's logging bridge handles this automatically for supported frameworks, injecting context without code changes.

Service maps generated from trace data show runtime topology: which services call which, at what rate, with what error rate and latency. An elevated error rate on the map immediately reveals which service is affected and which callers are impacted.

Correlation by time and resource fills gaps where explicit links do not exist. If a latency spike on service A coincides with a CPU saturation event on the host running service B, temporal correlation suggests a relationship. Unified platforms that store all signal types in a common time-indexed backend can surface these correlations automatically.

The implementation cost is not trivial. It requires consistent instrumentation, a pipeline that preserves correlation identifiers, and a backend supporting cross-signal queries. But the alternative, three separate tools with no links, does not scale.

OpenTelemetry as the foundation

OpenTelemetry has become the de facto standard for instrumentation and telemetry collection: instrument once, export to any backend. The SDK provides APIs for traces, metrics, and logs across all major languages. Auto-instrumentation captures telemetry from common frameworks without code changes. The OpenTelemetry Collector receives, processes, and exports telemetry to one or more backends, decoupling instrumentation from the choice of platform.

Several aspects are particularly valuable for microservice observability.

  • Context propagationOpenTelemetry propagates trace context using W3C Trace Context headers by default. Traces connect across services regardless of language or platform, eliminating a category of integration problems.
  • Semantic conventionsOpenTelemetry defines standard attribute names for common concepts: HTTP method, URL, status code, database system, messaging destination. When all services use the same attribute names, queries and dashboards work consistently across the entire fleet. Without semantic conventions, every team invents its own attribute names and cross-service analysis requires constant translation.
  • Resource detectionThe SDK detects the runtime environment (cloud provider, region, container ID, Kubernetes namespace) and attaches resource attributes to all telemetry, enabling filtering and grouping across deployments.
  • Baggage propagationBeyond trace context, OpenTelemetry propagates arbitrary key-value pairs across service boundaries: customer tier, request priority, experiment variant. This context is available downstream for logging, sampling, or routing decisions.

OpenTelemetry maturity varies by signal. Tracing is most mature. Metrics are stable. Logging reached stability recently and adoption is growing. Start with tracing, add metrics, and integrate logging as the ecosystem matures.

AI-assisted observability

AI-assisted analysis is the most hyped area of observability in 2026. Separating genuine value from marketing noise requires looking at what specific tasks AI handles well and where it falls short.

Anomaly detection on metrics is the most mature application. ML models trained on historical data detect deviations more reliably than static thresholds. A service whose p99 latency is normally 50 ms on weekday mornings but 120 ms after Monday batch jobs needs adaptive thresholds. ML-based detection handles seasonal patterns, reducing false positives and missed detections.

Automated root cause suggestions correlate anomalies across signals and propose probable causes. If elevated errors on service A coincide with a deployment on service B and a database CPU spike, the system suggests the deployment as the likely cause. These suggestions are helpful starting points but should not be trusted blindly. Correlation is not causation.

LLM-assisted log analysis is newer and more experimental. Large language models can summarise log data and identify error patterns, but quality depends heavily on log structure. Structured JSON logs produce much better results than free text. LLM inference latency limits real-time use during incidents; batch analysis and post-incident summarisation are more practical today.

Predictive alerting uses trend analysis to warn before a threshold is breached. If disk usage grows at 2% per day from 78%, the system can predict exhaustion in 11 days and alert proactively. Straightforward time-series forecasting, but valuable because it shifts alerting from reactive to anticipatory.

The honest assessment: AI-assisted observability reduces noise, accelerates triage, and handles volume. It does not replace engineers who understand the architecture. The agentic AI governance discussion applies here: AI tooling works best when it augments human judgment rather than attempting to replace it.

Cost management

Observability at microservice scale is expensive. Telemetry volume scales super-linearly with service count because each interaction generates data on both sides. Without deliberate cost management, observability spending can rival the infrastructure cost of the services being observed.

  • Sampling strategiesNot every trace needs to be stored. Head-based sampling decides at the trace root whether to keep or drop the entire trace. Tail-based sampling waits until the trace completes and keeps traces that are interesting (errors, high latency, specific attributes). Tail-based sampling is more efficient because it keeps the traces you actually need, but it requires a collector that buffers complete traces before making the decision, adding infrastructure complexity.
  • Tiered storageRecent telemetry data (last 24 to 72 hours) should be in hot storage with fast query performance. Older data, retained for trend analysis or compliance, can move to cheaper cold storage with slower query times. Most observability platforms support retention tiers. Configuring them correctly, based on actual usage patterns rather than defaults, can reduce storage costs by 50% to 80%.
  • Cardinality controlHigh-cardinality attributes (user IDs, request IDs, IP addresses) in metrics create enormous numbers of time series, which drives up storage and query costs. Metrics should use low-cardinality dimensions. High-cardinality data belongs in traces and logs, which are designed for it.
  • Collection filteringNot all telemetry is equally valuable. Debug-level logs from a healthy service during steady state generate volume without value. The OpenTelemetry Collector's processor pipeline can filter, drop, or downsample telemetry based on attributes, reducing the volume that reaches the backend. Filtering at the collector is cheaper than filtering at the backend because it avoids ingestion and indexing costs.

The cost conversation should happen at the architecture level, not as an afterthought. Teams that define telemetry requirements alongside service architecture make better cost and coverage trade-offs than those that instrument everything first and worry about cost later.

Implementation patterns

Adopting unified observability across a microservice fleet is an incremental process. Attempting a big-bang migration from existing tooling to a new stack rarely succeeds. The following patterns reflect what works in practice.

Shared instrumentation libraries wrap the OpenTelemetry SDK with organisation-specific defaults: standard resource attributes, sampling configuration, approved exporters, and span naming conventions. Service teams import the library and get correct instrumentation without understanding OpenTelemetry internals. This is the single most effective lever for consistency.

Service mesh integration (Istio, Linkerd, Cilium) provides baseline observability for all service-to-service communication without application instrumentation. The mesh proxy generates metrics and traces for every request. Application-level instrumentation adds detail: database queries, cache lookups, business logic spans.

SLO-based alerting replaces threshold-based alerting on raw metrics. Alert when the error budget for the checkout SLO is being consumed too fast, not when CPU exceeds 80%. SLO-based alerts are more meaningful and produce fewer pages. The performance regression checklist provides a structured approach to investigating the regressions they surface.

Progressive rollout with observability gates ties deployment decisions to telemetry. A canary deployment can automatically promote or roll back based on whether the canary's SLIs meet the SLO. The deployment pipeline becomes a consumer of observability data, not just a producer.

Runbook links in alerts connect notifications directly to investigation workflows. Every alert should link to a runbook describing what it means and how to mitigate. Teams that maintain this link resolve incidents faster. Those that treat runbooks as wiki documentation rediscover troubleshooting steps from scratch each time.

Unified observability for microservices is not a product you purchase. It is a capability built from standards-based instrumentation, deliberate signal correlation, cost-aware collection, and workflows that move engineers from detection to resolution quickly. The tooling has matured with OpenTelemetry's stabilisation. The remaining challenge is organisational: ensuring consistent instrumentation, correlation identifiers flowing across every boundary, and data serving people during incidents rather than sitting in dashboards nobody checks.

Related notes

Back to topic • Back to Notes index