Best practice examples - from Management Zones to Segments

• 60-min read
• Published Jul 10, 2025

Scope

This guide helps you to upgrade from management zones to segments in the latest Dynatrace, sharing best practices for fully supported scenarios. We will add further scenarios in the future.

Why upgrade

With the introduction of the latest Dynatrace, it was necessary to introduce new concepts to meet the requirements for monitoring cloud and AI native environments in terms of scale and manageability.

While management zones have been used widely in Dynatrace to define access to data and filter data on a global level, in the latest Dynatrace they have been replaced by three new concepts, each tailored to satisfy the respective requirements of Enterprise environments:

In this upgrade guide, you will find practical examples that show how to upgrade from existing management zones to segments.

Auto-tagging scenarios

If you rely on entity auto-tagging to define your management zones, the following sections offer examples of how you can move from auto-tagging to segments.

Auto-tagging based on process name, host name, service name, or metadata

Other than in cloud native scenarios (Application-only OneAgent injection), when the tags are based on process name, host name, service name, or their metadata, we recommend tagging via host tags at the source.

The following example shows a possible tagging configuration.

To set the host tags for a management zone via the OneAgent deployment configuration page

Repeat the above procedure for each management zone.

The result of this change is that, in Grail, on every signal sent by the selected hosts, the key-value will be on every signal as a field value combination.

Note that for signal data originating from processes with an injected code module, a process restart is required for the change to take effect.

Exceptions

Derived data such as service metrics, which are calculated based on span data, don’t get every key-value that you add on the OneAgent side as a dimension. Currently, only keys will be carried over to derived data: dt.security_context, dt.cost.costcenter, and dt.cost.product.

However, you can propagate your OneAgent set tag to Davis problems. In settings, you need to configure your tag to be propagated to Davis problems.

If the host level is not granular enough for you, you can set environment variables on the process level (DT_TAGS and OTEL_RESOURCE_ATTRIBUTES), which triggers signal enrichment on the process level.

In the segment configuration, you add a new variable with a DQL query.

Auto-tagging based on host group names

Once the host group is set, all signals sent by the OneAgent are enriched with it as the dt.host_group.id field. There is no need to tag the data in Grail. In scenarios where a host group matches exactly a management zone, the variable definition could look as follows.

fetch dt.entity.host_group
| fields hgName = entity.name, tag = concat("HG:", entity.name)

In the example above, the auto tag's name is HG. You need this in the variable definition because you want to match the Davis problems with that tag, since the Davis problems are enriched with the corresponding entity tags.

The segment definition looks as follows.

Note: The preview for segments based on entities currently is not working. This is a known issue that will be resolved soon.

Auto-tagging based on extraction of host group names

Suppose there is systematic host group naming, where the value of the host group name is composed of various environmental information split by a dash.

For example, you have <CMDBID>-<AppName>-<component>-<deploymentEnvironment>.

You're extracting here the CMDBIDs and tagging all related entities with the CMDBID. The CMDBID can consist of multiple apps and components. To keep the example DQL simple, let's limit this to three host groups per CMDBID.

In the DQL query for the variable definition, you would need to parse the environmental information. Let’s call the information “dimensions”.

To make the segment more user-friendly, let’s give the end user the possibility to select the application name. The idea here is that, based on the application name, the host group name filter will be applied to all the data.

Here is the DQL query:

fetch dt.entity.host_group
| parse entity.name, "LD:CMDBID '-' LD:app '-' ld:component '-' Ld:stage"
| filter isNotNull(CMDBID)
| fieldsAdd tag = concat("CMDBID:",CMDBID )
| fields CMDBID, tag
| dedup CMDBID
| sort CMDBID asc

In the variable definition, you also have a field tag, which represents the CMDBID tag you put on every entity. You need that because you want to match the Davis problems with that tag, since the Davis problems are enriched with the corresponding entity tags.

The segment definition looks as follows.

Similarly, you can add additional segments for every dimension, and thus slice and dice all your observability data based on your dimensions derived from the host group name.

Auto-tagging based on Kubernetes namespace or cluster

All signals coming from a OneAgent that is deployed in a Kubernetes environment enrich every signal with the Kubernetes cluster name and the Kubernetes namespace.

Here the cluster or namespace name is propagated as tag to all the related entities. The segments variable definition would look as follows.

fetch dt.entity.cloud_application_namespace
| fields namespace = entity.name
| dedup namespace
| fieldsAdd tag = concat("Namespace:", namespace)

In the variable definition, you also have a field tag, which represents the namespace tag you put on every entity. You need that because you want to match the Davis problems with that tag, since the Davis proble ms are enriched with the corresponding entity tags.

The segment definition looks as follows.

Auto-tagging based on host tags/host properties

If your auto tags are based on host tags set upon OneAgent installation or via the oneagentctl (as described in Define tags and metadata for hosts), defining the segment should be relatively easy. Every signal sent by the OneAgent is enriched with the tags defined on the OneAgent side.

Assume that the host tag you add has the tag key App. This means that, in the web UI, the tag is visible on the host level with the [Environment] prefix. Furthermore, you propagate the tag as tag App to all related entities.

The variable definition of the segment would look like this:

fetch dt.entity.host
| expand tag = tags
| fields tag
| filter startsWith(tag,"[Environment]App")
| parse tag, """'[Environment]App:' LD:app"""
| fields app, tag = concat("App:", app)

In the variable definition, you also have a field tag, which represents the App tag you put on every entity. You need to do this because you need to add the entities to the segment.

The host tag you add on OneAgent doesn't enrich any derived signal on top of the raw data, like service metrics or Davis problems (except for field names/keys dt.security_context, dt.cost.costcenter, and dt.cost.product). However, for Davis problems, you can propagate your OneAgent set tag to Davis problems. In Settings, you need to configure your tag to be propagated to Davis problems as follows.

Non-auto tagging scenarios

Instead of relying on tags, your management zone definition could be based on process name, host name, service name, or metadata. If this is the case, follow the instructions in the Auto-tagging based on process name, host name, service name, or metadata section.

There, you need to introduce a new tag with a key such as Segment, and with the value set to the name of the management zone. This will allow you to segment all the data coming from OneAgents not running in cloud-native environments, where the OneAgent is injected into the application only.

Extension scenarios

Segments support filtering on signal data from extensions, not on entities created by extensions. With Dynatrace extensions, you can configure the enrichment attributes Security context, Product, and Cost center for every extension configuration.

In the following example, you see the enrichment configuration for a Postgres instance.

Assume that you have a management zone per product and that a host group is set up for every product. Your segment variable definition would be as follows.

fetch dt.entity.host_group
| fields hg = entity.name

The segment definition would be as follows.

Note that you need to add the entities related to the host entity to the segment based on your needs.

Cloud-native scenarios

In cloud-native scenarios where the OneAgent is only injected into the application, you need to set environment variables so that the signals coming from that application are enriched with data.

Let’s have a look at the following example.

This will make sure that every metric, Davis event, and span is enriched with the fields dt.security_context, App, and stage. In addition, the related process group instance metric gets that information added as tags.

Currently, you need to set those three environment variables. Note that the DT_TAGS and OTEL_RESOURCE_ATTRIBUTES variables might look the same, but there's a semantic difference (a colon instead of a space as a separator). Improvements for the future are already planned.

Derived data such as service metrics, which are calculated based on span data, don’t get every key-value that you add within the environment variables. Currently, only keys will be carried over to derived data: dt.security_context, dt.cost.costcenter, and dt.cost.product.

However, you can propagate your OneAgent set tag to Davis problems. In Settings, you need to configure your tag to be propagated to Davis problems.