Dynatrace Operator version 1.10+ OneAgent version 1.333+ ActiveGate version 1.343+
Starting with Dynatrace SaaS version 1.345, you can opt into central configuration at the cluster or tenant level. When you opt in, Dynatrace checks the builtin:ingest.enrichment.config settings schema for pre-existing rules. If none exist, your current enrichment setup is automatically migrated to the new central configuration setting in the background. If rules already exist, no automatic migration occurs and your existing setup remains unchanged.
You can migrate your rules and enable the new experience for individual Kubernetes clusters or for the entire environment.
The following table maps the current and new settings so that references to "current" and "new" throughout this page are unambiguous:
| Current settings | New settings | |
|---|---|---|
Settings schema |
|
|
Inheritance | Cluster rules replace environment rules | Cluster rules merge with environment rules |
Configuring domain tags | Enable | Select |
Configuring primary Grail tags on edge | Not supported | Select |
The current Kubernetes enrichment settings use an override-based structure: rules defined at the Kubernetes cluster level replace rules defined at the environment level. Clusters without cluster-level settings fall back to environment rules.
The new settings merge rules from the environment level with rules from the cluster level, where cluster-level rules take precedence. For details on this schema type, see Settings API key concepts.
The new schema aligns with the updated tagging model, which introduces primary Grail tags prefixed with primary_tags.*.
In the existing schema, the primaryGrailTag field marks the created rule as a domain tag rule. The new schema introduces a dedicated primary tag rule with target: "primary_tags.<key>". A primary tag rule writes the source value directly to primary_tags.<key> on the edge, without requiring an OpenPipeline step.
The target fields dt.security_context, dt.cost.product, and dt.cost.costcenter remain valid in the new schema. All other custom target field values are rejected.
When rules are defined at both environment and cluster level, automatically migrating both scopes may change enrichment behavior due to the inheritance differences described above. If rules are defined at only one level, this does not apply.
When you opt in a scope (Kubernetes cluster or environment) and no rules exist for it in the new schema, Dynatrace automatically migrates your existing rules. The migration creates copies of the existing rules in the new schema without modifying the original values, so you can switch back at any time.
For rules that used primaryGrailTag: true in the old schema, automatic migration creates two new rules in the new schema: the equivalent domain tag rule and a matching primary tag rule. Both k8s.namespace.<label|annotation>.<key> and primary_tags.<key> are populated on telemetry after migration.
Opting in and out repeatedly for the same scope does not create duplicate rules. To re-trigger automatic migration, delete all rules in the target scope and opt in again.
To skip automatic migration for a scope, create at least one settings object in the new schema via the UI or API before enabling the opt-in toggle. You can trigger automatic migration later by deleting all rules from the target scope in the new schema and opting in again.
The following example shows how a domain tag rule from the old schema is migrated to two rules in the new schema.
Old rule (builtin:kubernetes.generic.metadata.enrichment):
{ "type": "Label", "source": "domain", "primaryGrailTag": "true" }
New rules created by automatic migration (builtin:ingest.enrichment.config):
// Rule 1 — domain tag{ "type": "K8S_NAMESPACE_LABEL", "valueSource": "domain", "target": "k8s.namespace.label.domain" }// Rule 2 — primary tag{ "type": "K8S_NAMESPACE_LABEL", "valueSource": "domain", "target": "primary_tags.domain" }
After migration, telemetry carries both k8s.namespace.label.domain (for backwards compatibility) and primary_tags.domain (for routing, segmentation, and access control).
For each target, the first rule that provides a value is applied. Given these two rules:
k8s.namespace.label.first -> dt.cost.costcenterk8s.namespace.label.second -> dt.cost.costcenter
If the first label is present on the signal source, its value is written to dt.cost.costcenter and no further rules for that target are evaluated. If first is absent but second is present, that value is used. If neither label exists, no value is written.
When rules exist at both environment and cluster level, copying them directly to the new schema (for example, via automatic migration) can change enrichment behavior. Consider the following setup:
Cluster:k8s.namespace.label.costcenter -> dt.cost.costcenterEnvironment:k8s.namespace.label.product -> dt.cost.productk8s.namespace.label.department -> dt.cost.costcenter
| Input labels | Output (existing schema) | Output (new schema) |
|---|---|---|
|
|
|
| - |
|
In the existing schema, the cluster-level rules override the environment-level rules entirely, so dt.cost.product is never populated and k8s.namespace.label.department has no effect on clusters that define their own rules. In the new schema, both levels are merged, so environment rules continue to apply alongside cluster rules.