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

# Metrics in Honeycomb

> Learn how Honeycomb handles metrics data, how metrics relate to traces and logs, and when to use metrics in your observability practice.

Honeycomb supports three telemetry signals: traces, logs, and metrics.
Metrics are the right tool for continuous monitoring of known quantities: infrastructure health, request rates, error counts, and other numeric signals you always care about, regardless of what any individual request is doing.

<Tip>
  If you are new to metrics or want to understand how Honeycomb thinks about metrics versus events, visit [Traces, Metrics, and Logs](/get-started/honeycomb/traces-metrics-logs/).
</Tip>

## How metrics work in Honeycomb

Metrics in Honeycomb are built around two core concepts: data points and time series.
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).
Changing any metric attribute value creates a different time series for that metric.
For example, CPU utilization grouped by `host.name` produces one time series per host.

### Supported metric types

Honeycomb supports the following [OpenTelemetry metric types](https://opentelemetry.io/docs/concepts/signals/metrics/):

* **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

### Connecting your metrics pipeline

Honeycomb is built on the [OpenTelemetry Metrics Data Model](https://opentelemetry.io/docs/concepts/signals/metrics/), 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.

### Automatic handling

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 to `LAST()`, 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.
* **Calculated fields:** Apply temporal logic and derived calculations directly in your queries without modifying your dataset schema, so you can compute ratios or rates on the fly.

## 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 sum
* `INCREASE(metric)`: Calculates the difference between the first and last values within each time step, accounting for counter resets
* `LAST(metric)`: Returns the most recent value for each time step
* `SUMMARIZE(metric)`: Sums all data points in a step, interpolating at step boundaries to avoid double-counting and gaps

To learn more about how temporal aggregation works and when to use each function, visit [Temporal Aggregation](/investigate/query/temporal-aggregation) and [Applying Temporal Aggregation Functions](/investigate/query/apply-temporal-aggregation).

Metrics queries also support *spatial aggregation* (comparing values across multiple time series at the same point in time) and [Query Math](/investigate/query/math), which lets you build multi-step queries with inline mathematical formulas to calculate ratios, percentages, and other derived values.

## How metrics work with traces and logs

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](/investigate/analyze/correlate).

### 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](/notify/triggers/metrics).

### Boards

Add metrics queries to Boards alongside event queries to build a unified view of system health.
To learn more, visit [Boards](/investigate/observe/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

Use events (traces and logs) when you want to:

* 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

In practice, you will often use both.
A metrics alert surfaces a problem; a trace investigation tells you why it happened.

## Metrics and your plan

Honeycomb measures metrics usage in *data points per month (DPPM)*.
Each plan includes a data point allotment on top of your event allotment.
To see the data point allotment for your plan, visit [Honeycomb Pricing Plans](https://www.honeycomb.io/pricing).

Honeycomb counts the metric observations you send, not the number of unique time series those observations belong to.
High-cardinality attributes, such as host IDs, pod IDs, or CI job IDs, can create many short-lived time series, but they do not add a separate per-series billing charge.
To understand what counts as a data point, visit [How Honeycomb Calculates Usage](/get-started/manage-costs/how-honeycomb-calculates-usage#how-we-define-a-data-point).

Data point usage is tracked and throttled independently from events, using the same overage model.
To learn how Honeycomb measures usage, handles overages, and applies burst protection for both events and data points, visit [How Honeycomb Calculates Usage](/get-started/manage-costs/how-honeycomb-calculates-usage).

## Next steps

* [Send application metrics to Honeycomb](/send-data/metrics/application)
* [Send system metrics with the OTel Collector](/send-data/metrics/system)
* [Set up a Metrics-based Trigger](/notify/triggers/metrics)
* [Correlate metrics with your event queries](/investigate/analyze/correlate)