Set up Cost Allocation for Distributed Tracing
- 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 span data regardless of your ingestion method.
On this page, you'll learn how to set up Cost Allocation for span data.
Overview
For ingested traces, you can allocate costs related to ingest and query consumption.
- Dynatrace natively supports Cost Allocation for Traces - Ingest, as described on this page.
- To allocate Traces - Query costs, see Configure user-based Cost Allocation for queries, Automation Workflow, and Agentic AppEngine.
We recommend setting up Cost Allocation along organizational lines and deployment scopes.
Suitable concepts include service.name, k8s.namespace.name, dt.host_group.id, and deployment.environment.
These attributes are typically available on all span data, regardless of ingest method.
To add Cost Allocation information to your span data, enrich your records with the dt.cost.costcenter and dt.cost.product Grail attributes.
Dynatrace automatically propagates these attributes from spans to the service entity and any resulting service metrics.
Cost Allocation works regardless of how the traces were ingested, whether via OneAgent extended trace ingestion or OpenTelemetry.
Allocate trace ingest costs
Depending on how you ingest your traces, there are different ways to allocate your costs. Our recommendations are:
- If you ingest via OneAgent or Kubernetes: Enrich on ingest.
- If you ingest via API: Enrich either at the source, or via OpenPipeline.
Enrich on ingest
With ingest enrichment, you can create rules to automatically enrich all ingested span signals with dt.cost.costcenter and dt.cost.product.
The data is stored in Grail:
- It's available via
Dashboards, 
Notebooks, Account Management, and the Dynatrace API. - You can use the data across Dynatrace (for example, pipeline routing, bucket assignment, access control, as well as Cost Allocation) without any post-processing steps.
For more information about enriching on ingest, see Configure ingest enrichment rules.
Enrich at the source
You can define Cost Allocation at the source via OneAgent, Kubernetes labels or annotations, or OpenTelemetry.
This lets you use your existing labels and tags, so that dt.cost.costcenter and dt.cost.product are already present when your data arrives.
Enrich with OpenPipeline
If you only need to allocate costs at the deployment level of granularity, you can use OpenPipeline to
- Map primary Grail fields (works for most use cases).
- Derive Cost Allocation tags based on multiple fields (if you have a more sophisticated tagging strategy for cost centers).
Map primary Grail fields
Do this in the Cost allocation and Product allocation stages in OpenPipeline.
-
Identify the primary Grail field that you want to base your allocation on, such as
k8s.namespace.nameordeployment.environment. -
Go to
OpenPipeline > Traces. -
Go to the Pipelines tab, select an existing pipeline or create a new one, and go to the Cost allocation stage (to set
dt.cost.costcenter) or the Product allocation stage (to setdt.cost.product). -
Add a DPS Cost Allocation - Cost Center or DPS Cost Allocation - Product processor. Define a matching condition, such as:
matchesPhrase(deployment.release_stage, "prod-") -
Set the value either as a static string, or copied from a field on the record.
For the full list of parameters and processor examples, see Cost allocation via 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.
Recommendations for Distributed Tracing Cost Allocation
Traces often span multiple services, hosts, or clusters. Consider these recommendations when you allocate costs for Distributed Tracing:
- Allocate at the service or deployment-environment level, not at the level of an individual span, so that all spans belonging to the same trace end up with consistent
dt.cost.costcenter/dt.cost.productvalues. Splitting a single trace's spans across multiple cost centers can make it harder to reconcile a trace's total DPS usage with a single cost center or product. - If a service is shared across cost centers or products, see Handling shared costs rather than trying to split individual spans.
Before you change the values of dt.cost.costcenter or dt.cost.product, make sure they're defined in the Cost Allocation allow lists.