Does enabling adaptive sampling in Prometheus preserve alerting fidelity for low‑traffic workloads?

Direct answer

The premise needs correcting before the question can be answered: upstream Prometheus has no built-in "adaptive sampling" feature, in v2.30 or any later release. Prometheus scrapes each target at a fixed, configured interval and stores every sample it scrapes. There is no server-side mechanism that reduces the ingested sample rate for low-activity targets, so there is no such feature to enable — and therefore no sampling-induced fidelity loss to worry about from Prometheus core itself.

Because no live documentation was fetched for this answer, treat the version-specific claim with appropriate skepticism and verify against the official changelog — but the architectural point is well established: Prometheus's storage model is "store what you scrape," and cost control happens through scrape configuration and relabeling, not adaptive sampling.

What likely caused the confusion

Sampling-like behavior does exist elsewhere in the ecosystem, which may be the source of the mix-up:

• Grafana Agent / Alloy and some vendor distributions offer tail sampling or probabilistic sampling for traces, and remote-write relabeling for metrics. That is agent behavior, not Prometheus server behavior.
• Remote-write relabeling into long-term stores (Thanos, Mimir) can drop or downsample series before they leave Prometheus, which feels like "sampling" but is explicit configuration.

You can confirm what your server actually supports by checking /api/v1/status/flags and your scrape configs — you will find only standard scrape and relabel settings, no sampling flag.

The fidelity risk that actually exists

Alerting fidelity in a stock deployment is governed by two knobs, and both matter for your sub-minute spike concern:

1. Scrape interval. A spike shorter than the scrape interval can already be missed entirely. With the common 15s–60s intervals, a 20-second spike between scrapes may never be stored, sampled or not.
2. Rule evaluation interval and for durations. Lengthening the scrape interval to save storage also slows alert evaluation and delays staleness handling.

So the honest answer to "what sampling rate ensures sub-minute spikes aren't missed" is: no sampling rate does — only a scrape interval shorter than the spike duration does.

How to cut storage costs safely instead

For a low-traffic deployment, the practical levers are:

• Drop low-value series at ingestion with metric_relabel_configs (e.g., high-cardinality metrics no alert references). This is irreversible, so scope the regex carefully.
• Lengthen scrape intervals only on non-critical jobs, keeping alert-relevant targets at full frequency.
• Use recording rules to pre-aggregate expensive queries rather than storing raw high-cardinality data long-term.

The safeguard for critical alerts is simple: any metric or label set referenced by an alerting rule must be excluded from drop rules and kept at the original scrape interval.

Validating alert rules after relabeling changes

Before applying any drop config to production:

1. Extract every metric name used in your alerting rules and confirm none match your drop regexes.
2. Run promtool test rules against recorded series to confirm each rule still has input data.
3. Replay a known spike with a test exporter, apply the new config in staging, and confirm the alert still fires with the same timing.

One detail that would sharpen this recommendation: which backend (plain Prometheus, Thanos, Mimir, or an agent-based pipeline) is actually in front of your storage — because that determines whether any real sampling layer exists in your path at all.