# The 3 pillars of observability: logs, metrics and traces > Logs, metrics and traces form the three pillars of observability. Strengths, limits, correlation and unification through OpenTelemetry: the 2026 guide. - Date : 2022-01-06 - Lecture : 9 min - Catégorie : devsecops - Tags : Observability, Logs, Metrics, Tracing, OpenTelemetry, Monitoring, Microservices, SRE - URL : https://www.adservio.fr/en/insights/articles/les-3-piliers-de-l-observabilite ## TL;DR - Observability goes further than monitoring: it answers unforeseen questions by inspecting and correlating the signals a system emits. - Logs offer the granularity to debug, metrics summarise behaviour over time, traces reconstruct the path of a request across all services. - No pillar is useful on its own: value comes from correlation, trace_id in logs, exemplars linking metrics and traces. - OpenTelemetry, a graduated CNCF project, has unified the three pillars with one SDK, the OTLP protocol and shared semantic conventions; continuous profiling is joining as a fourth signal. - Operational AI (AIOps, incident-triage agents) is only as good as the telemetry underneath it. - Cost-efficient observability requires governance: sampling, filtering at the source, tiered retention and cardinality control. ## Observability and monitoring: what really changes for your systems Observability is the ability to understand the internal state of a system from the signals it emits, without having to predict every failure mode in advance. As companies migrate to the cloud, multiply microservices and put AI inference chains into production, visibility into performance data becomes both more critical and harder to obtain: a single request can cross dozens of services before producing a response, and every link is a potential point of failure. Monitoring answers the questions you knew to ask: a dashboard displays chosen indicators, an alert fires when a threshold is crossed. Observability goes further: it provides the tools to inspect and correlate data in order to answer the questions nobody had anticipated, the famous unknown unknowns. That exploratory capability is what makes the difference when a never-seen-before incident hits at three in the morning and the time to resolution is measured in lost revenue. Logs, metrics and traces are considered the three pillars of observability, because none of them is truly useful without the other two. In 2026, this triad is being joined by a fourth signal, continuous profiling, and above all by a common foundation, OpenTelemetry, which has put an end to the fragmentation of proprietary formats that until recently complicated every instrumentation strategy. ## Logs: the granularity debugging depends on An event log pairs a timestamp with context: what happened, where, with which values. Logs exist in binary, structured or plain-text form, and remain the easiest pillar to generate, virtually every language and framework produces them natively. Their strength is granularity: when a rare bug affects only one user in ten thousand, only the log holds the detail needed to reconstruct the exact scenario, with the parameters, the state and the precise sequence of operations. ### Moving to structured logging In modern production, free text is no longer enough: structured logs, usually in JSON, carry normalised fields, request identifier, trace_id, tenant, service version, that make them queryable like a database and correlatable with traces. This discipline turns a pile of lines into an exploitable analysis source, including for AI diagnostic agents, which need reliable fields to reason about an incident. ### Keeping log volume and cost under control The limits of logs are well known: volume that explodes with traffic, indexing and storage costs that can exceed those of the infrastructure being observed, and an inability to pinpoint the root cause on their own in a distributed system. Modern collection pipelines answer with filtering at the source, sampling of repetitive messages and tiered storage: hot data stays indexed for search, while archives move to cheap object storage where they remain rehydratable for audits. ## Metrics: summarising system health over time Metrics are aggregated numerical values that summarise behaviour and performance over time: 99th-percentile latency, error rate, resource saturation. Cheap to produce and store, easy to query, they power real-time dashboards, alerting and above all SLOs, which turn reliability into quantified objectives shared between product and engineering teams. Prometheus and its PromQL language remain the de facto standard of the cloud-native ecosystem, now fully interoperable with OpenTelemetry collection. Metrics are also what establish the benchmarks of normal operation: without a historical baseline, there is no way to know whether 300 milliseconds of latency is an incident or the usual Friday-evening behaviour. This long memory, cheap to keep, makes metrics the first pillar to set up when starting from scratch. To choose what to measure, two frameworks have proven themselves: the SRE's four golden signals, latency, traffic, errors, saturation, for user-facing services, and the USE method, utilisation, saturation, errors, for infrastructure resources. Starting from these frameworks rather than exporting every available metric avoids the four-hundred-graph dashboards nobody ever looks at, and focuses alerting on the symptoms that actually affect users rather than on internal causes with no impact. ### The cardinality trap The flip side of this efficiency is generalisation: a metric says how many users suffered, never which ones. And adding overly fine labels, customer identifier, full URL, makes cardinality explode, and with it the memory footprint of the time series and the bill. The proven rule: lean metrics to detect, traces and logs to explain, and exemplars to jump from one to the other in a single click. ## Distributed traces: following every request end to end A trace represents the series of events triggered by a request as it travels through all of your systems. Broken down into spans, one per operation, with duration, status and metadata, it makes visible the structure and the actual path of a call: which service added eight hundred milliseconds, which dependency timed out, where the queue built up. In a microservices environment, it is the only pillar able to reconstruct causality across dozens of components that do not know each other. ### Context propagation and sampling Tracing requires every component to propagate the request context, the W3C Trace Context standard handles this in HTTP headers, and its cost is kept in check by sampling: head-based for simplicity, or tail-based to systematically retain slow or failed transactions. Even partial instrumentation already yields valuable insights, and the automatic instrumentation shipped with modern SDKs drastically lowers the entry ticket: a few lines of configuration are enough to cover the most common web frameworks, HTTP clients and databases. Traces also yield precious by-products: automatically generated dependency maps between services, metrics derived from spans, latency and error rate per operation, and the detection of unexpected dependencies introduced by a deployment. Many teams discover their real architecture by instrumenting tracing, and it often sits quite far from the official architecture diagrams. > Related read: [Observability patterns for distributed systems: logs, metrics, traces and profiles](https://www.adservio.fr/en/insights/articles/patterns-observabilite-systemes-distribues): Logs, metrics, traces and profiles: the observability patterns that make a distributed system understandable, with OpenTelemetry as the common standard. ## OpenTelemetry: the standard unifying logs, metrics and traces The major evolution of the decade is standardisation. OpenTelemetry, a graduated CNCF project, provides a per-language SDK, a single transport protocol (OTLP) and shared semantic conventions for the three pillars, all three stable and generally available. Instrumenting once and freely choosing your backend, open source or commercial, puts an end to the proprietary lock-in of legacy APM agents, and the OpenTelemetry Collector acts as a single gateway to filter, enrich and route telemetry. ### Continuous profiling, the fourth signal Since March 2026, OpenTelemetry's profiling signal has been in public alpha, with general availability targeted within the year. Collected continuously via eBPF with minimal overhead, it shows which function is consuming CPU or memory, and correlates with traces through trace_id and span_id. The triad becomes a quartet: traces locate the offending service, profiling drills down to the responsible line of code, with no redeployment and no manual instrumentation. For organisations still running proprietary agents, migration happens in stages: deploy the Collector as a gateway in front of the existing backend, switch service by service to the OpenTelemetry SDKs, then rationalise the backends once collection is unified. The instrumentation investment is thus preserved whatever the later tooling choice, a complete reversal of the balance of power with observability vendors. ## Correlating signals: from raw data to actionable insights Three pillars stored in three silos do not make observability: value comes from correlation. An alert on a metric should open the traces involved; a slow trace should expose its logs; an error log should lead back to the originating request. Shared identifiers, trace_id injected into every log line, exemplars linking metrics and traces, turn three databases into a single navigable graph, and divide diagnosis time accordingly. This is also where AI is changing day-to-day practice: AIOps platforms correlate signals at scale, group redundant alerts into single incidents and propose root-cause hypotheses, while LLM agents handle a first triage of alerts before the human on-call. These systems, however, are only as good as the telemetry they are fed: without well-instrumented, semantically consistent pillars, there is no useful operational AI. In practice, a correlated diagnosis looks like this: an SLO alert flags a rise in 99th-percentile latency; the exemplar attached to the metric opens a representative trace; the trace shows that a database call is consuming most of the time; the logs of the span in question reveal a degraded query plan after a migration. Four signals, one single thread, a few minutes instead of a few hours of blind searching. > Related read: [What is AIOps?](https://www.adservio.fr/en/insights/articles/qu-est-ce-que-l-aiops): AIOps in 2026: definition, data ingestion and correlation, anomaly detection, generative agents for incident response, platforms (Datadog, Dynatrace, ServiceNow), benefits and challenges. ## Implementing cost-efficient observability with Adservio The three pillars form a whole: traces connect logs, metrics reveal overall health and performance, and together they form the foundation of an observable system. That leaves the question of cost, now central: telemetry can represent a significant share of the cloud bill if left ungoverned. Sampling tuned to criticality, filtering in collection pipelines, retention periods differentiated per signal and regular cardinality reviews keep the balance between value produced and money spent. At Adservio, we help organisations achieve observability of their systems by building on open standards and best practices: OpenTelemetry instrumentation, SLO definition, signal correlation and cost control, while avoiding costly pitfalls and anti-patterns. The more complex a system, the more it needs observability, and the more its implementation benefits from being guided by field experience rather than by piling up tools. > Related read: [Bridging the SRE Gap: Toward Autonomous Observability and AI-Agent Root Cause Analysis](https://www.adservio.fr/en/insights/articles/combler-l-ecart-sre-vers-l-observabilite-autonome): Autonomous observability: how an AI agent correlates logs, metrics and traces to automate root cause analysis and cut MTTR from hours down to minutes. ## FAQ ### What are the 3 pillars of observability? Logs, metrics and traces. Logs bring the granularity to debug, metrics summarise behaviour over time, and traces follow a request across all systems. None is truly useful without the other two. ### What is the difference between monitoring and observability? Monitoring answers the questions you knew to ask, through dashboards and alert thresholds. Observability goes further: it lets you inspect and correlate signals to answer unforeseen questions and diagnose never-seen-before incidents. ### What does OpenTelemetry bring to the three pillars? OpenTelemetry, a graduated CNCF project, unifies logs, metrics and traces with a per-language SDK, the OTLP protocol and shared semantic conventions. You instrument once and freely choose your backend, with no proprietary lock-in. ### Is continuous profiling a fourth pillar? Yes, it is establishing itself as a fourth signal: in public alpha at OpenTelemetry since March 2026, collected via eBPF with minimal overhead, it links traces to the line of code consuming CPU or memory. ### Why is tracing harder to implement? Because it requires every component to propagate the request context, standardised by W3C Trace Context. Head-based or tail-based sampling keeps its cost in check, and a partial implementation already provides valuable insights in microservices environments.