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 |
Tag field name |
|
|
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 a rule as a tag rule. The new schema replaces this with a "Kubernetes or cloud tag" option, represented by setting both source and target to the same key value.
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.
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.
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.