Skip to content
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

Add support to track filtered/unfiltered notifications and do not re-notify if filtered states don't change #4503

Closed
icinga-migration opened this issue Aug 17, 2016 · 10 comments · Fixed by #9893
Assignees
Labels
area/configuration DSL, parser, compiler, error handling area/notifications Notification events enhancement New feature or request needs-sponsoring Not low on priority but also not scheduled soon without any incentive
Milestone

Comments

@icinga-migration
Copy link

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

Created by darmagan on 2016-08-17 10:00:53 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-08-17 10:00:53 +00:00 (in Redmine)

Icinga Version: 2.4.10
Backport?: Not yet backported
Include in Changelog: 1

Hi,

if Services are changing states all of the changes are notified. It's not possible to disable that behavior. Flapping detection will not apply cause it occurs temporally. In this example, if the Unknown state notifications are disabled/filtered, it looks like as if Icinga double notifies. And the notification interval is not helping, cause the event is triggered live.

Regards

@icinga-migration icinga-migration added bug Something isn't working area/configuration DSL, parser, compiler, error handling labels Jan 17, 2017
@pefmeister
Copy link

This issue bothers me, too. This is also a real big bummer for our operations team. Critical services that have been acknowledged and experience such an Critical-Unknown-Critical transition lose their acknowledgement and (usually) their comment. This happens quite often as we also hit the problem that a config change increases the load on our satellites and create timeouts for the service checks.

@dnsmichi
Copy link
Contributor

Why don't you use sticky acknowledgements then?

https://docs.icinga.com/icinga2/latest/doc/module/icinga2/toc#!/icinga2/latest/doc/module/icinga2/chapter/icinga2-api#icinga2-api-actions-acknowledge-problem

The original issue is about the fact that notification filters hide the state change transition and will notify 2x times critical. Which looks suspicious to the user, but works as designed. There are no acknowledgements involved.

@pefmeister
Copy link

I'll try that tomorrow, but since it is the default, I should have always used it :) I'll report back.

@pefmeister
Copy link

Tried it a couple of times and you're absolutely right, using the sticky flag works as designed. Is there any way to set this as a default in IW2?

@pefmeister
Copy link

OK, found it. Putting the following in /etc/icingaweb2/modules/monitoring/config.ini is what I need:

[settings]
acknowledge_sticky = 1

@dnsmichi
Copy link
Contributor

Actually this requires changes in the state and notification logic to suppress notifications if some states in between have been filtered away. So to speak, Icinga 2 would need to keep track of filtered and unfiltered notifications.

I'm changing this into a feature request requiring a sponsor. Or you'll attach it to something like NoMa with advanced notification rules and history tracking.

@dnsmichi dnsmichi added enhancement New feature or request wishlist and removed bug Something isn't working labels Sep 26, 2017
@dnsmichi dnsmichi changed the title [dev.icinga.com #12463] Unable to disable notifications by State-changes from Critical-Unknown-Critical Add support to track filtered/unfiltered notifications and do not re-notify if filtered states don't change Sep 26, 2017
@dnsmichi dnsmichi added the area/notifications Notification events label Sep 26, 2017
@dnsmichi dnsmichi removed the wishlist label May 9, 2019
@Al2Klimov Al2Klimov added the needs-sponsoring Not low on priority but also not scheduled soon without any incentive label Mar 12, 2020
@Al2Klimov
Copy link
Member

@N-o-X Shall we just require not to filter out e.g. OK if you want to be notified for WARN->OK in addition to OK->WARN (wontfix)? Or shall we notify for both OK->WARN and WARN->OK if one allows notifications for WARN?

@Al2Klimov Al2Klimov added the needs feedback We'll only proceed once we hear from you again label Mar 12, 2020
@Al2Klimov
Copy link
Member

PING @N-o-X

@N-o-X N-o-X removed their assignment Dec 6, 2021
@Al2Klimov
Copy link
Member

It seems I have to re-address my question...

@julianbrost
Copy link
Contributor

I'm not sure if I fully understand the problem and your suggestion, but isn't this that in a situation like OK -> WARNING -> UNKNOWN -> WARNING and you filter the notification states for WARNING (or OK + WARNING), you only want to receive one notification?

Shall we just require not to filter out e.g. OK if you want to be notified for WARN->OK in addition to OK->WARN (wontfix)? Or shall we notify for both OK->WARN and WARN->OK if one allows notifications for WARN?

I don't see how this would be possible with either of these suggestions.

@julianbrost julianbrost removed their assignment Oct 5, 2022
@Al2Klimov Al2Klimov self-assigned this Jul 4, 2023
@Al2Klimov Al2Klimov added the stalled Blocked or not relevant yet label Jul 4, 2023
@Al2Klimov Al2Klimov removed needs feedback We'll only proceed once we hear from you again stalled Blocked or not relevant yet labels Nov 7, 2023
@icinga-probot icinga-probot bot added this to the 2.15.0 milestone Dec 13, 2023
@Al2Klimov Al2Klimov modified the milestones: 2.15.0, 2.14.1 Dec 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/configuration DSL, parser, compiler, error handling area/notifications Notification events enhancement New feature or request needs-sponsoring Not low on priority but also not scheduled soon without any incentive
Projects
None yet
6 participants