A new way to look at Management Zones and the new future design-segments.

[ChadTurner]

Recently we have been engaging with other customers of Dynatrace. The vast majority of these customers build Management Zones looking at the individual application level. While this method allows you to be granular at the app level, it also provides hard breaks between applications. 

Banking as an example - If MyBank was one of your applications, you would most likely have its own Management Zone, but what about the steps prior to the user getting into the 'MyBank' app? What about your login/authentication segment? Before a customer can access that Banking app, they need to authenticate with another segment of your tech stack. You might very well have built out a Management Zone called "Login/Authentication" Which is indeed the proper use of Management Zones, but this is where we saw a new view point in the use of Management Zones. In this scenario, we have two Management Zones that allows us to keep the infrastructure separate as they serve two different functions, but in the eyes of the customer, this is journey of the Customer - Step 1 - Login, Step 2 - Leverage the Applications. So why not build out a Management Zone that encompasses all the segments of the users Journey. Call it "MyBank Login Journey". 

User Journey as a Management Zone - By building a Management Zone that brings in all of the tech from the customers perspective, you allow the ability to create dashboards/alerts on segments that would directly impact the customers journey as they tech is directly ties to the users RUM Session. All while removing traces and calls to irrelevant segments that would live outside of the customers journey. 

Building it out - We took this idea and started to put it into action. Targeting the defined Application as the primary source, using Login and MyBank app designs. We did this via relationships, and placing a tag on the monitored entity. So (Think of Smartscape layers) services are related to Applications, we first tag our two applications being Login and MyBank, Then we tag the Services Related to the two targeted applications. Then we take one step back and tag Process Group Instances as they are related to Services, Then Process Groups related to Process Group Instances, Then Process Groups to Hosts. We just keep linking tags based off each layer of a relationship, much like how smartscape works natively. Then we leverage a Management Zone that is named "MyBank Login Journey" Which now gives a clear depiction of the users journey as the Login, and get deposited into the primary application. 

It is important to note that this relationship design only works if you are using full stack and have an application defined out. For segments that are leveraged but are not linked to any of the defined application(s) you will need to add them into the Management Zone or add in the tag to allow them to be included in the Management Zone. 

I hope this new way of looking at Management Zones (Converting to Segments) from the customers perspective, allows you to build effective groupings and help facilitate dashboard and data aggregation designs. 

[MarwanC]

Thanks, Chad, for the insightful analogy. Management Zones remain an essential part of Dynatrace, providing high-level segmentation across environments. Segments, on the other hand, introduce a granular approach to data grouping, offering a more refined view into observability at a lower level. Your analogy of Management Zones being the helicopter view and Segments being the deep-dive analysis is a fitting representation of how these two concepts complement each other. You argeee with me that MZ should not be removed in the future?
It would be valuable to gather best practices from customers and partners regarding the newly introduced Segments, especially since they were not available in previous already matured implementations. The way organisations leverage this feature will help refine its practical applications and improve the overall monitoring strategy.

Regarding the disappearance of Management Zones from dashboards, they are still clearly represented within Smartscape visualization, which ensures structural visibility. However, the shift away from direct dashboard integration raises questions about design intent. If this aligns with Dynatrace's planned direction, understanding how Management Zones are meant to be leveraged outside of dashboards will be crucial. In my view, Management Zones still serve an important role within dashboards, particularly in providing filtered perspectives on large-scale environments.

When creating Segments, the selection criteria currently seem restricted, with Host Groups being one of the available options alongside of course low-level data and event selection. Expanding the selection possibilities could enhance data organization flexibility. It would be interesting to understand Dynatrace’s roadmap for Segments—whether additional filtering and grouping mechanisms will be introduced and how this impacts broader observability strategies.

This conversation highlights the evolution of data structuring within Dynatrace, and it would be great to see community insights and practical use cases as the platform continues to evolve. What are your thoughts on potential improvements for Segment configurations and the initial best practices outlined below:

Initial Thoughts Best Practices 

Practice Recommendation

Model by domain	Build segments around ownership/responsibility domains (e.g., “Payments flow in Prod-XX” for App Z)
Limit includes	Only include necessary  entities to keep segments efficient
Use variables wisely	Parameterise segments (e.g., cluster selection) for reusability
Leverage one-entity traversal	Don’t exceed a single entity-to-entity relationships
Avoid overcomplication	Use reasonable grouping to fit the Helicopter view vs Deep Diving Pattern
Fine-tune permissions	Ensure segments are usable  in e.g; Distributed Tracing App etc..

[MarwanC]

*Chad