Metric Volume Control - Reduce Cardinality and Cost

Overview

Volume control lets you reduce the stored volume and cardinality of a metric by aggregating away attributes you don't need. You pick a metric and the attributes to keep (or drop); SigNoz then mathematically aggregates all series that differ only in the dropped attributes into a single series, at storage. The remaining attributes stay fully queryable, and the aggregated values stay correct: counter rates account for restarts and resets, and gauges keep their min, max, and averages.

This is different from dropping labels with a collector processor, which does not reduce cost and silently corrupts your data. See Dropping Metric Labels for why, and why the collector can't do this below.

When to Use It

Use volume control when a metric's cardinality comes from an attribute you never query by. The classic case is per-instance identity on aggregate views: 100 instances of a service each export http.server.requests.count broken down by route, method, and status. If your dashboards and alerts only ever look at route/method/status, the service.instance.id dimension multiplies your stored series by 100 for no benefit. A rule that aggregates away service.instance.id collapses those series while keeping every number you actually chart correct.

Common attributes worth aggregating away:

• service.instance.id, host.name, container.id: per-instance identity on services behind a load balancer
• k8s.pod.name, k8s.pod.uid: pod identity that churns on every rollout, creating new series each time

Managing Rules

Volume control lives in Metrics Explorer:

• The Volume Control tab gives the account-wide picture: configured rules, ingested vs retained series and samples, estimated monthly savings, a sample-volume chart, and a per-metric table with each rule's status, mode, attributes, and volume change. Use it to review and manage rules across your account.

• Each metric's detail page has a Volume control section where you set up or edit that metric's rule.

Create a Rule

Creating and editing rules requires the Admin role; other users can view rules but not change them.

1. Open the metric in Metrics Explorer and go to the Volume control section in the metric details.

2. Select Set up volume control (or Edit if it already exists) to open the Manage attributes drawer.

3. Choose a mode:

   Mode	Behavior
   Allow all attributes	All attributes stay queryable. Selecting this removes any existing rule.
   Include	Allowlist: only the selected attributes stay queryable. Everything else is aggregated away.
   Exclude	Blocklist: the selected attributes are aggregated away. Everything else stays queryable.

4. Select the attributes to include or exclude.

5. Review the impact preview. It shows the metric's full series count, the series currently retained under the existing rule, and the series that would be retained if you save (Full series / Current retained / Potential retained) so you can see the reduction before committing.

6. Review the related assets warning, if shown. It lists the dashboards and alerts that currently query the attributes this rule would aggregate away. Those panels will fall back to aggregated data once the rule applies. Follow the links and confirm you're not about to break a view someone depends on.
7. Select Save rule.

Rules take effect about 10 minutes after saving. Until then the rule shows as pending, and data keeps flowing at full fidelity.

Edit or Remove a Rule

Editing follows the same flow. Change the mode or attribute list and save; the new configuration also takes about 10 minutes to apply. To remove a rule, use Remove rule in the drawer or set the mode to Allow all attributes.

Rule changes are forward-looking:

• Data written before a rule took effect keeps its full fidelity.
• Data aggregated while a rule was active stays aggregated. Removing the rule does not restore the dropped attributes for that period.
• Queries that span a rule change are stitched automatically; you don't need to adjust them.

What Happens to Your Data

Once a rule is active:

• The most recent 24 hours always stay at full fidelity. Every attribute remains queryable in this window regardless of rules, and alerts always evaluate against this full-fidelity data. This is deliberate: alerting stays reliable no matter what rules exist, and when something is on fire you can debug it immediately at full detail, without pausing rules or thinking about cost. Volume control only changes how history is stored, where the aggregate trend is what matters.
• Beyond that window, ruled metrics are stored as 60-second aggregates per surviving attribute combination. Gauges keep last/min/max values and the sums and counts needed for averages; counters and histograms are stored as reset-aware per-minute increases, so rates stay exact.
• Aggregated data trails real time by a few minutes (typically 2–4), because aggregation runs on a schedule. This only matters for the aggregated copy — the full-fidelity window is as fresh as normal ingestion.

See Understanding Aggregated Metric Data for exactly what is preserved, what is lost, and why numbers can differ from what an alert saw — read it before writing rules for metrics that back important dashboards.

Rule Constraints

• One rule per metric. A rule targets the metric name.
• Protected attributes can't be aggregated away. le, quantile, __name__, __temporality__, and deployment.environment are always retained; rules that try to drop them are rejected.
• Exponential histograms are not supported yet. Rules on exponential-histogram metrics are rejected.
• Aggregation resolution is fixed at 60 seconds. Finer resolutions (30s/15s) may come later.

Why You Can't Do This in Your Collector

It's tempting to reach for OpenTelemetry Collector processors instead, for example metricstransform (aggregate labels), interval (reduce reporting frequency), or transform (rewrite attributes). None of them can deliver what volume control does:

• Aggregation there is per-batch. The metricstransform processor only aggregates within a single batch so it cannot combine data arriving from multiple sources, in different batches, or through different collector instances. Your 100 service instances export independently, so their series never meet in one batch to be merged.
• Resource attributes aren't aggregatable. The attributes that carry most cardinality (service.instance.id, host.name, k8s.pod.uid) are resource attributes. Data points under different resources are never merged by these processors, so the series don't collapse even when the batching happens to line up.
• No time alignment or state. Correctly merging cumulative counters from different sources requires tracking each source's start time and resets across export intervals. Stateless per-batch processing can't do that, and gets the math wrong when it appears to work.

Volume control aggregates at storage, where all sources' data is available together, aligned to time windows, with counter resets handled, which is what makes the results correct.

Related Reading

• Understanding Aggregated Metric Data: what aggregation preserves and what it trades away
• Dropping Metric Labels: why dropping labels in the collector doesn't reduce cost
• Understanding Metrics Billing and Reducing Costs: the full cost-reduction toolbox