48.9k
MELT is an observability data model that groups telemetry into four types (metrics, events, logs, and traces) so teams can name every signal a system emits. New Relic popularised the acronym, extending the three pillars of observability (logs, metrics, traces) with a fourth type: events, structured records of significant state changes.
The framing appears in New Relic's white paper "MELT 101: An introduction to the four essential telemetry data types" and its platform documentation, which organises all ingested data into those four categories. The three-pillars model it extends dates to Peter Bourgon's February 2017 essay "Metrics, tracing, and logging"; MELT's contribution is promoting events from an afterthought to a first-class telemetry type.
What does each MELT data type capture?
Each of the four types records a different slice of system behaviour.
| Type | What it is | Data shape | Example |
|---|---|---|---|
| Metrics | Numeric measurements aggregated over time | Time series: name + labels + values per interval | checkout_error_ratio = 0.004 at 09:14 |
| Events | Structured records of significant state changes | One record per occurrence, with a defined name and attributes | deployment.finished with version=2.41.0, service=checkout |
| Logs | Free-form diagnostic output from code paths | Timestamped text or JSON lines with arbitrary fields | "payment declined" with order_id=8123, provider=stripe |
| Traces | One request's path across services | Tree of timed spans sharing a trace ID | POST /charge span, 1,840 ms, status ERROR |
Metrics are the cheapest to store and alert on because aggregation happens at write time; the cost is that dropped dimensions are unrecoverable. Traces, standardised by OpenTelemetry, the CNCF instrumentation project, show where latency lives across service boundaries. Logs carry the richest context per record. Events sit between logs and metrics: individually meaningful like a log line, structured and countable like a metric.
What is the difference between an event and a log?
An event is a structured record of a significant, discrete state change (a deployment, a payment, a scaling action) with a defined name and schema. A log is free-form diagnostic output a developer emits to explain a code path. Every event could be logged; most log lines record detail too routine to call an event.
The distinction is intent and structure, not storage. OpenTelemetry makes this explicit: in its logs data model, an event is a log record with an EventName field, and its semantic conventions for events require each event name to uniquely identify a documented attribute structure. Structurally, an event is a log that made a commitment to schema, which is why it can be aggregated, joined, and alerted on like a metric while retaining per-occurrence context.
How does MELT differ from the three pillars of observability?
MELT contains the three pillars of observability (logs, metrics, traces) and adds events as a fourth type. The two models otherwise make the same move: they categorise telemetry by data shape. Neither says anything about whether those shapes can be queried together, which is what separates monitoring from observability in practice.
Adding events is a genuine improvement in vocabulary. Deployments, config changes, and feature-flag flips are the highest-value correlation points in most incidents ("what changed at 09:12?"), and the three-pillars model gave them no home. Teams either buried them in logs, where they drowned in routine output, or lost them entirely.
Where does the MELT model break?
Four telemetry types stored in four separate systems have the same correlation problem as three; this critique is ClickHouse's editorial position, and the definitions above stand without it. MELT inherits the pillars' central weakness: it categorises data types, then vendors turn each category into a separate store with its own query language, and engineers correlate across them by hand during incidents.
A metrics store, a log search engine, a trace backend, and now an events service means four ingest pipelines, four retention policies, and an engineer copy-pasting timestamps and trace IDs between four tabs at 3 a.m. The taxonomy improved; the silo count went up.
How do wide events reconcile the four MELT types?
A wide event is one high-cardinality record per unit of work, with enough columns to carry what MELT scatters across four systems: metric values become aggregations over the rows, log context rides along as fields, and trace and span IDs make each row part of a trace. One event stream, queried ad hoc, serves all four roles. A single wide event for a declined payment looks like this:
{
"timestamp": "2026-07-28T09:14:07Z",
"trace_id": "4bf92f35", "span_id": "00f067aa",
"service": "checkout", "event.name": "payment.declined",
"duration_ms": 1840, "status_code": 402,
"order_id": 8123, "provider": "stripe", "deploy_version": "2.41.0"
}The row above is simultaneously a log (diagnostic context), an event (payment.declined, structured), a metric source (avg(duration_ms), error ratios), and a trace fragment (trace_id). Structurally it is a structured log that grew enough columns to do all four jobs. ClickHouse's internal logging platform passed 100 petabytes and 500 trillion rows on wide events, cutting pipeline CPU by 90% in the process.
How ClickStack handles MELT data
ClickStack, the ClickHouse observability stack, stores all four MELT types in a single ClickHouse database rather than four per-type systems. OpenTelemetry handles instrumentation and collection, ClickHouse stores metrics, events, logs, and traces as wide columnar rows, and HyperDX, the stack's UI, searches and charts them from one place, so correlating across types takes one query. High-cardinality event attributes (order IDs, customer IDs, deploy versions) are ordinary columns, which is what makes treating events as first-class telemetry affordable.
Frequently asked questions
What does MELT stand for in observability?
MELT stands for metrics, events, logs, and traces: the four telemetry data types a system emits. Metrics are aggregated numeric time series, events are structured records of significant state changes, logs are free-form diagnostic records, and traces follow individual requests across services as trees of timed spans.
Who coined the term MELT?
New Relic popularised MELT through its "MELT 101" white paper and built its telemetry platform documentation around the four types. The acronym extends the three-pillars framing (logs, metrics, traces) that Peter Bourgon's February 2017 essay "Metrics, tracing, and logging" introduced.
Is MELT the same as the three pillars of observability?
No. MELT contains the three pillars (logs, metrics, traces) and adds events as a fourth telemetry type. Neither model guarantees observability: a team can collect all four types in four silos and still struggle to correlate them during an incident.
Are events and logs the same thing?
No, though they share a data model. An event is a structured record of a significant state change, with a defined name and attributes; a log is free-form diagnostic output. OpenTelemetry represents an event as a log record carrying an EventName field whose attribute structure is documented in semantic conventions.
To query metrics, events, logs, and traces in one store, ClickStack is open source and runs locally; the getting started guide takes one Docker command.
