OneAgent version 1.343+ ActiveGate version 1.343+ Dynatrace Operator version 1.10+
Use the central enrichment settings to create rules that automatically enrich all signals from your environment with primary Grail fields and tags.
Rules map metadata from Kubernetes labels and annotations, cloud provider tags, host and process properties, or custom literal values to target dimensions such as dt.cost.product, dt.security_context, dt.cost.costcenter, or your own primary_tags.* fields.
Enrichment rules run before data enters the processing pipeline, so the same fields are available for pipeline routing, bucket assignment, access control, and cost allocation without any post-processing steps.
For a step-by-step approach across all enrichment methods, see Best practices for enriching primary Grail fields and tags.
In Dynatrace, go to Settings and search for Ingest Enrichment Config.
Each rule defines a mapping:
Rules are evaluated in priority order. When two rules target the same dimension for the same signal, the higher-priority rule wins.
Rules apply within the scope where they are configured. When rules at multiple scopes target the same dimension for the same signal, the narrower-scope rule takes precedence.
| Scope | Applies to |
|---|---|
Environment | All signals in the Dynatrace environment. Rules configured here serve as the tenant-wide default. |
Kubernetes cluster | Signals from a specific Kubernetes cluster. Cluster-level rules merge with environment-level rules; the cluster rule wins when both target the same dimension. |
Host group | Signals from hosts in a specific host group. Host group rules merge with environment-level rules. |
Cloud account | Signals from resources in a specific cloud account. Account rules merge with environment-level rules. |
To configure rules for a specific scope, navigate to the entity in Dynatrace (for example, a Kubernetes cluster or host entity page), open Settings, and search for Ingest Enrichment Config.
For background on how settings scopes work, see Settings API key concepts.
The Rule type dropdown determines which source metadata is available and which dimensions you can target. The four rule types cover Kubernetes, cloud provider, host/process, and custom sources.
Kubernetes rules promote labels and annotations from Kubernetes resources to primary Grail fields and tags on all signals emitted by those workloads.
| Rule type | Reads from | Source attribute written to telemetry |
|---|---|---|
Kubernetes namespace label | Namespace |
|
Kubernetes namespace annotation | Namespace |
|
Kubernetes workload label | Workload |
|
Kubernetes workload annotation | Workload |
|
Kubernetes pod label | Pod |
|
Kubernetes pod annotation | Pod |
|
Available dimensions: Cost product, Security context, Cost center, Kubernetes or cloud tag
When you select Kubernetes or cloud tag as the dimension, the source value is propagated as a Kubernetes metadata tag (for example, k8s.namespace.label.team), which you can then promote further with an OpenPipeline processing rule if needed.
When you select Cost product, Security context, or Cost center, the value is written directly to that primary Grail field on all signals from the matching workloads.
Form fields
team maps the label team: payments to the selected dimension.Namespace label and namespace annotation rule types are available now. Workload and pod rule types are rolling out and may not yet be visible in your environment.
Requirements: Dynatrace Operator version 1.10+ with metadataEnrichment enabled in your DynaKube.
For setup details, see Enrich Kubernetes telemetry with primary Grail fields and tags.
Cloud rules promote tags and labels from AWS, Google Cloud, and Azure resources to primary Grail fields and tags on all signals from those resources.
| Rule type | Reads from | Source attribute written to telemetry |
|---|---|---|
AWS tag | AWS resource tags |
|
GCP label | Google Cloud resource labels |
|
GCP tag | Google Cloud resource tags |
|
Azure tag | Azure resource tags |
|
Available dimensions: Cost product, Security context, Cost center, Kubernetes or cloud tag
When you select Kubernetes or cloud tag as the dimension, the source value is propagated as a cloud provider tag (for example aws.tags.CostCenter).
Form fields
CostCenter maps the AWS tag CostCenter: payments to the selected dimension.Cloud rule types are rolling out and may not yet be visible in your environment.
Host/process property rules promote attributes from OneAgent-monitored hosts and processes to primary Grail fields and tags.
Available dimensions: Cost product, Security context, Cost center, Primary tag
When you select Primary tag, enter a tag name to write the value to primary_tags.<name>.
Form fields
Source attribute: Select from a curated list of host and process attributes, grouped by cloud provider (AWS, Azure, Google Cloud), Kubernetes, host, process, Cloud Foundry, operating system, and general properties. Select Custom / other to enter an attribute key that is not in the list.
Key (for attributes marked with <key>): Replace the <key> placeholder with your specific attribute key.
Dimension: The primary Grail field or tag to write the value to.
Primary tag name (when Primary tag is selected): The name to use as the primary_tags.<name> key.
Override value with DPL expression (optional): Enable this toggle to transform or extract part of the source value before writing it to the target dimension. The expression uses a subset of Dynatrace Pattern Language.
Extract the last segment of a host name (for example, host from app.prod.host):
splitString(host.name, ".")[lastIndex]
Extract the first segment of a host name:
splitString(host.name, ".")[0]
Normalize a value to lowercase:
toLower(host.name)
Normalize a value to uppercase:
toUpper(host.name)
Not all DPL constructs are supported. Pattern-matching expressions designed for log parsing are not guaranteed to work in this context.
Condition (optional): A DQL matcher expression that limits when the rule runs. The condition field supports a reduced set of DQL matcher syntax; for available functions and operators, see DQL matcher in logs. The rule runs only when the condition evaluates to true.
For example: isNotNull(host.name) limits the rule to signals where the host attribute is present. host.name == "prod-server" limits the rule to a specific host. Use AND and OR to combine conditions.
Host/process property rules require OneAgent version 1.343+ and are rolling out.
Custom rules write a fixed literal value to a target dimension on all signals where the optional condition is met. Use custom rules to add a static dimension to signals when no existing metadata key carries the value.
Available dimensions: Cost product, Security context, Cost center, Primary tag
Form fields
primary_tags.<name> key.k8s.namespace.name == "production" limits the rule to signals from the production namespace. Use AND and OR to combine multiple conditions: isNotNull(k8s.namespace.name) AND k8s.namespace.name != "kube-system".Rules take effect within a few minutes. Changes to rules that apply to Kubernetes workloads may take up to 15 minutes to propagate, and affected pods may need to restart.
To edit or delete a rule, open the (More) menu on the right end of a row and select the command.
Rules are evaluated top to bottom. When two rules would write the same target dimension for the same signal, the higher-priority rule wins. The Propagated value column in the rule table shows the value that each rule produces. When a rule is overridden by a higher-priority rule, its value is shown as Loses to higher value.
To change priority, use to drag a rule row to a new position in the table, or use the Move rule up and Move rule down actions in the (More) menu.
This example shows how to configure central enrichment rules to automatically populate dt.security_context, dt.cost.costcenter, and dt.cost.product across all Kubernetes telemetry.
Scenario: Each Kubernetes namespace carries two labels:
team: <owning-team> — identifies the team responsible for workloads in this namespacecost-unit: <business-unit> — identifies the business unit for cost allocationRules to create (in this priority order):
Rule type: Kubernetes namespace label | Key: team | Dimension: Security context
Writes dt.security_context from the team label on all signals from that namespace, enabling Grail access control per team.
Rule type: Kubernetes namespace label | Key: cost-unit | Dimension: Cost center
Writes dt.cost.costcenter from the cost-unit label, routing costs to the correct business unit.
Rule type: Kubernetes namespace label | Key: team | Dimension: Cost product
Writes dt.cost.product from the team label, giving per-team cost visibility.
Rule type: Custom | Literal: untagged | Dimension: Security context | Condition: isNull(dt.security_context)
A fallback rule that writes dt.security_context: untagged to signals from namespaces that do not have the team label. Because rule 1 runs first, this rule only fires when rule 1 produced no value.
Result: A log, span, or metric from a namespace with team: payments and cost-unit: fintech will carry dt.security_context: payments, dt.cost.costcenter: fintech, and dt.cost.product: payments. Signals from unlabeled namespaces will carry dt.security_context: untagged.
To scope these rules to a specific Kubernetes cluster only, follow the same steps from the cluster entity settings rather than the environment settings. See Scope hierarchy.
metadataEnrichment to be enabled in your DynaKube.