Coverage-first or cost-first: two ways to automatically apply Adaptive Metrics' recommendations¶
Summary¶
Grafana Labs' Adaptive Metrics (part of the Adaptive Telemetry suite in Grafana Cloud) watches how each metric is actually queried and recommends how much label detail to keep — the usage-driven form of the aggregation shield for metric cardinality. This post announces the GA of auto-apply and, specifically, a second auto-apply mode. The pre-existing mode, coverage-first, applies every recommendation the moment it is generated — including de-aggregation (series increases) when a query arrives for data that had been aggregated away — so resolution always tracks what you query, at the cost of an active-series spike when query patterns shift. The new cost-first mode adds a built-in budget guardrail: it applies all series-reducing recommendations immediately, ranks series-increasing ones from least to most impactful, and walks that list only until the next increase would push projected active series above where the cycle started — guaranteeing the series count stays flat or drops over a cycle. Segments let a tenant partition telemetry (by team / environment / cluster) and set a different mode per segment, so experts' critical data stays coverage-first while cost-sensitive data runs cost-first.
Key takeaways¶
- Active series, not sample rate, is the cost unit the whole feature optimizes around. Every recommendation carries a projected change to series count; both modes are decision rules over that projected delta. This is the same framing as the canonical cardinality lesson — cardinality (active series) is the primary TSDB scaling/cost knob. (Source: sources/2026-10-15-grafana-coverage-first-or-cost-first-auto-apply-adaptive-metrics)
- Coverage-first = usage tracks queries, unbounded cost. "Every recommendation applies, no ranking required." Series increases go through immediately: "If a query comes in for data that's already been aggregated away, the recommendation to restore it at full resolution applies right away, because someone clearly needs that data." The tradeoff is explicit — "a spike in queries against previously-aggregated data shows up as a spike in series count."
- Cost-first = bounded cost, deferred coverage. A three-step decision rule: (1) series-reducing recommendations always apply (including brand-new ones); (2) series-increasing recommendations are ranked least- to most-impactful; (3) Adaptive Metrics stops at your current total — it walks the ranked list applying increases "until the next one would push your projected series count above where it started the cycle." Net effect: series count stays flat or drops, never rising above the cycle's starting point.
- Worked example (the post's own table). A cycle with three recommendations
—
-10(reduces),+5(increases),+10(increases): cost-first applies the-10and the+5(running total still ≤ start) but rejects the+10(would exceed start); coverage-first applies all three. The guarantee cost-first is built around is that the running total never exceeds the cycle's start. - Mode selection is a per-dataset judgement, not a global switch. Grafana Labs uses coverage-first internally for its own critical telemetry — "you want nothing standing between a real query and the raw data behind it." Cost-first is the better fit "where cost matters more than guaranteed full coverage" — notably when a PromptQL query or an agent issues queries with no visibility into the downstream cost impact, so Adaptive Metrics "holds the line on cost and lets you review and restore specific data later." This is a named, concrete motivation: naive/agent-generated queries driving unintended de-aggregation cost.
- Segments make the two guarantees composable. The segments feature partitions telemetry along a chosen dimension (team / environment / cluster) and lets each segment carry its own mode — "the same underlying system; you're just telling it which guarantee you want and where." Keep coverage-first on expert-owned segments, cost-first where predictability matters.
- Operational guardrails. Both modes apply continuously with no human in the loop while existing dashboards, alerts, and queries keep working unchanged. The post recommends creating exemptions first for anything you can't afford to lose, and notes an Admin role is required to change the mode.
Systems / concepts extracted¶
- Adaptive Metrics (Grafana Cloud / Adaptive Telemetry suite) — usage-driven
aggregation-recommendation engine. A feature of Grafana
Cloud, not an independent system; recorded as a
##section on the Grafana Cloud page per the Systems gate (single source, feature/SKU of an existing system). - auto-apply — the mechanism that applies Adaptive Metrics' recommendations with no human intervention; now GA, now with two modes.
- coverage-first mode / cost-first mode — the two decision rules over the projected active-series delta. A single-source, product-specific implementation of usage-driven cardinality control; recorded as prose + tags, not a minted pattern (per Taxonomy discipline — one-off, not yet reusable across articles).
- segments — per-dimension partitioning that lets each slice carry its own mode.
- Metric cardinality — the concept this maps into: active series as the TSDB cost/scaling knob, and aggregation as the shield.
- PromptQL / agent-issued queries — named as the motivating cost risk that cost-first exists to contain (plain-text mention; no page).
Operational numbers / specifics¶
- No fleet-scale numbers (this is a feature-mechanics post). The only concrete
figures are the illustrative recommendation table:
-10,+5,+10series deltas, with cost-first applying-10and+5and rejecting+10. - Cost-first invariant: projected active-series count at end of a cycle ≤ count at start of that cycle.
Caveats¶
- Borderline-scope GA/feature-announcement post (Tier-2 Grafana). Ingested
because the cost-vs-coverage auto-apply decision algorithm and its
active-series-budget invariant are genuine, reusable observability-cost design
content that maps onto the existing
metric-cardinalityconcept; the marketing (CTAs, "sign up free") is confined to intro/outro. - Mechanics-only: no architecture of how Adaptive Metrics computes recommendations, no ingestion-path internals, no production numbers.
- Vendor-specific to Grafana Cloud / Adaptive Telemetry.
Source¶
- Original: https://grafana.com/blog/coverage-first-or-cost-first-two-ways-to-automatically-apply-adaptive-metrics-recommendations/
- Raw markdown:
raw/grafana/2026-10-15-coverage-first-or-cost-first-two-ways-to-automatically-apply-6a6e8c93.md
Related¶
- concepts/metric-cardinality — active series as the TSDB cost/scaling knob; aggregation as the shield
- systems/grafana-cloud — the platform hosting Adaptive Metrics / Adaptive Telemetry
- concepts/observability
- companies/grafana