Sparse Whisper series reserve full retention archives: diagnosing aggregation for low-traffic metrics

Direct answer

For sparse counter metrics, use aggregationMethod = sum so each down‑sampled archive stores the cumulative total. Set xFilesFactor low (e.g., 0.1 or 0.0) on the lower‑resolution archives so that a single daily point is not discarded when the aggregation window contains many null slots. carbon-aggregator rarely provides net storage savings for very low‑traffic series; its added latency, failure surface, and risk of double‑aggregation outweigh the modest block reduction because Whisper pre‑allocates the same blocks regardless of aggregation.

Why sum preserves counter semantics

• A counter increments monotonically; down‑sampling with sum adds the increments that occurred in each source interval, yielding the correct total for the target interval.
• avg normalises to a rate (value / seconds) and will under‑report when many source slots are null, because the average is taken over the whole window including the nulls.
• last or max lose the cumulative nature and are only appropriate for gauges.

Tuning xFilesFactor per archive

1. High‑resolution archive (e.g., 1 min for 1 day): keep the default 0.5 or raise it if you want to reject intervals with many gaps.
2. Mid‑resolution archive (e.g., 10 min for 30 days): set xFilesFactor = 0.1. A single point in a 10‑minute window yields 1/10 = 0.1 non‑null fraction, so it is retained.
3. Low‑resolution archive (e.g., 1 day for 5 years): set xFilesFactor = 0.0 or 0.01. This guarantees that even a solitary daily point survives aggregation.

Lowering xFilesFactor too far can keep intermittent nulls as valid data, masking real gaps. Choose the smallest value that still reflects the expected minimum point density for each archive.

Carbon‑aggregator trade‑off

• Regex rules apply globally; overlapping patterns can double‑aggregate or silently drop points.
• The daemon adds network hop latency and a single point of failure.
• Because Whisper’s storage cost is dominated by the fixed block allocation defined in storage-schemas.conf, down‑sampling via carbon‑aggregator does not reduce the number of allocated blocks.
• Only enable carbon‑aggregator when you need custom down‑sampling that cannot be expressed by the native archive schema (e.g., non‑uniform bucket sizes).

Verification steps

# 1. Inspect archive configuration and actual point counts
whisper-info.py /path/to/metric.wsp

# 2. Generate a controlled sparse series (one point per day for 30 days)
for i in {1..30}; do
  echo "test.metric $(date -d "$i days ago" +%s):1" | nc -q0 localhost 2003
done

# 3. After retention rolls, compare stored values with expected sums
whisper-fetch.py /path/to/metric.wsp | tail -30

If the fetched values match the manual sum of the injected points, the sum/xFilesFactor settings are correct.

One missing diagnostic detail

What is the exact retention schema (archive resolutions and durations) defined in storage-schemas.conf for the sparse metric? The optimal xFilesFactor per archive depends on those intervals.