Documentation menu
Counters and baselines
Convert counters, reduce or rank groups, and compare measurements with learned history.
Counter conversion, ranking and reduction
requests_total | rate by (agent_id)container_oom_kills | increase by (agent_id)host_process_cpu_percent | avg by (agent_id, process_instance) | sum by (agent_id)rate and increase require an exact counter metric. Cumulative samples are
differenced per original series before aggregation; resets contribute the new
value. Delta samples are summed. A missing predecessor contributes nothing; up
to an hour before the requested start is read for that predecessor. Rates divide
by bucket seconds for charts or window seconds for alerts. Counter queries use
raw data, not gauge rollups, and cannot use baseline stages.
A second sum/avg/min/max/count stage aggregates the first stage’s temporal results across a subset of its dimensions. This avoids summing repeated gauge samples. For changing service membership, prefer service metrics.
topk(10) keeps the largest ten aggregates per bucket or alert window, requires
grouping, and accepts 1–200. Membership may change; losing rank is not recovery.
Both ranking and reduction retain the input/query series limits. There is one
final transformation stage: reduction, topk, or baseline/deviation.
Learned baselines
http_check_total_ms | p95 by (target) | baseline(weekly_12w, p95)http_check_total_ms | p95 by (target) | deviation(weekly_12w)baseline draws a learned seasonal statistic in the metric’s unit; deviation
reports distance from its historical median in robust standard deviations.
Insufficient history yields no value while the profile learns.
These query stages use selector syntax. In a health rule, you can also choose
Against the baseline for a from query ending in pick for one measured
output, without joins or calculations. Use avg, min, max, or a percentile,
with stable IDs and recorded labels. Totals, counts, counter conversions,
reductions, and rankings require history of their evaluated outputs and are
not supported by sample-based baselines. See
baseline-based latency rules.
In Settings → Baselines, give a profile a friendly name such as “Business
hours”. Its query slug is generated automatically: business-hours. Slugs are
unique within your organization; duplicates receive -2, -3, and so on.
Use the slug in queries, for example | baseline(business-hours, p95).
Renaming a profile preserves its slug so saved queries and rules keep working.
Existing profiles and built-ins retain their original query identifiers.