julianbrost
commented
1 year ago states and times only affects state notifications at the moment.
I do however wish to receive a
DowntimeStartnotification without any delay if aProblemnotification has been sent for the service before, since it indicates that someone else is working on the problem already and is therefore comparable to aRecoverynotification.
This sounds more like a use case for acknowledgements to me, not for downtimes.
I also wish to receive a
DowntimeEndorDowntimeRemovednotification when the service is notOKwhile the Downtime is removed and continues to be notOKfor the duration oftimes.begin(or maybe another optionally configurable delay) since it indicates that the person who created the Downtime does not seem to still work on the problem (or they should have extended the Downtime).
How would this extra delay differ from just making the downtime longer?
davidwinterstein
Al2Klimov
Describe the bug
Downtimes
Downtime notifications don't seem to respect either of the notification object's
statesortimesconfiguration.A notification object that has
states = [ Critical ]types = [ DowntimeStart, DowntimeEnd, DowntimeRemoved ]times.begin = 30mwill immediately trigger a notification when a Downtime starts, ends or is removed and the service state is
OK, regardless of when the Downtime is created or ends.Flapping
Flapping notifications don't seem to respect the notification object's
timesconfiguration.A notification object that has
types = [ FlappingStart, FlappingEnd ]times.begin = 30mwill immediately trigger a notification when the service is considered flapping.
To Reproduce
enable_flapping = true.OKstate (i.e. via IcingaWeb2).DowntimeStart.DowntimeEnd.OKandWarningstates until it is considered flapping.FlappingStart.Expected behavior
A notification should only be sent for Downtime events if the service state matches the notification object's
statesconfiguration.While the service is
OK, I do not wish to receive a notification if a Downtime is started or ends for the service - the purpose of creating a Downtime on the fly is to not receive a (problem) notification, i.e. during a planned reboot.I do however wish to receive a
DowntimeStartnotification without any delay if aProblemnotification has been sent for the service before, since it indicates that someone else is working on the problem already and is therefore comparable to anAcknowledgednotification.I also wish to receive a
DowntimeEndorDowntimeRemovednotification when the service is notOKwhile the Downtime is removed ~and continues to be notOKfor the duration oftimes.begin(or maybe another optionally configurable delay)~ since it indicates that the person who created the Downtime does not seem to still work on the problem (or they should have extended the Downtime).A notification should not immediately be sent for Flapping events but after a configurable duration.
I do not wish to receive a notification as soon as a service is considered flapping but I wish to receive one once it has been flapping for the percentage configured with
flapping_threshold_low/flapping_threshold_highover the duration oftimes.begin(or maybe another optionally configurable delay).I.e. I do not wish to trigger a phone call in the middle of the night because a http check is flapping for 5 minutes, but I do wish to trigger one if it is flapping for more than half an hour.
Maybe it would be enough to make the amount of events considered for flapping detection configurable, although the events are rather random and completely depend on the check interval, or rather use a combination of a duration and number of events that can be set per service if a notification delay is not desired.
Your Environment
Include as many relevant details about the environment you experienced the problem in
icinga2 --version):icinga2 feature list):icinga2 daemon -C):