12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata

In dynamic enterprise ecosystems characterized by ephemeral containers, auto-scaling microservices, and serverless compute, static configuration is obsolete. Infrastructure and services are continuously provisioned and decommissioned. To maintain control, observability platforms require robust metadata and tagging strategies. In Dynatrace, tags and metadata provide the foundational intelligence that powers automated governance, scoping Management Zones, routing Davis AI alerting profiles, filtering Service Level Objectives (SLOs), and structuring analytics queries in Dynatrace Query Language (DQL).

---

Taxonomy of Dynatrace Tags: Mechanisms and Lifecycles

Dynatrace distinguishes between several distinct types of tags and metadata, each possessing unique lifecycle characteristics, evaluation engines, and operational purposes.

+-----------------------------------------------------------------------------------------+
|                               DYNATRACE TAGGING TAXONOMY                                |
+-----------------------------------------------------------------------------------------+
| 1. MANUAL TAGS                                                                          |
|    • Applied via Web UI or Monitored Entities API v2.                                   |
|    • Statically bound to a specific internal entity ID (e.g., HOST-4B3A82C1).           |
|    • Destroyed when the entity is decommissioned; does NOT survive dynamic recreation. |
+-----------------------------------------------------------------------------------------+
| 2. AUTOMATED RULE-BASED TAGS                                                            |
|    • Defined globally in Settings > Tags > Automatically applied tags.                  |
|    • Evaluated dynamically by the Dynatrace server cluster against entity properties.   |
|    • Instantaneous, retroactive, and supports regular expression value extraction.      |
+-----------------------------------------------------------------------------------------+
| 3. INGESTED CLOUD & CONTAINER METADATA                                                  |
|    • Discovered natively via OneAgent or ActiveGate Cloud Integrations.                 |
|    • Ingests Kubernetes pod/namespace labels, AWS EC2 tags, Azure tags, and GCP labels. |
|    • Stored as read-only entity properties; ideal trigger sources for automated rules.  |
+-----------------------------------------------------------------------------------------+
| 4. AGENT-LEVEL ENVIRONMENT INJECTIONS (DT_TAGS & custom.properties)                     |
|    • Configured directly on compute hosts via configuration management (Ansible/Chef).  |
|    • Statically injected into OneAgent during process initialization.                   |
+-----------------------------------------------------------------------------------------+

Why Manual Tags Fail at Enterprise Scale

Manual tags are added by a user clicking "Add tag" in the Dynatrace UI or posting to /api/v2/entities/{entityId}. While convenient for quick ad-hoc troubleshooting, manual tags are an anti-pattern for enterprise production governance:

• They cannot adapt to auto-scaling events: when an auto-scaling group provisions ten new virtual machines, the new instances lack the manual tags.
• When a Kubernetes pod restarts or rolls to a new deployment replica, its internal entity ID changes, severing any manual tags attached to the previous instance.
• They introduce configuration drift and human error, undermining automated governance pipelines.

---

Automated Rule-Based Tags: Architecture and Mechanics

Automated tagging rules are configured centrally in the Dynatrace web console (Settings > Tags > Automatically applied tags) or through the Configuration API (/api/config/v1/autoTags). Unlike manual tags, automated rules do not bind to static entity IDs; they are continuous evaluation rules executed cluster-side.

Evaluation Engine and Propagation

When OneAgent registers a new entity (host, process group, or service), or when entity metadata updates, the Dynatrace rules engine evaluates all configured auto-tag rules in real time:

1. Target Entity Selection: The rule specifies which entity type it evaluates (e.g., Hosts, Process Groups, Services, Applications).
2. Rule Conditions: Conditions evaluate incoming properties using comparison operators (equals, contains, begins with, ends with, regex match, exists).
3. Tag Assignment: If all conditions match, the specified tag is attached to the entity.
4. Topological Propagation: Rules can optionally propagate tags across Smartscape boundaries (e.g., from Process Groups down to running Services, or from Hosts to Process Groups).

Dynamic Value Extraction Using Regular Expression Capture Groups

A critical feature of automated tagging rules is the ability to dynamically extract tag values from runtime properties rather than hardcoding static strings. This is accomplished using regular expression capture groups ({1}, {2}).

Consider an enterprise where Java microservices are launched with a standard command-line argument defining environment and tier: -Dapp.descriptor=billing-prod-east.

An administrator can configure an automated tag rule as follows:

• Tag Key: Deployment
• Target Entity: Process Groups
• Condition: Process execution command line contains regex: -Dapp\.descriptor=([a-z]+)-([a-z]+)-([a-z]+)
• Tag Value Definition: {1}:{2}
• Resulting Tag Attached: Deployment:billing:prod

This single dynamic rule automatically extracts and assigns precise, standardized key-value tags across thousands of diverse applications without requiring custom code or manual intervention.

---

Native Cloud and Container Metadata Ingestion

Modern cloud-native platforms already possess rich metadata frameworks. Dynatrace automatically discovers and leverages these existing metadata streams, eliminating redundant data entry.

Kubernetes and OpenShift Metadata Discovery

OneAgent natively communicates with the local node kubelet and Kubernetes API server. It automatically captures pod, node, and namespace metadata and attaches them as read-only entity properties:

• Pod Labels: Captured as [Kubernetes]pod.label.* (e.g., app.kubernetes.io/name, app.kubernetes.io/version, release).
• Namespace Annotations & Labels: Captured as [Kubernetes]namespace.label.*.
• Workload Metadata: Workload name, controller kind (Deployment, StatefulSet, DaemonSet), container image repository, and container image tag.

These properties are immediately accessible within automated tagging rule conditions. For example, an automated rule can state: "If [Kubernetes]pod.label.app exists, apply tag Service:{[Kubernetes]pod.label.app}".

Hyperscaler Cloud Tag Ingestion (AWS, Azure, GCP)

Through ActiveGate-based cloud platform integrations, Dynatrace continuously polls cloud APIs to enrich monitored entities with cloud-native tags:

• Amazon Web Services (AWS): Discovers AWS EC2 tags, RDS tags, Auto Scaling Group tags, and Lambda tags. Read-only properties appear in Dynatrace with the prefix [AWS]TagKey.
• Microsoft Azure: Discovers Azure Resource Manager (ARM) tags across VMs, App Services, and Azure SQL instances.
• Google Cloud Platform (GCP): Captures GCP labels across Compute Engine instances and Google Kubernetes Engine (GKE) clusters.

---

Agent-Side Host Configuration: DT_TAGS, custom.properties, and hostautotag.conf

In scenarios where entities must carry local metadata established by infrastructure automation tools (e.g., Terraform, Ansible, Puppet, Cloud-Init) before communicating with the Dynatrace cluster, OneAgent provides local configuration hooks.

Configuration Mechanisms Comparison

Best Practice Recommendation: Prefer using custom.properties over DT_TAGS. Defining custom properties allows infrastructure teams to publish clean metadata keys (DataCenter, Owner, Environment) without cluttering the UI with unmanaged static tags. The Dynatrace administrator can then build centralized, automated rule-based tags that evaluate those custom properties.

---

Tagging Strategy Evaluation Matrix

---

Enterprise Tagging Best Practices: The Key-Value Pattern

To prevent tag pollution and ensure consistency across large organizations, enterprises must enforce a strict Key-Value tagging convention (key:value). Single-string tags (e.g., production, java, linux) create ambiguity and cannot be queried efficiently.

Standardized Enterprise Taxonomy Schema

1. env:<stage> — Environment lifecycle stage (env:prod, env:staging, env:dev).
2. owner:<team> — Responsible engineering team (owner:payments-sre, owner:order-fulfillment).
3. service:<name> — Canonical service identifier (service:billing-api, service:catalog-service).
4. tier:<architecture> — Architectural tier (tier:frontend, tier:backend, tier:database).
5. compliance:<standard> — Regulatory compliance requirement (compliance:pci-dss, compliance:hipaa).

Standardized key-value tags allow administrators to define universal Management Zones (e.g., matching owner:payments-sre), universal Alerting Profiles, and multi-dimensional SLO charts that dynamically populate without touching platform settings when new microservices deploy.