# Metrics

> Gauges, sums, histograms and summaries in Pulse: how they're stored and which aggregations work on each.

Each OTLP data point becomes one row with the metric's `name`, `unit`, `service` (from `service.name`), `kind`, its start and end time, and its resource and point attributes.

| OTLP type | `kind` | `value` holds |
| --- | --- | --- |
| Gauge | `gauge` | The value |
| Sum | `sum` | The value, with `monotonic` and `temporality` (delta or cumulative) |
| Histogram | `histogram` | The sum, plus `count`, `min`, `max` and the explicit bucket bounds and counts |
| Exponential histogram | `exphistogram` | The sum, plus `count`, `min`, `max` and the exponential buckets |
| Summary | `summary` | The sum, plus `count` and the quantiles |

## Aggregations

A metric query picks one metric `name`, an `agg` and a `step` (bucket width in seconds, at least 10), and optionally filters on `attrs` and splits into series with `groupBy`.

| `agg` | Does |
| --- | --- |
| `avg`, `sum`, `min`, `max`, `count` | Over the values in each step |
| `rate` | Per-second increase. Cumulative monotonic sums use the difference between points, and a drop counts as a counter reset; delta sums are added up and divided by the step |
| `p50`, `p95`, `p99` | Percentiles on explicit-bucket histograms, interpolated within the bucket |

For histograms, `avg`, `sum` and `count` work on the histogram's sum and count.

## Names and series

`GET /api/v1/names?kind=metric&prefix=http.` lists the metric names seen in the last 7 days (`kind=service` lists services). The MCP tools `list_metric_names` and `list_services` do the same.

`groupBy` keys are looked up in the point's attributes, then the resource's. Each distinct combination is one series.

## Cardinality

Pulse charges by bytes, not series, so a high-cardinality attribute costs nothing extra to store. It does make queries slower when you group by it; group by the attributes you need.