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