Set up Cost Allocation for OpenTelemetry

• Latest Dynatrace
• How-to guide
• 4-min read
• Published Nov 04, 2026

You can use Cost Allocation to allocate your Dynatrace Platform Subscription (DPS) usage to the cost centers and products that you define.

Allocating costs provides a transparent and detailed account of the Dynatrace expenditures that originate from each cost center or product, which in turn helps your organization optimize its budgets. Cost Allocation works with OpenTelemetry-ingested data regardless of the telemetry type.

On this page, you'll learn how to set up Cost Allocation for data ingested via OpenTelemetry.

Overview

OpenTelemetry-ingested telemetry is covered by Cost Allocation the same way as other ingest methods: Traces - Ingest, Metrics - Ingest, and Log - Ingest, as described on this page.

We recommend setting up Cost Allocation along organizational lines and deployment scopes. Suitable concepts include OpenTelemetry resource attributes that are already available on your signals, such as service.name, k8s.namespace.name, or deployment.environment.

To add Cost Allocation information to your OpenTelemetry data, enrich your signals with the dt.cost.costcenter and dt.cost.product attributes. Dynatrace automatically propagates these attribute values from spans to the service entity for span data.

Allocate costs for OpenTelemetry-ingested telemetry

OpenTelemetry-ingested telemetry supports the same enrichment options as other ingest methods. Our recommendations are:

Enrich on ingest

With ingest enrichment, you can create rules to automatically enrich all ingested telemetry signals with dt.cost.costcenter and dt.cost.product. The data is stored in Grail:

For more information about enriching on ingest, see Configure ingest enrichment rules.

Enrich at the source

You can use your existing labels and tags to facilitate Cost Allocation in Dynatrace.

Via Kubernetes labels or annotations

You can use Kubernetes labels or annotations as a source for your dt.cost.costcenter and dt.cost.product. This is one of the most convenient ways of doing this.

Alternatively, you can configure the OTel Collector to enrich data in transit. If you do this, you might have to map your Kubernetes metadata to dt.cost.costcenter or dt.cost.product in OpenPipeline.

Via OpenTelemetry resource attributes

To use the OTEL_RESOURCE_ATTRIBUTES environment variable, directly set dt.cost.costcenter and/or dt.cost.product as resource attributes. You can also use any resource attribute in OpenPipeline as a source for either field.

Via OneAgent metadata file

Dynatrace OneAgent provides enrichment files or environment variables to add attributes directly in your application code.

Enrich with OpenPipeline

If source-level enrichment isn't feasible, or if you only need to allocate costs at the deployment level of granularity, you can use OpenPipeline to

Map primary Grail fields

Do this in the Cost allocation and Product allocation stages in OpenPipeline.

Derive cost centers or products based on multiple fields

If you have a more sophisticated strategy for cost center tags, it might not be enough to map a single field directly to dt.cost.costcenter or dt.cost.product.

In this case, we recommend that you use a DQL processor in OpenPipeline to derive cost centers or products from a combination of fields, and then set dt.cost.costcenter or dt.cost.product from the resulting field with the Cost allocation stage. For examples, see OpenPipeline processing examples.