-
Notifications
You must be signed in to change notification settings - Fork 574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Notification behaviour after Downtime ends #5919
Comments
Contacts/Users don't have a notification interval, that's to be defined inside the notification object. Can you share a sample configuration in order to reproduce the issue? Cheers, |
Ok, here we go: I applied the following changes to a vanilla icinga 2.8 installation: conf.d/services.conf
conf.d/users.conf
conf.d/notifications.conf
conf.d/templates.conf
Here's how to reproduce the problem:
Result:
Conclusion: |
Ok, understood. The main request is to ignore the notification interval if a downtime has ended. Right now the calculated next notification time is
Changing this could break existing setups. I'd like to hear from others what they think. Or see a possible patch to adjust the behaviour and fully test it. |
Just a quick addendum: I watched the same behaviour when an outage happens out of a notification period: when the notification period starts, UserA with interval=0 gets a notification immediatly, and the user with interval=60m gets the notification later, apparently with the same formula that dnsmichi has shown before. I cannot imagine why someone doesn't want to be informed of an outage immediatly when a downtime ends or a notification period starts, so count my vote for a change of that behaviour. |
Sure, I hear you. I'm not sure how this can be implemented yet though. |
I noticed in my setup the same behavior and I agree with @edpstiffel that a notification should be sent right after the downtime. |
BUMP Our intended setup relies heavily on what @edpstiffel is describing being the case. Consider the following scenario: |
The same issue or wish for feature request here; every night our print servers were rebooted, at this time they are in downtime. When a service ended at the downtime, then, in this case reboot and the service doesn't came up, we haven't any notification... Yes.. in the downtime it reached critical state, yes.. the state doesn't changed, when the downtime ends... |
+1 Could this be solved by adding some sort of queue where all notifications that occured during a downtime (or while outside of an notification timeperiod) are collected? After the downtime ends, the get deduplicated and checked if they still apply. If yes, then the notifications get sent immediately. |
…re re-sending a suppressed notification refs #5919
…re re-sending a suppressed notification refs #5919
…re re-sending a suppressed notification refs #5919
…re re-sending a suppressed notification refs #5919
This is a sponsored feature request, thanks for granting us the time to implement it. ref/IP/14729 |
…re re-sending a suppressed notification refs #5919
…re re-sending a suppressed notification refs #5919
Expected Behavior
I schedule a fixed downtime for a service.
The service goes CRITICAL within the downtime.
The service is still CRITICAL when the downtime ends.
I expect to be notified right when the downtime ends.
Current Behavior
When the downtime ends, the notification for one contact fires right away, but the notification for a second contact is delayed.
Possible Solution
Experiments show that the interval setting for a notification is the key: The one contact that gets the notification right after the downtime ends has notification interval of 0 (zero).
The other contact has an interval setting of 600 seconds (10m), and he gets the notification 10 minutes after the hard state change happened (during the downtime).
Steps to Reproduce (for bugs)
Please take a look at the attached screenshot which shows the history of such a behaviour:
Context
IMHO, the notification should happen immediately after the downtime has ended, no matter which interval was set.
I guess, I watched the same behaviour when using timeperiods which are not 24x7, i.e. when using notification period 9to17 and a outtage happens before that time. The contact attached to notification object with interval 0 is notified right when the notification period starts, the contact attached to a notification object with an interval, is delayed until the next regular interval after the outtage.
The background: Our contact with interval 0 is a ticket system which should only receive one notification, while our staff should be re-informed every hour.
Your Environment
The text was updated successfully, but these errors were encountered: