[dev.icinga.com #2919] allow disabling notifications with expire time

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/2919

Created by mfriedrich on 2012-07-30 19:57:32 +00:00

Assignee: (none)
Status: Rejected (closed on 2014-07-19 12:52:28 +00:00)
Target Version: (none)
Last Update: 2014-10-27 15:37:59 +00:00 (in Redmine)

---

same as acks with expire time, but just for notifications. though i do believe that with modified_attributes within #2473 and #2474 those changes will be reflected a bit better, so i am not yet convinced that this should happen on a host or service level, but rather let it happen only globally as i misinterpreted in #905

---

Relations:

• relates #905
• relates #2473
• relates #2474

[icinga-migration]

Updated by mfriedrich on 2012-07-31 08:01:36 +00:00

from the original issue

It would be a great feature if it would be possible to disable notifications for hosts, services, all services of a host and hostgroups with an end time - e.g.:
disable notification for this host until 

And to add an external command for this - e.g.:
DISABLE_HOST_NOTIFICATION_UNTIL
or
DISABLE_SERVICE_NOTIFICATION_TEMPORARY

This feature would prevent disasters which could happen if an admin forget to re-enable notifications.

[icinga-migration]

Updated by mfriedrich on 2014-07-19 12:52:28 +00:00

• Status changed from New to Rejected

[icinga-migration]

Updated by pvdputte on 2014-10-27 15:11:48 +00:00

As rbrinkmo mentioned in the original #905 issue, a scheduled downtime is interpreted like a 'planned maintenance' by SLA reporting, which is exactly what we want (e.g. downtime during this timeframe does not count for the maximum allowed downtime for the month).

We use regular 'ack' while investigating an incident, hence this downtime does get counted for the SLA report. Again exactly what we want.

However, if the host/service is continually spamming our sysadmins with 'OK' and 'Critical' messages because it's flapping, they have no other option but to disable notifications manually (and maybe forget to re-enable it), or to add a scheduled downtime (messing up SLA reporting => not an option really). 'flap detection' is something we wish to steer clear of because we might miss actual incidents because Icinga stops sending out alerts and people might not have woken up in time.

The only option we have is to bolt on some in-house tool to disable and re-enable notifications on a service or host for us. Or is there an clean alternative?

[icinga-migration]

Updated by pvdputte on 2014-10-27 15:37:59 +00:00

Come to think of it, if there would be an option to make an ACK with expire time not be automatically removed if the host/service recovers, that would essentially achieve the same thing.