Honeycomb supports three telemetry signals: traces, logs, and metrics. Each one answers different questions about your system. This page explains what metrics are, how Honeycomb handles them, and how to decide when metrics are the right tool.Documentation Index
Fetch the complete documentation index at: https://docs.honeycomb.io/llms.txt
Use this file to discover all available pages before exploring further.
What is a metric?
A metric is a numeric measurement of something in your system, captured at regular intervals over time. Where a trace or log describes what happened during a specific unit of work, a metric describes how something is performing over time: its state, its rate of change, or its distribution of values. Metrics are well suited to things you always care about and can measure consistently: the utilization of a host, the rate of requests through a service, the memory available to a container. Because metrics are pre-computed and structured at the point of collection, they are efficient to produce, store, and query at high volume, which makes them the right tool for continuous monitoring of known quantities, even at scale. Each individual measurement is called a data point. A time series is the sequence of data points for a single metric with a consistent set of attributes (for example, CPU utilization for a specific host over the past 24 hours). Honeycomb supports the following OpenTelemetry metric types:- Gauges: A snapshot of a value at a point in time, such as current memory usage
- Counters and sums: Cumulative or delta counts of something over time, such as total requests served
- Histograms: A distribution of values, such as request latency bucketed by duration
How metrics work in Honeycomb
Honeycomb is built on the OpenTelemetry Metrics Data Model, which means your existing OpenTelemetry metrics pipeline works without modification. If you are already sending OTLP metrics, you can point them at Honeycomb and start exploring your data immediately. No instrumentation changes are required. Honeycomb stores metrics in a dedicated metrics dataset, separate from your traces and logs, to keep your data organized and make querying more predictable. Honeycomb handles a few things automatically:- Automatic aggregation defaults: Honeycomb selects the appropriate temporal aggregate for each metric type. Counters and cumulative sums default to
RATE(), gauges default toLAST(), and histograms are handled as distributed structures. You can override these defaults in your queries. - Native histogram support: Honeycomb stores histograms as distributed data structures rather than pre-bucketed values. This enables accurate percentile calculations (p95, p99) and flexible merging across time windows and grouped dimensions.
- Query-scoped calculated fields: You can apply temporal logic directly in your queries without modifying your dataset schema.
How to query metrics
Querying metrics works the same way as querying any other data in Honeycomb. You use the Query Builder, filter and group by resource attributes, and visualize results as time series charts. Metrics queries support temporal aggregation functions, which account for the time-based nature of metric data:RATE(metric): Calculates the per-second rate of change of a counter or cumulative sumINCREASE(metric): Calculates the difference between the first and last values within each time step, accounting for counter resetsLAST(metric): Returns the most recent value for each time stepSUMMARIZE(metric): Sums all data points in a step, interpolating at step boundaries to avoid double-counting and gaps
How metrics work with traces and logs
Metrics and events aren’t mutually exclusive; tracking something as a metric and as a span attribute is sometimes the right call. Metrics give you high-resolution continuous data over time. Events give you the rich context of what happened in a specific request. Having both in Honeycomb means you can move between signals without switching tools.Correlations
When you run an events-based query, Honeycomb automatically surfaces relevant metrics in the Correlations view below your query results. For example, if you are investigating a latency spike, you can explore CPU utilization, memory usage, or network throughput for the relevant hosts alongside your query results. Correlations also appear at the span level in trace waterfalls, surfacing infrastructure metrics for the resource associated with a specific span. To learn more, visit Correlations.Metrics-based Triggers
You can alert on metrics data using the same Trigger system you use for events, with the same notification destinations and reliability. Metrics-based Triggers support temporal aggregation functions, so you can alert on rates and trends rather than just raw values. To learn more, visit Metrics-based Triggers.Boards
Add metrics queries to Boards alongside event queries to build a unified view of system health. To learn more, visit Boards.When to use metrics
Metrics and events serve different purposes and work best together. Use metrics when you want to:- Track the health and resource usage of infrastructure such as hosts, containers, and Kubernetes nodes
- Monitor high-volume numeric signals at regular intervals, such as request rates or error counts
- Alert on threshold conditions over time using rates and trends
- Get a continuous picture of known quantities: things you always care about, regardless of what any individual request is doing
- Understand what happened during a specific request or transaction
- Debug a problem by examining individual spans, errors, or log lines
- Ask open-ended questions across high-cardinality dimensions you didn’t anticipate in advance
- Identify outliers and unusual patterns using BubbleUp