What is MELT?

#What each data type provides

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.

#How telemetry signals work together

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.

#Limits and cost

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.

#MELT vs the three pillars

"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.

#Key takeaways

• MELT is a mnemonic for four common telemetry forms, not an exhaustive or standardized definition of observability data.
• Each type is optimized for different questions, with some overlap between them.
• Change events can provide valuable context for incidents that follow deployments, configuration changes, or infrastructure changes.
• Shared identifiers across signals are what make them useful together rather than separately.

#Frequently asked

Which data type gives the most value per dollar?

Metrics are efficient for detection and events are inexpensive relative to their diagnostic value. The right mix depends on the systems involved and how problems tend to surface.

How do you control log costs?

Sampling high-volume routine logs, keeping errors unsampled, tuning retention and indexing, and moving per-request detail into traces are common approaches.

Why are events called out separately?

Because change context is frequently useful during investigation, and treating deploys as ordinary log lines can make that signal harder to find. Some standards still model events as logs.

#Sources

• OpenTelemetry: signals