Understanding Metrics Billing and Reducing Costs

Overview

Metrics billing is based on cardinality - the number of unique time series created by your metrics. Understanding how attributes affect cardinality is key to managing costs effectively.

How Attributes Affect Billing

There are two types of attributes that affect your metrics differently:

Identifying attributes - These create new time series and contribute to cost. For example, adding a new host.name creates a new series.
Non-identifying/descriptive attributes - These enrich existing metrics without creating new series. Examples include host family or EC2 tags.

You can add as many non-identifying attributes as needed without additional cost, but each new identifying attribute with unique values increases your bill, often exponentially.

Common Cost Drivers

High Cardinality Attributes

Avoid including random IDs or unique identifiers in your metric attributes. For example, instead of:

/bitcoin-mainnet-esplora/scripthash/20fd0a38027a2eeb14fd50fcbd94934f832bef4cc279958c30c72704338eb065/txs

Use a templated approach:

/bitcoin-mainnet-esplora/scripthash/${id}/txs

Histogram Metrics

Histogram metrics are particularly costly because:

Bucket configuration - Each bucket distribution creates a separate series. Optimize your bucket configuration based on your workload's latency patterns.
Cumulative nature - With cumulative histogram metrics, values continue to be sent even when there's no recent activity, especially problematic when combined with high-cardinality attributes like method names containing IDs. Switching to delta temporality avoids this — see Use Delta Temporality.

Cost Reduction Strategies

1. Use Delta Temporality

OpenTelemetry SDKs export metrics with cumulative temporality by default: on every export interval, the SDK re-sends the running total for every active series — even when nothing has changed since the last export. With delta temporality, synchronous instruments (Counter, Histogram) that record no measurements during an export interval export no data points at all for that interval, so idle series don't add billable samples.

We recommend setting delta temporality in your application's SDK using the standard environment variable:

export OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE="delta"

This environment variable is supported by the OpenTelemetry SDKs for Java, Python, Go, JavaScript/Node.js, .NET, and Ruby. Some SDKs (such as Rust) configure temporality in code instead — see the application metrics guides for language-specific instructions.

The savings apply to synchronous instruments only. Observable (asynchronous) instruments emit a data point on every collection cycle regardless of temporality.

Deriving deltas at the OpenTelemetry Collector with the cumulativetodelta processor does not reduce costs. The SDK still exports the cumulative value on every interval even when nothing changed, and the processor converts each of those points into a zero-value delta point — which is still ingested and billed. To get the savings, set delta temporality in the SDK itself.

2. Remove or Template High-Cardinality Attributes

Replace unique IDs with templated values to reduce the number of unique time series being created.

3. Optimize Histogram Buckets

Reduce the number of buckets while maintaining meaningful data. See Configure Custom Buckets for more details.

4. Implement Sampling

Reduce the volume of metrics sent from your application. This directly reduces the number of data points ingested.

5. Review Attribute Necessity

Ensure all identifying attributes are essential for your monitoring needs. Remove any attributes that don't provide actionable insights.

6. Aggregate or Drop Metrics

Consider using the following techniques:

Aggregate away high-cardinality attributes - Use Metric Volume Control to aggregate away attributes you don't query by (like service.instance.id or k8s.pod.uid) at storage, reducing stored cardinality while keeping the remaining attributes correct and queryable. Collector-side alternatives like the MetricsTransform Processor only aggregate within a single batch and cannot aggregate resource attributes, so they don't work for data coming from multiple sources.
Drop entire metrics - See How to Drop and Filter OpenTelemetry Metrics to remove unnecessary metrics entirely.

Note that simply dropping metric labels/attributes does not reduce cardinality or costs. See Dropping Metric Labels for a detailed explanation of why this doesn't work and what to do instead.

Monitoring Your Costs

Use the Cost Meter to:

Monitor costs across different telemetry signals
Understand the cost breakdown and key contributors
Track metric datapoint ingestion over time
Set up alerts to notify you when costs exceed thresholds

Additional Resources

Comprehensive guide on cardinality
Dropping Metric Labels - Why dropping labels doesn't reduce costs
Cost Meter Overview - Monitor your observability costs