Suppressing all alerts from a host in Maintenance Windows

[Mark_Skeats]

Would like to create maintenance windows via the API for bulk patching and other situations where application/service may or may not be gracefully shutdown.

My understanding is that the MW exclusion must be applied to the same entity type as the alert setting to be effective, for example to suppress alerting attached to a process group I will need to include in the MW definition that process group id.

This can be achieved via the API but my concern is the size and complexity of the MW definition when used with many hosts.

I would like to avoid tagging due to the number already in our system.

My question is - to suppress ALL alerting from a host do I need to include all entities associated with the host or is there a more efficient way to do this?

[Babar_Qayyum · Accepted solution]

Hello @Mark_Skeats 

My personal experience taught me that if I put only a host for the maintenance windows (especially the full-stack one), the problem will still be generated for the processes availability, network retransmissions, etc., etc.

 Therefore, whenever I plan to do maintenance windows then, I make sure to cover all the entities in one tagging rule e.g. host, processes, services, custom devices, synthetic, etc to make sure the problem is not taking a sneaky way to appear.

Regards,

Babar

[Mark_Skeats]

Thank you for the reply, very helpful

[fstekelenburg]

Agree with Babar, tagging is the most efficient and dynamic way. Rather than adding all required filters in a MW definition. Unfortunately, like with tagging and management zones, you can't select options like 'apply to (processes) running on matching (hosts)'

[jtclark]

In my opinion, the Accepted solution is not a solution at all as it requires a specific level of per-entity administration or at least tagging rules be set up. Most modern systems out there (even in other locations within Dynatrace) let you toggle a suppression of all dependent entities with the parent entity and will automatically include alerts for those children in the MW if toggled true. I have brought this up with my account team and they seem to understand the logic of my point of view.

Without administering the tagging in a very specific way, the only other option is to build maintenances via API using some interface to select a parent, then fetching its "toRelationsips" attribute and parsing those for distinctly dependent sub-entities (disks, services running on the host, etc) while also considering the entities that are linked, but not distinct (process groups, etc). This is development overhead on the customer that doesn't need to be there if this were solved on the MW UI interface.