What is MELT?

Metrics are numeric measurements captured and commonly aggregated over time. They are efficient for trends, thresholds, dashboards, and alerting; exemplars and shared context can connect an aggregate measurement to individual traces. Events are discrete records of something that happened, such as a deployment or scaling action. Depending on the telemetry model, an event may be represented as a log record or as an event attached to a trace.

Logs record events or messages with timestamps and attributes. Traces represent the path of an operation through one or more components and help show where time was spent or an error occurred. The boundaries are implementation-dependent, and correlation matters more than forcing every record into a rigid category.

Different signals answer different questions, and investigations often move between aggregate measurements and detailed records. Metrics may show when behavior changed; deployment or configuration events may show what changed nearby; traces may localize a problem within a request path; and logs may provide component-level detail.

This is a common pattern, not a required sequence. An investigation may begin with a trace, log, customer report, profiler, security signal, or another source depending on how the problem was detected.

Volume and cost differ substantially across the four. Metrics are relatively cheap and compress well. Logs can become a major observability expense at high volume, depending on retention, indexing, sampling, and vendor pricing. Traces require sampling decisions that risk discarding the requests you most want to see.

Correlation is the other difficulty. The four types are most useful together when they share identifiers, and telemetry where a trace cannot be connected to its logs leaves each type isolated in its own tool.

"Metrics, logs, and traces" is another common observability mnemonic. MELT calls out events separately because change and lifecycle events are often valuable during incident investigation.

Some telemetry standards model events as a type of log, so the distinction is a practical organizational choice rather than a universal taxonomy. What matters operationally is that change context is easy to find on the same timeline as the symptom, however it is stored.