Best practices for optimizing metrics cost

Start by identifying which cost centers, cost products, or metrics sources contribute the most to your metric cardinality. This helps pinpoint which business units ingest most metrics, allowing you to target optimization efforts where they will have the greatest impact.

Run the following DQL queries to view the breakdown by cost centers, cost products, or metric sources.

metrics
| summarize count = count(), by: {dt.metrics.source}
| sort count desc

metrics
| summarize count = count(), by: {dt.cost.costcenter}
| sort count desc

metrics
| summarize count = count(), by: {dt.cost.product}
| sort count desc

The following example shows these queries executed in a notebook.

Notebook showing DQLs for metrics Cost Allocation, scanning a maximum of 100,000 series per query

Once you identify high-cardinality attributes, filter by these and examine individual metric keys.

The following DQL examples show how to identify metrics for filtered cost centers, cost products, or metric sources. These queries reveal which specific metrics within the filtered attributes contribute the most to cardinality.

metrics
| filter dt.metrics.source == "metric_source_name"
| summarize count = count(), by: {metric.key}
| sort count desc

metrics
| filter dt.cost.costcenter == "cost_center_name"
| summarize count = count(), by: {metric.key}
| sort count desc

metrics
| filter dt.cost.product == "product_name"
| summarize count = count(), by: {metric.key}
| sort count desc

Use Notebooks to execute DQL queries

Once you've drilled down with the metrics command, you can use the timeseries command to get the cardinality for a specific key.

timeseries count(metric.key, scalar: true)

For more information, see DQL timeseries examples.

The following example shows the results of this DQL query expressed as a Single value visualization.

Use the timeseries DQL command to view cardinality for a specific metric

Dynatrace provides built‑in self‑monitoring metrics for OTLP metrics ingest. These metrics show how many OTLP data points arrive at the ingest API and provide a high‑level view of how much metric data is being ingested. They can also be used to validate that fewer data points are flowing in after applying filters on the client side or in the Collector.

Available self‑monitoring metrics are described in the table below.

The Collector provides internal telemetry, which you can use to understand how many metrics are received and how many are exported.

To inspect individual metrics and their attributes, you can use the Collector's debug exporter. This prints metrics directly to the Collector's console and is useful for troubleshooting and validation.

The code block below provides an example that you can integrate into your Collector configuration.

exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, otlp_http/dynatrace]

Dropping metrics helps eliminate unused data, such as metrics that you haven't used in the last year.

Although OpenPipeline rules are evaluated during ingest in the Dynatrace cluster, any metrics dropped by these rules (or upstream before ingestion) are neither stored nor retained. As a result, they don’t incur costs related to Metrics - Ingest & Process billing.

Drop metrics in OpenPipeline

OpenPipeline allows you to drop metrics during the Processing stage by using a Drop record processor. This lets you drop metrics by name, drop data points based on resource attributes, and drop data points based on metric point attributes.

The Drop record processor executes for all matches. Every metric record matching the query is dropped and never written to storage.

Drop metrics in OpenPipeline

Drop metrics at the source

Dropping metrics within the OTel Collector prevents specific time series or data points from being ingested altogether.

You can drop metrics at different points in the ingest process:

High-cardinality dimensions, such as user IDs or request IDs, significantly increase metric storage requirements. Removing a high-cardinality dimension reduces the number of stored timeseries and can lower cost.

Keeping dimensions meaningful and bounded is critical for managing cost and performance.

Reduce cardinality in OpenPipeline

In OpenPipeline metrics processing, metric dimensions are stored as fields on the record. When you remove a field from a record, that dimension is not ingested for the given metric.

You can use either a DQL processor or a Remove fields processor.

To use a DQL processor:

How to configure a DQL processor in OpenPipeline

To use a Remove fields processor:

Usage of the OpenPipeline Remove fields processor

Reduce cardinality at the source

You can use the OTel Collector to remove unwanted attributes from metrics before ingestion.

To do this, use the transform processor to remove high-cardinality attributes such as user.id and request.id at the data-point level.

You can integrate the following example code into your Collector configuration.

processors:
  transform:
    metric_statements:
      - context: datapoint
        statements:
          - delete_key(attributes, "user.id")
          - delete_key(attributes, "request.id")

To reduce metric resolution and granularity, adjust the collection interval at the source before data reaches Dynatrace.

Select metrics with longer ingest intervals carefully to ensure they still meet monitoring and analysis requirements. The following metrics might be good candidates for reduced ingest intervals.

To ensure reliable, cost‑efficient, and stable observability data, continuously validate the cardinality and ingest intervals as part of your CI/CD (SDLC) processes. Changes in instrumentation or configuration can unintentionally introduce excessive cardinality, overly frequent metric collection, or shifts in data behavior. All of these can increase ingestion costs.

You can use Dynatrace to automate these checks. Validate DQL queries through a Site Reliability Guardian (SRG) integrated into development workflows, which helps detect data anomalies early. SRG evaluations can alert when new code or configuration changes modify cardinality, scraping intervals, or other aspects of the telemetry profile. For more information, see Site Reliability Guardian.

Continuous validation creates a proactive feedback loop: teams can correct instrumentation or adjust their OpenTelemetry configuration before changes progress to production.

You can allocate metrics ingest costs to specific cost centers or products. To do this, enrich your metrics ingest with Cost Allocation attributes (dt.cost.costcenter or dt.cost.product) as metadata.

For more information, see Allocate your DPS costs.

Validate the business value of each metric before ingestion. Keep only metrics that support defined use cases to minimize data point volume and reduce cost.