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 are key-value pairs that add business and operational context across the platforms and tools that make up your IT landscape. A consistent tagging strategy connects technical entities to the teams, environments, applications, and cost centers that own them, making telemetry data actionable at scale. By picking up the tags you already maintain in AWS, Microsoft Azure, Google Cloud, and Kubernetes, and by enriching every signal through primary Grail fields and tags, Dynatrace makes your existing organizational vocabulary available across metrics, logs, spans, and events.
Tags are a universal concept across modern cloud infrastructure. Every major cloud provider and many enterprise software platforms use them as the primary mechanism for organizing, governing, and attributing resources.
Enterprises invest significant effort in establishing tagging strategies that define which tags track ownership, environment, cost center, application, and business unit. These tags are used in cloud billing dashboards, security policies, and deployment pipelines, and they represent a shared organizational vocabulary.
Dynatrace tells you what is happening through telemetry data and topology, and why it's happening through Dynatrace Intelligence causal AI root cause analysis. Organizational context (which team owns a service, which environment it runs in, which cost center it belongs to) is what makes telemetry actionable. Without consistent metadata across all signals, three problems emerge:
Duplicate effort: The same ownership information appears in your Kubernetes labels, AWS tags, and Dynatrace. Each source is maintained separately and often out of sync.
Incomplete access control: Enforcing fine-grained permissions requires the same fields on every telemetry signal (logs, metrics, spans, events, and problems), regardless of where each one originates. Gaps in coverage mean gaps in enforcement.
Fragile filtering: When organizational metadata is missing from parts of your telemetry or topology, dashboards and alerts silently return incomplete data, with no indication that anything was filtered out.
Dynatrace uses the tags it already maintains and makes them consistently available across all signal types and topology nodes.
Your existing cloud tags, Kubernetes labels, and tags applied to Smartscape nodes are a natural starting point, but they're only available on Smartscape nodes. They don't follow data into the telemetry pipeline, so you can't use them to route data, assign Grail buckets, allocate cost, or enforce access control on logs, metrics, spans, or events.
To close this gap, Dynatrace provides primary Grail fields and tags, enriched on every signal and every relevant Smartscape node before data enters the processing pipeline.
primary_tags.* prefix. The full tag key (for example, primary_tags.team) is never defined in the semantic dictionary; only the primary_tags.* namespace is reserved.Both are available for routing, segmentation, permissions, and alerting across all data types.
A tagging strategy is a planned, standardized approach.
In Dynatrace, a tagging strategy defines how and why tags are assigned, ensuring that the resulting metadata accurately reflects the business, operational, and technical context. The core principle is to follow the tagging strategy you already have, not create a new one. If you already tag resources in AWS, Azure, Kubernetes, or a CMDB such as ServiceNow, Dynatrace consumes those tags directly. You configure which of your existing tags to make primary tags in Dynatrace, with no new tagging infrastructure required.
A good tagging strategy doesn't need to be exhaustive. Start with the attributes that matter most for your use cases and expand from there.
The following table lists the most commonly used tags.
| Attribute | What it captures | Example tags |
|---|---|---|
Ownership | The responsible team |
|
Application | The service or application name, plus its identifier in a CMDB or internal registry |
|
Environment | The environment where the workload runs |
|
Business unit | The part of the organization it belongs to |
|
Geography | Region or country, when relevant for compliance or routing |
|
Cost allocation | Cost center and product, for financial attribution |
|
A few practical guidelines for tagging strategy:
Start with what you already have
Dynatrace is designed to follow your existing tagging strategy, not replace it. If you already tag resources in AWS, Azure, Kubernetes, or a CMDB such as ServiceNow, map those existing tags to primary Grail tags, don't create a parallel naming scheme in your Dynatrace configuration.
Agree on valid values up front
Decide per tag key whether values should be constrained.
Environment, region, and security classification benefit from an enforced allowlist: the number of valid values is small, and mistakes are costly.
Team names and application identifiers are typically open-ended and harder to enumerate upfront.
Start lean
Automate from day one
You don't have to wait for all features to be generally available. The enrichment you configure today is already usable and will carry over once full primary Grail tag support is rolled out.
Assess your current state
Start enriching at the source
Set up platform foundations
Migrate progressively