Dynatrace management zones and automatic tagging: structuring a shared environment

A Dynatrace Managed environment that monitors a few dozen hosts can be browsed by eye. When it monitors several thousand, spread across twenty or so teams, three datacentres and Kubernetes clusters that are born and die every day, navigation becomes an exercise in patience. Dashboards mix everything up, alerts go to the wrong people and every team asks for « its own » environment. This is precisely the problem that Dynatrace management zones, combined with automatic tagging, are designed to solve.

Creating one environment per team is tempting, but costly in Managed: each environment has its own settings, tokens, integrations and quotas to administer, and the end-to-end view (Smartscape, distributed traces across services owned by several teams) ends up cut into pieces. Most of the time, the right answer is a shared environment structured by two complementary mechanisms: automatic tagging and management zones.

This article explains the role of each, proposes a naming convention and details the setup step by step, including a pass through the API to industrialise it.

Tags and Dynatrace management zones: who does what?

The tag, a label

A tag is metadata attached to an entity (host, process group, service, application…). It can be manual, imported (DT_TAGS environment variable, Kubernetes labels, cloud metadata) or automatic, meaning computed by a rule that Dynatrace evaluates continuously. Tags are used to filter, to target settings and to build rules.

The management zone, a scope

A management zone is a logical subset of entities defined by rules. It serves three purposes: filtering the interface and dashboards, restricting a user group’s permissions, and targeting alerting profiles. An entity can belong to several zones.

Criterion	Automatic tag	Management zone
Nature	Attribute of an entity	Set of entities
Main use	Classify, filter, target	Partition, restrict access
Security impact	None directly	Yes, through group permissions
Best practice	Many, fine-grained	Few, stable

The winning pattern is to classify with tags, then build zones from the tags. Zone rules then stay short and readable.

A naming convention first

Settle on a small vocabulary of lowercase tag keys, and stick to it:

• env: prod, preprod, staging, dev;
• app: application code from your CMDB;
• team: owning team;
• dc: datacentre or region;
• tier: front, back, data, middleware.

Zones follow a format such as {env}-{app} or team-{team}. Avoid names of people or temporary projects: a zone is referenced by groups, alerting profiles and dashboards, so renaming it has a cost.

Step-by-step tutorial

Step 1 — Set metadata at the source

The most reliable automatic tag is one based on information that already exists. When deploying OneAgent, set the host group, which often encodes environment and application:

sudo /bin/sh Dynatrace-OneAgent-Linux.sh \
  --set-host-group=prod_payments \
  --set-network-zone={network-zone}

On an existing host, add host tags with oneagentctl:

sudo /opt/dynatrace/oneagent/agent/tools/oneagentctl --set-host-tag=team=payments --restart-service

For processes, the variable DT_TAGS="app=payments tier=back" in the process environment is also taken into account. On Kubernetes, pod labels and annotations can be used by the rules.

Step 2 — Create the automatic tagging rules

In the environment (https://{your-domain}/e/{environment-id}), open the automatically applied tags settings. For example, create an env tag whose value is extracted from the host group via a dynamic value format, with the condition « host group name exists ». Enable propagation to the processes and services running on the host: this is what lets a service inherit its host’s tag.

Then create team and app on the same principle. Check the result in the hosts view by filtering on the tag: every expected entity should appear.

Step 3 — Build the management zones

In the management zones settings, create prod-payments with a single rule: entities carrying the tags env:prod and app:payments, applied to hosts, process groups, services and web applications. The rule stays short because the classification work has been done by the tags.

Step 4 — Industrialise through the API

Once the first zone has been validated by hand, export its definition and replay it for the other applications. With an environment token that has the settings read and write scopes:

export DT_ENV="https://{your-domain}/e/{environment-id}"
export DT_TOKEN="{token}"

# List the management zone configuration objects
curl -s -H "Authorization: Api-Token $DT_TOKEN" \
  "$DT_ENV/api/v2/settings/objects?schemaIds=builtin:management-zones&fields=objectId,value" \
  | python3 -m json.tool > mz-export.json

Adapt the exported JSON (name, tag values), then create the new zone with a POST to the same endpoint. Schema IDs (builtin:management-zones, builtin:tags.auto-tagging) and their structure change between versions: check them in your environment’s API explorer. Store these JSON files in Git: they are your governance reference.

Step 5 — Connect zones to access and alerting

In the CMC, restrict the dt-prod-payments group to the prod-payments zone (see the users, groups and permissions model). Then, in the environment, create an alerting profile filtered on that zone. The team sees and receives only what concerns it.

Step 6 — Check coverage

Create a « safety net » zone, for example no-team, grouping entities without a team tag. It should trend towards zero; anything that lands there is an orphaned entity to be assigned.

Best practices

• Tags at the source: host group, DT_TAGS, Kubernetes labels rather than rules on fragile hostnames.
• Zones built on tags, never on complex regular expressions.
• Few zones: a few dozen at most per environment, aligned with stable areas of responsibility.
• Configuration as code: export and import through the API, review by pull request.
• Performance: a large number of complex rules weighs on evaluation; simplify regularly. Documented limits per environment: 300 UI-based zone rules for entities (150 up to version 1.323), 100,000 conditions in total, and at most 200 zones per entity.
• A safety-net zone to detect unclassified entities.

Frequently asked questions

Should you create one environment per team?

Rarely. In Managed, each environment brings its own settings, tokens, integrations and quotas to administer, and the end-to-end view across services owned by several teams gets cut up. A shared environment, structured by tags and management zones, usually meets the need.

Can an entity belong to several management zones?

Yes. The same service can sit in its application’s zone and in its team’s zone, for example. That is one more reason to keep zones few, stable and built on tags.

How do you find entities that slip through the classification?

Create a « safety net » zone grouping entities with no team tag. It should tend towards zero: every entity that shows up there needs to be attached, ideally by fixing its metadata at the source.

Conclusion

Automatic tags and management zones turn a shared Managed environment into a readable workspace for every team, without multiplying environments to administer. The recipe comes down to three ideas: set metadata at the source, classify with tags, partition with zones built on those tags. Combined with user groups and alerting profiles, they become the foundation of your entire observability governance.

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Dynatrace is a trademark of Dynatrace LLC. Always check values (ports, versions, sizes) against the official documentation for your Managed version.

---

Originally published on span.observer. French version: https://span.observer/fr/management-zones-tagging/.