This documentation describes the new tagging model for Latest Dynatrace. Some capabilities are still rolling out. If you're currently using Dynatrace Classic auto-tagging, see Dynatrace Classic versus Latest Dynatrace to understand how your existing setup maps to the new model.
Tags add the organizational context that turns telemetry into something teams can act on. In Dynatrace, a consistent tagging strategy lets you carry ownership, environment, application, and cost information across logs, metrics, spans, events, and Smartscape nodes, so the same metadata is available in both telemetry and topology.
The challenge is making existing metadata consistently available across every signal type in Dynatrace. This is possible with Primary Grail fields and tags. Dynatrace automatically enriches logs, metrics, spans, events, and problems, as well as Smartscape nodes, with the same metadata before data enters the processing pipeline. This means the same fields are available for routing data to the right pipeline, assigning Grail buckets, enforcing access control, allocating costs, and filtering dashboards and alerts. You don't need to rebuild your organizational vocabulary inside Dynatrace; Dynatrace picks up the tags you already maintain and makes them work across your entire observability setup.
Teams use tags in Dynatrace to solve a small set of high-value problems repeatedly across environments and signal types.
| Platform capability | How primary Grail fields and tags help |
|---|---|
Data routing | Route telemetry to the right pipeline based on |
Bucket assignment | Assign telemetry to Grail buckets based on primary fields and tags to control retention and cost. |
Grail permissions | Enforce access policies so teams only see the telemetry that they own. |
Cost allocation | Attribute costs per team or product with |
Segments | Filter dashboards, notebooks, and data to a specific application, environment, or business unit. |
Alerting | Scope alerting and workflow automation to the right owners and operational context. |
Learn what tags are and why they matter.
Learn how primary Grail fields and tags form the metadata foundation of the Dynatrace platform.
Follow a fallback approach to enriching your signals, from built-in defaults to ingest-time lookup.
Compare Dynatrace Classic auto-tagging with primary Grail fields and tags.
Use your Dynatrace Classic setup as input for primary Grail fields and tags.
Apply primary Grail fields and tags through OneAgent installation and runtime configuration.
Promote Kubernetes labels and annotations to primary Grail fields and tags using the Dynatrace Operator.
Enrich data from Dynatrace extensions with primary Grail fields and tags.
Propagate AWS resource tags to primary Grail fields and tags for unified observability.
Propagate Azure resource tags to primary Grail fields and tags for unified observability.
Propagate Google Cloud labels and tags to primary Grail fields and tags for unified observability.
Apply tags in Real User Monitoring and Synthetic Monitoring for digital experience observability.
Coming soon
Map OpenTelemetry resource attributes to primary Grail fields and tags.
Configure pipelines, buckets, permissions, and segments using data fields instead of entity IDs.
Restrict record-level access to telemetry using dt.security_context.
Attribute DPS consumption to teams and cost centers using dt.cost.costcenter and dt.cost.product.
If earlier-stage enrichment and central tag configuration don't cover your use case, use OpenPipeline primary Grail tag rules to derive primary Grail tags from existing record fields at ingest-processing time.