This documentation describes the new tagging model for Latest Dynatrace. Some capabilities are still rolling out.
Many organizations running Dynatrace Classic built their observability setup around two mechanisms: automatically applied tags and management zones. Understanding how they worked, and where they created ongoing maintenance overhead, makes it easier to see why primary Grail fields and tags are the better foundation on Latest Dynatrace.
Auto-tagging rules in Dynatrace Classic applied key-value tags to entities based on conditions evaluated against entity properties.
A typical rule looked like this: if the process name contained billing, Dynatrace applied the tag component=billing.
Because these conditions were evaluated at the entity level, a single rule could automatically tag hundreds of hosts, processes, and services.
Auto-tags also acted as the main propagation mechanism.
A tag defined on a process group is propagated vertically to related host and service entities.
That meant a single rule could ensure that the environment=prod tag appeared on processes, their host, and the services they exposed, effectively spreading organizational context across the topology.
Management zones were often defined as combinations of auto-tag conditions.
For example, a management zone named Billing - Production could include entities where component=billing and environment=prod.
This used let teams scope dashboards, alerts, and access to a meaningful slice of the environment without enumerating individual entities.
In practice, this created a chain of dependencies. Auto-tagging rules could extract values from naming schemes, but management zones still had to be created and maintained manually. There was no way to define them generically. Every new team, application, or environment meant updating auto-tag rules in some cases and always creating or adjusting the management zones that depended on those values.
A common pattern in Dynatrace Classic was to encode organizational context directly in the host group name, for example, onprem_billing_prod or aws_payments_staging.
This kept host group assignment simple, but the individual attributes embedded in the name, such as environment, application, and team, were not queryable as separate fields.
To work around this, teams wrote auto-tagging rules that parsed the host group name.
A rule might say: if the host group name contains prod, apply tag environment=prod.
This made the individual attributes available again for management zone conditions and dashboard filters, but it also created brittle rules tied to naming conventions that were difficult to change later.
Primary Grail fields and tags replace this chain of rules with enrichment at the source. Set it once during deployment, and it flows automatically to every signal and Smartscape node.
Classic setups are entity-first: you find an entity by its tag, then look at that entity's data. Because primary Grail fields and tags are enriched directly on every signal, the latest platform is data-first. You query, route, and filter the data directly, without detours through the topology.
| Entity-first (classic) | Data-first (latest) |
|---|---|
Query an entity by its tag, then fetch it's data. | Query the data directly by primary fields and tags. |
Route alerts based on tags applied to entities. | Route alerts on the primary fields and tags carried by the alert events themselves. |
Encode context in service names so it surfaces in lists. | Use primary fields and tags as columns in service lists, apps, and dashboards. |
In Dynatrace Classic, you needed auto-tagging rules to propagate tags from the host to the process to the service level.
With primary Grail tags, propagation is built in.
A primary_tags.* attribute defined at the host level is automatically present in logs, metrics, spans, and events on all relevant Smartscape nodes, and in any Davis events and problems they trigger.
The same applies at process level: a primary_tags.* attribute set via DT_TAGS propagates to all signals from that process and its associated services.
Many of the attributes that classic setups derived through auto-tagging rules are now available out of the box as primary Grail fields, automatically enriched on every signal without any extra configuration.
Examples include host group (dt.host_group.id), Kubernetes namespace (k8s.namespace.name), Kubernetes cluster (k8s.cluster.name), AWS account (aws.account.id), and Azure subscription (azure.subscription).
If your classic setup used auto-tagging rules to surface these values, those rules are no longer needed. The underlying infrastructure context is already present in the telemetry.
For organizational attributes that go beyond infrastructure, such as team, application, cost center, or business unit, Latest Dynatrace sets them explicitly as primary Grail tags during deployment. This replaces brittle naming-scheme conventions with independently queryable attributes.