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.
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 Grail fields are built-in and enriched automatically. Primary Grail tags are customer-defined and follow the primary_tags.* prefix.
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.
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:
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. A small set of well-maintained tags is more valuable than a large set of stale ones.
Cover ownership and environment first. These unlock access control and segmentation.
Align with what you already have.
If your Kubernetes namespaces, AWS accounts, or Google Cloud projects already encode environment or team information, map those to your tag keys rather than inventing parallel naming.
Automate from day one.
Tags that were set up manually drift over time. Inject them through your deployment pipelines, Helm charts, Terraform modules, or OneAgent installation scripts so they're consistent and version-controlled.