What Are the 4 Pillars of Observability? Metrics, Events, Logs and Traces

When people refer to the four pillars of observability, they usually mean metrics, events, logs, and traces, collectively abbreviated as MELT. Metrics reveal patterns, events record meaningful changes, logs preserve detailed records, and traces follow work across a system. Cisco, for example, uses MELT as the data model for its observability platform, while Splunk uses the same four-part framework in its observability guidance (Cisco, Splunk).

That answer needs one qualification: there is no universal standard requiring observability to have exactly four pillars. Many sources use only metrics, logs, and traces. OpenTelemetry currently models events as a special kind of log, while continuous profiles are emerging as another signal. The pillar count depends on how a framework separates the data.

The useful question is therefore not only “What are the four pillars?” It is also “What can each signal tell me, and how do I connect them during an investigation?”

The four pillars at a glance

Suppose a checkout request has become slow. Each MELT signal gives you a different view of that problem.

These signals overlap. A deployment event may be stored as a log record, and a trace may contain events inside its spans. The categories are useful because they organize diagnostic questions—not because every observability system must store four completely separate types of data.

1. Metrics: Is the system behaving normally?

A metric is a numerical measurement captured over time. Common examples include request rate, error rate, response latency, queue depth, CPU utilization, and memory consumption.

Metrics usually compress many observations into a form that is efficient to aggregate, graph, and alert on. A counter can track the number of completed requests. A gauge can represent a value such as queue depth. A histogram can group request durations into buckets so you can inspect their distribution instead of relying only on an average.

In the hypothetical checkout incident, a latency metric provides the first clue: checkout requests are taking longer than their established baseline. An error-rate metric might also show that more requests are failing. These measurements tell the team that user-facing behavior has changed and identify the time window worth investigating.

Metrics rarely explain the complete cause by themselves. An aggregate can show that the 99th-percentile latency increased without identifying the affected request, code path, customer cohort, or recent change. Metric labels also need discipline. Adding values with many unique possibilities—such as raw user IDs or request IDs—can create high-cardinality series and increase storage and query costs. Grafana's cost guidance consequently recommends controlling metric cardinality and sending telemetry that has a defined observability purpose (Grafana).

Metrics narrow the investigation to a symptom and a period. Events add the next piece: what changed during that period?

2. Events: What changed at a specific moment?

An event is a named occurrence at a meaningful point in time. Deployments, configuration updates, feature-flag changes, service restarts, autoscaling actions, and job completions are all useful event candidates.

Events provide timeline context. If checkout latency rises shortly after a payment configuration changes, the deployment event gives the team a concrete hypothesis to test. It does not prove that the deployment caused the slowdown—two things occurring close together can still be unrelated—but it identifies a change worth comparing with the other telemetry.

OpenTelemetry's event conventions describe events as named occurrences such as state transitions, lifecycle moments, feature-flag evaluations, and exceptions. They also explain when another representation fits better: an operation with a duration should generally be a span, while a property describing an entire operation may belong on the span as an attribute (OpenTelemetry event conventions).

Are events different from logs?

Conceptually, the distinction is useful:

• An event emphasizes a meaningful occurrence with a name and defined structure.
• A log is the broader record that can contain a diagnostic message, attributes, severity, and other details.

At the data-model level, those categories may overlap. OpenTelemetry represents an EventRecord as a LogRecord with an event name. Its documentation summarizes the relationship plainly: events are a special type of log, but not every log is an event (OpenTelemetry logs).

This means you can treat deployment events as a distinct diagnostic concept without requiring a separate event database. What matters is that the occurrence has a stable name, accurate timestamp, and attributes that let you correlate it with the affected environment and service version.

3. Logs: What exactly happened?

Logs are timestamped records emitted by applications, operating systems, databases, network components, and other services. A useful application log often includes:

• Timestamp and severity
• Service and environment
• Deployment or build version
• A clear event name or message
• Relevant error and operation attributes
• Trace and span identifiers when a trace is active

In the checkout example, the payment service might record that a database connection timed out. The record can include the database operation, error type, service version, and the trace and span IDs for the request. Those fields make the log useful for both direct search and cross-signal navigation.

Structure matters more than encoding. A JSON log is not automatically well structured if different services use inconsistent field names and types. OpenTelemetry distinguishes structured logs with a stable schema from semistructured JSON or key-value records whose fields vary between emitters. Its log-record model also includes TraceId and SpanId, which allow a backend to connect a record with the active request trace (OpenTelemetry logs).

Logs also create operational risks. Verbose services can generate more records than a team can afford to retain or search. Payloads may contain personal, confidential, or security-sensitive information. A useful logging policy therefore defines which fields are allowed, which events deserve a record, how long records are retained, and how schemas stay consistent.

The same principle applies to AI systems. Krunal's guide to MLflow tracing for production AI agents shows how recorded retrieval steps, tool calls, inputs, outputs, and metadata help locate a failure inside a multi-step agent. The details differ from an HTTP checkout flow, but the diagnostic goal is similar: preserve structured evidence and connect it to the operation that produced it.

A log explains what one component recorded. To see how that component fits into the entire request, you need the trace.

4. Traces: Where did the request go?

A trace represents the path of one operation through a system. It contains one or more spans, where each span describes a unit of work such as an HTTP request, database query, queue operation, or function call. Parent-child relationships connect the spans into an execution path.

For the checkout request, a trace might include:

1. The API gateway receives the request.
2. The checkout service validates the cart.
3. The payment service authorizes the transaction.
4. The payment service queries its database.
5. The response returns through the previous services.

Span duration and status help locate where the request slowed down or failed. If most of the trace completes normally but the database span inside the payment service takes much longer, the team has a much narrower place to investigate. The database-timeout log attached to that span then supplies the detailed failure record.

This connection depends on context propagation. Each service and asynchronous boundary must pass the trace context forward; otherwise, the trace can break into unrelated fragments. Sampling creates another limitation. Retaining every trace may be too expensive at high request volumes, but an aggressive policy can discard the rare slow or failed request you need to inspect. Sampling should therefore follow the system's investigation needs rather than a universal percentage.

Traces are particularly useful when work crosses service, process, queue, or database boundaries, but they are not exclusive to microservices. A trace can still reveal nested work inside a monolith, background job, or AI workflow. For a broader discussion of what fails after a model moves beyond a notebook, see production monitoring and deployment.

How the four pillars work together during an incident

The following sequence is hypothetical. It demonstrates how connected telemetry could support an investigation; it is not a measured case study or a guaranteed troubleshooting recipe.

1. A metric reveals the symptom. Checkout latency rises above its normal range, and the error rate begins to change.
2. An event identifies a relevant change. The deployment timeline shows that payment configuration version 2.4.1 was released shortly before the change in behavior.
3. A trace locates the affected path. Slow checkout traces spend most of their time in a database span owned by the payment service.
4. A log supplies the component-level evidence. A log record attached to the slow span reports a database connection timeout and includes the active trace ID.

The four signals become one investigation only because they share context. Useful correlation fields include service name, environment, deployment version, region, timestamp, trace ID, and span ID. Kubernetes documentation makes the same broader point for its three primary signal types: aggregating and correlating metrics, logs, and traces creates a unified view of cluster and application behavior (Kubernetes).

Notice what this example does not prove. The deployment's timing alone does not establish causality. The team still needs to compare affected and unaffected requests, inspect the configuration, reproduce the behavior where possible, and verify that a correction changes the relevant signals.

Why do some sources list only three pillars?

Metrics, logs, and traces are the most widely repeated three-pillar model. Kubernetes documentation explicitly uses those three categories, and OpenTelemetry lists traces, metrics, logs, and baggage among the signals it currently supports (Kubernetes, OpenTelemetry signals).

MELT reaches four by treating events as a distinct conceptual category. OpenTelemetry instead represents a named event through its log data model. Neither approach makes the other useless: one organizes operational questions, while the other standardizes how telemetry is represented and transported.

Two additional terms complicate the count:

• Baggage carries contextual information across signals. It helps propagate values but is not usually called one of the classic observability pillars.
• Profiles record code-level resource consumption and execution. OpenTelemetry Profiles is currently alpha and is designed to correlate profile samples with traces, metrics, and logs (OpenTelemetry Profiles). Some platforms and authors therefore describe profiles as an emerging fourth signal.

The accurate answer depends on the framework:

• Use MELT when the question explicitly asks for four pillars: metrics, events, logs, and traces.
• Use metrics, logs, and traces when discussing the conventional three-pillar model.
• Treat profiles as an emerging additional signal, not as a universally accepted replacement for events.

The number is less important than defining the categories and their boundaries before using them.

The four pillars are not the four golden signals

The four golden signals are latency, traffic, errors, and saturation. Google's SRE book describes them as a focused set of measurements for monitoring a user-facing service (Google SRE).

They answer a different question from MELT:

Golden signals are commonly implemented as metrics. Those metrics can then lead an investigator to related events, logs, and traces. The two frameworks complement each other rather than compete.

How to implement the pillars without creating four data silos

Do not begin by sending every available signal to a different tool. Begin with the operational questions your team must answer: Is the service healthy? What changed? Which requests are affected? Where did they fail? What detailed evidence should be retained?

A practical starting sequence is:

1. Define important service behavior. Choose a small set of user-facing metrics, such as request volume, latency distributions, and error outcomes.
2. Standardize resource context. Use consistent fields for service name, environment, region, deployment version, and other attributes required for filtering.
3. Propagate trace context. Preserve trace and span identifiers across HTTP calls, messaging systems, jobs, and other boundaries.
4. Correlate logs with traces. Attach the active trace and span IDs to structured log records where the context exists.
5. Record meaningful change events. Capture deployments, configuration updates, feature-flag changes, restarts, and other occurrences that can explain a new time window.
6. Set data policies deliberately. Define metric-label limits, trace sampling, log retention, schema ownership, and sensitive-data controls.
7. Test the pivots. In a staging failure or controlled exercise, verify that an engineer can move from a metric to the related event, trace, and log without manually guessing identifiers.

OpenTelemetry provides common concepts and tooling for producing, processing, and exporting telemetry, but adopting it does not choose your operational questions or guarantee useful instrumentation. The signal definitions remain tools; the implementation still needs deliberate attributes, retention, and investigation workflows.

A small application may begin with structured logs and a few service-level metrics. Distributed or asynchronous systems often gain more from traces because a single operation crosses multiple boundaries. Adopt the signal that closes an actual diagnostic gap, then make it correlate with what you already collect.

Common observability-pillar mistakes

Treating collection as the goal

A platform can ingest metrics, events, logs, and traces while engineers still struggle to answer basic questions. Collection creates raw material. Observability requires usable context, queries, and investigation paths.

Giving each signal incompatible identifiers

If logs call a service payments, metrics use payment-api, and traces use payment_service_v2, automated correlation becomes unreliable. Standardize resource names and version attributes at instrumentation time.

Adding unlimited metric labels

Request IDs and user IDs are useful for individual investigation but usually make poor metric labels because they create many unique time series. Keep high-cardinality request context in records designed to support it, such as correlated traces and structured logs, unless your metric backend and cost model explicitly support the use case.

Recording logs without a stable schema

Machine-readable syntax is not enough. Field names, types, units, and semantics need consistency across services. Otherwise, every incident begins with parsing and normalization work.

Sampling without protecting valuable traces

Uniformly dropping traces can remove rare failures and tail-latency cases. Design a sampling policy around the requests and outcomes that matter, and verify what information is lost.

Splitting context across tools

Honeycomb argues that the classic pillar architecture can create multiple sources of truth and destroy useful relationships when each signal is stored independently. That is one vendor and practitioner perspective, not a universal architecture rule, but the underlying warning is practical: a unified interface cannot repair identifiers and context that were never captured (Honeycomb).

Ignoring privacy and retention

Logs and trace attributes can accidentally capture credentials, personal information, query text, or payload data. Decide what instrumentation may collect before sending it to a backend, and apply access and retention rules appropriate to the data.

The pillars are useful only when they connect

In the MELT framework, the four pillars of observability are metrics, events, logs, and traces. Metrics show changes in aggregate behavior. Events identify meaningful occurrences. Logs preserve detailed records. Traces follow an operation across its execution path.

The count is not universal, and no individual signal guarantees observability. Use the framework to organize questions, then preserve enough shared context to move between the answers. A smaller set of well-correlated telemetry is usually more useful than four large, disconnected stores.