Problem notifying to Different alerting profile

[Bramham]

Team, I have a setup where the Low Disk space problem notification is delivering to two alerting profiles but one of them Alerting profile & MZ no where added a rule to have this particular entity in it.

Is there any chance that by mount wise this particular problem routing to different alerting profile.?

[Bramham]

Pleas help me to remove the alerting profile for future unwanted notifications.

[lubrman]

HI @Bramham 

It’s possible to set up routing using different levels of tags for example, based on the host on which the disk is detected. Alternatively, if you use the Filesystem extension, you can configure a metric event on a specific metric, define a tag there, and reference that tag directly in the alerting profile.

[Bramham]

Yes, thanks that may work but my question is that there is nothing like you mentioned but still I have email notification for other hosts which is no where part of my MZ or AP.

Now would like to check if there is any way that not included to MZ or AP and should not deliver the notification.

[t_pawlak]

Hi

If you’re seeing notifications from an alerting profile that you believe shouldn’t match, there are a couple of things worth double-checking:

• Default alerting profile – Every environment has a default profile that applies if no other filter matches. If your disk problem isn’t explicitly covered by your custom MZ/AP rules, it might still fall back to the default one.

• Overlapping conditions – Even if the management zone doesn’t include that host, tags or global conditions in another alerting profile could be broad enough to catch it.

• Metric events / extensions – As @lubrman mentioned, custom metric events or filesystem extensions can trigger based on host tags rather than MZ membership.

• Notification integration scope – Check if your email/notification integration is linked to more than one profile (sometimes the same integration is referenced in multiple APs).

To stop unwanted alerts you can:

1. Narrow down filters in the alerting profile (for example by tags or MZ explicitly).

2. Create a dedicated AP for the entities you do want and remove them from the broader/default one.

3. Review whether the default alerting profile should be disabled or limited.

That way, only the entities you explicitly define will send notifications.

[Bramham]

Sure, let me give more detailed about this use case.

We have a problem detected in Dynatrace for Low disk space on multiple hosts.

And we have 2 Alerting profiles with 2 MZ, choosing 1MZ for each of AP respectively.

AP 1 & MZ 1 

AP 2 & MZ 2

And now the host with low disk space alert is only in MZ 1 and delivered alert for AP1.

Also for Default alerting profile & AP2, So now would like to investigate why its sent notification to AP2. My concern is that I'm part of AP2 - problem notification recipients.

Regards,

Bramha

[t_pawlak]

Then go to Settings → Integration → Problem notifications and check if you are listed as a recipient for that one. It might not be an issue with the alerting profile but rather a misconfigured problem notification.

[Bramham]

2 Problem notifications(P1 & P2) chosen correctly 2 alerting profiles only.

Im part of Problem notification (P2) where as a recipient.

[t_pawlak]

You can also double-check if the disk space problem is being detected as a global host problem (host level) instead of only within the MZ context. In such cases, the problem card can still be visible across multiple alerting profiles if no restrictive filters are applied.

Additionally, review:

If your alerting profile conditions (severity, duration, problem filters) are broad enough to include generic host problems, they might overlap.

If tags are automatically applied to these hosts that accidentally match AP2’s scope.

A practical test is to temporarily add a very restrictive filter (for example, a specific tag or entity) into AP2 and check if you still receive the notification. That way you can confirm if the overlap is coming from global/default routing or from tags.