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.namecreates 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 labels - Use the MetricsTransform Processor to aggregate metrics, which actually reduces cardinality and sample count.
- 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
