Dynatrace’s Auto-Tagging feature, when configured with rules, doesn’t just add labels; it fundamentally rewrites the identity of your entities in real-time based on observed attributes.
Let’s see it in action. Imagine you have a Kubernetes cluster and you want to tag all pods belonging to your "frontend" deployment with the tag environment=production.
First, you’d navigate to Settings -> General -> Tags in your Dynatrace environment. Then, you’d click Add tag rule.
Here’s how you’d set up the rule:
Tag value: environment=production
Apply to: Kubernetes Pod
Conditions:
Kubernetes Pod|Deployment Name|Equals|frontend
Once saved, Dynatrace continuously monitors incoming telemetry. When a pod with the deployment name frontend is detected, this rule automatically attaches the environment=production tag to it. This isn’t a manual process; it’s an automated, dynamic classification.
This capability is crucial for observability because it allows you to slice and dice your data not just by what the entity is (e.g., a Kubernetes Pod), but by how it’s behaving or what its logical role is.
Internally, Dynatrace uses a powerful pattern-matching engine. When new data points arrive – be it metrics, logs, or traces – Dynatrace checks them against your defined tag rules. If an entity’s attributes match a rule’s conditions, the specified tag is applied. This happens at ingestion, meaning your data is immediately enriched with these contextual tags.
The primary problem this solves is the manual toil of tagging. Without auto-tagging, you’d be creating tags manually for every new service, every new environment, or every change in your infrastructure. This is error-prone and doesn’t scale. Auto-tagging ensures consistency and accuracy, especially in dynamic, ephemeral environments like Kubernetes.
You have granular control over what gets tagged and how. You can tag based on:
- Entity Type: Kubernetes Pods, Services, Hosts, Processes, Cloud Applications, etc.
- Attributes: Deployment names, process group names, host properties (like cloud provider tags), specific metadata within logs or traces, etc.
- Conditions: Equals, not equals, contains, starts with, ends with, regex matches.
You can also combine multiple conditions using AND and OR logic to create highly specific tagging strategies. For example, you could tag all Kubernetes Pods that are part of the frontend deployment and have a region attribute of us-east-1 with environment=production.
Consider a scenario where your application has different tiers: frontend, backend, and database. You could have three separate tag rules:
-
Tag value:
tier=frontendApply to:Kubernetes PodConditions:Kubernetes Pod|Deployment Name|Equals|frontend -
Tag value:
tier=backendApply to:Kubernetes PodConditions:Kubernetes Pod|Deployment Name|Equals|backend -
Tag value:
tier=databaseApply to:Process GroupConditions:Process Group Name|Contains|postgres
This allows you to instantly filter and analyze metrics, traces, and logs for each tier independently, enabling targeted performance analysis and troubleshooting.
The true power of rule-based tagging lies in its ability to infer context that isn’t explicitly present as a tag itself. For instance, if your Kubernetes nodes have cloud provider tags like Owner=Finance and you’re running a specific set of applications on those nodes, you can create a rule that tags those application entities with department=Finance based on the node’s existing cloud tags. This bridges the gap between infrastructure metadata and application context without requiring direct modification of application deployments or Dynatrace’s OneAgent.
The most surprising aspect for many users is how Dynatrace handles tag conflicts or overlapping rules. If multiple rules apply to the same entity, Dynatrace prioritizes based on the explicit order of your tag rules. The first rule that matches and applies a tag to an entity takes precedence for that specific tag value. However, if different rules apply different tags to the same entity, all those tags are applied. This means you can have an entity tagged with environment=production from one rule and service=auth from another, and both will coexist.
The next logical step after mastering auto-tagging is to leverage these tags for sophisticated alerting and anomaly detection.