OneAgent version 1.343+ ActiveGate version 1.343+ Dynatrace Operator version 1.10+
Use the ingest 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 fields 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 write to the same target for the same signal, the higher-priority rule wins.
Rules apply within the scope where they are configured. When rules at multiple scopes write to the same target 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 write to the same target. |
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. Alternatively, go to Settings > Collect and capture > Ingest enrichment configuration and select Go to scope to pick the scope.
For background on how settings scopes work, see Settings API key concepts.
| Limit | Value | Notes |
|---|---|---|
Rules per scope | 50 | Applies independently at each scope (environment, cluster, host group, cloud account). |
Target length | 1–350 characters | The tag key or primary Grail field name written to the target. |
Value source length | 1–2048 characters | The metadata key (for Kubernetes, cloud, and host/process rules) or literal string (for custom rules). |
Value extraction (DPL expression) length | 1–2048 characters | Applies only to host/process property rules with the Override value with DPL expression toggle enabled. |
The Rule type dropdown determines which source metadata is available and which targets you can select. 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 label1 | Workload |
|
Kubernetes workload annotation1 | Workload |
|
Kubernetes pod label1 | Pod |
|
Kubernetes pod annotation1 | Pod |
|
Workload and pod rule types require Dynatrace Operator version 1.11+ ActiveGate version 1.347+. Namespace rule types require Dynatrace Operator version 1.10+ and ActiveGate version 1.343+.
Available targets: Cost product, Security context, Cost center, Kubernetes tag, Primary tag
When you select Kubernetes tag, 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 Primary tag, enter a key to write the value to primary_tags.<key>. Primary tags are written at the source, without a separate OpenPipeline processing step.
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 target.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.
Enable metadataEnrichment in your DynaKube before Kubernetes rules take effect.
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 targets: Cost product, Security context, Cost center, Cloud tag
When you select Cloud tag, the source value is propagated as a cloud provider tag (for example aws.tags.CostCenter).
Primary tag is not yet available as a target for cloud rules. Until it is, promote the forwarded cloud tags to primary tags in OpenPipeline.
Form fields
CostCenter maps the AWS tag CostCenter: payments to the selected target.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 targets: 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.
Target: 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. The expression uses a subset of Dynatrace Pattern Language. For supported constructs and examples, see Supported DPL syntax.
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 Conditions. 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. matchesValue(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. The DPL value extraction expression and DQL condition are evaluated only for host/process property rules; they have no effect on Kubernetes or cloud rules.
Custom value rules write a fixed literal value to a target on all signals where the optional condition is met. Use custom value rules to add a static value to signals when no existing metadata key carries the value.
Available targets: Cost product, Security context, Cost center, Primary tag
Form fields
Source: The fixed string value to write to the target.
Target: 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.
Condition (optional): A DQL matcher expression that limits when the rule runs. Supports a reduced set of DQL matcher syntax; see Conditions. For example, matchesValue(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 NOT matchesValue(k8s.namespace.name, "kube-system").
The condition is evaluated only for custom rules applied by OneAgent enrichment. Kubernetes and cloud rules do not evaluate DQL conditions.
Use a condition to limit a host/process property rule or a custom value rule to specific entities or data sources. The rule runs only on signals where the condition evaluates to true. If you leave the condition empty, the rule runs on all signals in its scope.
Conditions support a subset of DQL matcher syntax.
| Function | Use it to | Example |
|---|---|---|
| Check that a field equals a value. Use the |
|
| Check that a field contains, begins with, or ends with a value. |
|
| Check that a field doesn't exist. |
|
| Check that a field exists. |
|
Combine or negate functions with the AND, OR, and NOT operators. For example:
isNotNull(k8s.namespace.name) AND NOT matchesValue(k8s.namespace.name, "kube-system")
matchesValue(aws.account.id, "123456789012") OR matchesValue(aws.account.id, "210987654321")
The following examples show conditions for common fields.
Match an exact value:
matchesValue(host.name, "DemoData-easytrade")
matchesValue(dt.process_group.id, "PROCESS_GROUP-7EDCBB15662F9966")
matchesValue(dt.process_group.detected_name, "consumeCandleData")
Use the * wildcard with matchesValue to match part of a value:
| Match | Example |
|---|---|
Ends with |
|
Contains |
|
Starts with |
|
Match host and cloud attributes:
matchesValue(os.architecture, "x86")
matchesValue(host.type, "Standard_B4s_v2")
matchesValue(azure.resource.group, "PlatformSuccess")
matchesValue(azure.subscription, "00000000-0000-0000-0000-000000000000")
matchesValue(azure.tags.dt_owner_email, "owner@example.com")
Conditions don't support nested functions. Pass a field as the first argument of each function, not another function.
For example, matchesValue(matchesValue(aws.account.id, "12345"), true) isn't supported. Use matchesValue(aws.account.id, "12345") instead.
Other DQL matcher functions aren't supported in conditions.
Rules take effect within a few minutes. For Kubernetes workloads, the operator applies enrichment when it schedules a pod. Rule changes, therefore, affect only pods created after the change; restart existing pods to apply them.
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 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 ingest 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 | Target: 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 | Target: 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 | Target: Cost product
Writes dt.cost.product from the team label, giving per-team cost visibility.
Rule type: Custom value | Source: untagged | Target: 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.