Skip to content
This repository has been archived by the owner. It is now read-only.

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

Closed
icinga-migration opened this issue Jul 30, 2012 · 4 comments

Comments

Projects
None yet
1 participant
@icinga-migration
Copy link
Member

commented Jul 30, 2012

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:

@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Jul 31, 2012

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

This comment has been minimized.

Copy link
Member Author

commented Jul 19, 2014

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

  • Status changed from New to Rejected
@icinga-migration

This comment has been minimized.

Copy link
Member Author

commented Oct 27, 2014

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

This comment has been minimized.

Copy link
Member Author

commented Oct 27, 2014

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.