topic Re: Classic Dashboard vs DQL: Problem Count Differences Using Management Zones in DQL

Classic Dashboard vs DQL: Problem Count Differences Using Management Zones

Gabriel_BR_ — Mon, 23 Mar 2026 19:03:24 GMT

I need to update a classic dashboard to DQL.

However, in the classic dashboard it points to both open and closed problems based on the Management Zone (MZ).

In the new model, I’m not able to achieve the same result. It would be possible to use segments, but the problem counts shown in the classic view and in the DQL/segments do not match.

Has anyone experienced this before?

Below are the DQL and segment models.

---------------------

dt.management_zone.id = "XXXXX" OR (event.kind= DAVIS_PROBLEM)

--------------------------

fetch dt.davis.problems.snapshots
| filter dt.davis.is_duplicate == false
| dedup display_id

Re: Classic Dashboard vs DQL: Problem Count Differences Using Management Zones

AntonPineiro — Tue, 24 Mar 2026 08:00:50 GMT

Hi,

Which entities are impacted by those problems? Host?

Best regards

Re: Classic Dashboard vs DQL: Problem Count Differences Using Management Zones

t_pawlak — Tue, 24 Mar 2026 10:16:58 GMT

Hi,
Yes, I think this is the key question, because this is usually where the difference comes from.

IMO the issue is that Classic Management Zones and the new Segments are not a 1:1 mapping, so the same problem counts will not always match after migration. Dynatrace even has a dedicated upgrade guide from MZ to Segments, which suggests adapting the use case rather than just copying the old filter logic.

Then your DQL:

fetch dt.davis.problems.snapshots | filter dt.davis.is_duplicate == false | dedup display_id

This can produce different numbers than Classic, because dt.davis.problems.snapshots works on problem snapshots over time, not simply on the list of unique problems. In the current Dynatrace documentation, the recommended dataset for unique problem queries is rather fetch dt.davis.problems, for example with not(dt.davis.is_duplicate), and for active problems additionally event.status == "ACTIVE".

So I would first test something like:

fetch dt.davis.problems | filter not(dt.davis.is_duplicate) | summarize problem_count = count()

or only open one:

fetch dt.davis.problems | filter not(dt.davis.is_duplicate) | filter event.status == "ACTIVE" | summarize problem_count = count()

Also, with Segments it is very important to understand which entities are impacted by those problems. If the problems are tied to hosts, services, process groups, or other entity/data types, the segment needs to include the correct scope. Otherwise, the count shown in Dashboards/DQL may differ from what Classic MZ-based views displayed before. Dynatrace’s segment documentation also highlights that results depend on the correct data scope being included.
Documentation here:
Analyze monitoring data with segments

Re: Classic Dashboard vs DQL: Problem Count Differences Using Management Zones

Gabriel_BR_ — Tue, 24 Mar 2026 19:31:24 GMT

Hi,

Thanks for the explanation — that makes sense and helps clarify part of the behavior.

The Segment I configured is based on the following rule:

(event.kind = DAVIS_PROBLEM AND (dt.host_group.id = "APP_SPN" OR entity_tags = SPN))
OR (event.category = CUSTOM_ALERT AND event.status_transition = "CREATED" AND event.name = "SPN") AND dt.davis.is_duplicate = "false"

When I compare the results:

In the Classic Problems view (today) → I get 6 problems
Using DQL with the Segment applied → I get 13 problems

Query used in DQL:

fetch dt.davis.problems
| filter not(dt.davis.is_duplicate)
| dedup display_id

So even using dt.davis.problems (as recommended instead of snapshots), there is still a noticeable difference in the number of problems.

From what I can see, it seems that the Segment is including additional problems that are not shown in the Classic MZ view — possibly due to differences in how entity relationships or scope are evaluated.

Do you think this discrepancy is expected due to how Segments evaluate impacted entities vs. how Classic MZ scopes problems?

Thanks in advance!