This documentation describes the new tagging model for latest Dynatrace. Some capabilities are still rolling out. If you're currently using classic auto-tagging, see Classic vs. latest to understand how your existing setup maps to the new model.
Dynatrace addresses the challenge of organizing observability data at scale through the concept of primary Grail fields and tags. Together, they form the metadata foundation of the Dynatrace platform. Dynatrace is progressively expanding coverage across signal types and data sources.
The same enrichment applies across every signal type and Smartscape nodes. You query telemetry and topology with the same fields, no joins required. Because they're available before data enters the processing pipeline, you can use them consistently for routing, bucket assignment, access control, and segmentation consistently.
Primary Grail fields are built-in fields defined in the Semantic Dictionary. Dynatrace automatically enriches them on all signals (logs, metrics, spans, events, and problems) and on all relevant Smartscape nodes, without any manual configuration. They represent infrastructure-level facts like the Kubernetes cluster and namespace from which a signal originated.
Not every primary Grail field exists in every situation.
For example, dt.host_group.id is only present when you configure a host group for a host.
Where appliicable, Dynatrace enriches it consistently across all signals and Smartscape nodes from that source.
Primary Grail fields are available before data enters the processing pipeline. This means you can use them for pipeline routing and bucket assignment from the earliest processing stage. Dynatrace also enriches them on all derived signals, including Davis events and problems, so alerts carry the same organizational metadata as the telemetry that triggered them.
A subset of primary Grail fields can be used as conditions in IAM policies for record-level access control.
These fields are marked with the permission tag in the Semantic Dictionary.
Use them to define who can access which telemetry data based on deployment-level attributes such as host group, Kubernetes namespace, or cloud account.
Primary Grail tags are customer-defined and follow the primary_tags.* prefix convention, for example, primary_tags.team, primary_tags.app, primary_tags.stage.
Like primary Grail fields, primary Grail tags are available before data enters the processing pipeline. This means you can use them for pipeline routing and bucket assignment from the earliest processing stage. Dynatrace enriches all derived signals (service metrics, Davis events, and problems) with the same tags. Hence, the ownership metadata present in your logs and spans also appears on the Davis events and Davis problems they trigger.
The primary Grail tags can be set from multiple sources:
oneagentctl.OTEL_RESOURCE_ATTRIBUTES.Standard tags (cloud tags, Kubernetes labels and annotations, and topology-applied tags) remain available on Smartscape nodes. However, Dynatrace doesn't automatically enrich them on raw telemetry signals.
This means you can't use standard tags to:
Standard tags are available on Smartscape nodes only. They don't follow data through the platform. Primary Grail fields and tags are different. Dynatrace enriches them on every signal (logs, metrics, spans, events, and problems) and on every relevant Smartscape node. This makes them available for routing, segmentation, permissions, and cost allocation consistently across all data types.
When primary Grail fields and tags are in place, the rest of the platform configuration follows naturally. Buckets, access policies, segments, and alert routing all operate on the same consistent metadata. Teams no longer need to maintain parallel tagging strategies across their cloud environments and their observability platform.
This also applies to service names. Rather than encoding environment, region, or team into a service's name, keep the name clean and filter the service list by primary Grail fields and tags. For more information, see Service naming.
For a step-by-step approach to enriching your signals, from out-of-the-box defaults to ingest-time derivation, see Best practices for enriching primary Grail fields and tags.
Once your signals are enriched, you can use primary Grail fields and tags across the platform to manage data at scale. Dynatrace picks up the tags you already maintain in Kubernetes, AWS, Azure, and Google Cloud and uses a selected subset as the source for primary Grail tags. You don't have to rebuild your organizational vocabulary inside Dynatrace. For many common use cases, Dynatrace automatically derives infrastructure context such as Kubernetes clusters and namespaces, host groups, and cloud account identifiers, without any manual configuration.
Use dt.cost.costcenter and dt.cost.product to attribute data storage and processing costs to the responsible teams.
dt.host_group.id or k8s.namespace.name.dt.security_context for record-level access control with custom security boundaries.