Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #7355] Exclude option for TimePeriod definitions #2040
This issue has been migrated from Redmine: https://dev.icinga.com/issues/7355
Created by KeX on 2014-10-08 13:14:35 +00:00
On the icinga-users mailnig list I've seen a discussion about excludes in timeperiodes are not possible in icinga2? We've used this feature for a couple of yours now in icinga1 without a problem. It would be great if this feature is available for icinga2 too.
This is the configuration for icinga1:
And here the documentation:
It would be great if this feature finds its way back into icinga2.
2016-05-21 17:02:42 +00:00 by Reamer 699644b
2016-05-21 18:33:09 +00:00 by Reamer 54e1c8a
Updated by tgelf on 2015-04-22 08:21:43 +00:00
I'd also love to see this implemented. "Notify 9to5 but not on holidays" is a very basic feature. It's not needed when playing around or when "just sending mails", but most enterprises with an (even small-sized) IT department have to make sure to not bother their employees on holidays. At least unless they agreed on doing so.
In case the "exclude" logic as in Icinga 1.x is too complex to get it working smoothless together with our generic "import" implementation I could also immagine a simpler variant like follows:
Given this, one could create a config as follows:
Of course I could also live with a legacy-like exclude syntax .Implementing the above could be a quick win satisfying most needs while avoiding needless complexity.
Updated by gbeutner on 2015-08-27 14:36:41 +00:00
Implementing this with 'import' would probably be the easiest way. However there's an obvious drawback:
Now, while it's immediately obvious to me why the excludes for saturday and sunday aren't working this might be difficult to grasp for ordinary users.
I suspect this feature would be more powerful if we implement it like in Icinga 1.x:
Also, this way users wouldn't have to build "negative" time periods (e.g. "not bavarian holidays").
Updated by KeX on 2015-08-28 07:37:13 +00:00
The 2nd example you gave, like in Icinga 1.x, would be exactly what I'm looking for.
Would be a great enhancement for the notification system!
Updated by drbayer on 2016-02-05 17:55:15 +00:00
I'm trying to migrate from Nagios to Icinga2 and having some way to exclude ranges would be really helpful. As it is today, building a "business hours excluding holidays" (for example) is incredibly tedious.
Updated by Reamer on 2016-02-28 22:58:57 +00:00
i try to implement this feature. #71
Hope the code quality is good enough.
One Question. What's the different between this two locks "ObjectLock olock(timeranges)" and "ObjectLock dlock(segments)"?
Local tests are successfully.
Updated by mfriedrich on 2016-03-11 20:55:40 +00:00
I did not test it yet, but there's three things to consider with checking the timeperiod ranges on-demand at runtime (IsInside())
Updated by Reamer on 2016-03-25 12:37:45 +00:00
thanks for feedback @dnsmichi
Next try with an other idea:
Updated by KeX on 2016-04-20 07:23:56 +00:00
I've testet your patch with Version 2.4.4. It works like expected. My timeperiodes.conf looks like this:
And tested via a passive check.
Can't say something about the code quality, but the feature does what we are looking for! I hope this patch finds it's way into the stable release.
Thanks for that!
Updated by mfriedrich on 2016-05-06 07:46:20 +00:00
I'll have a look into the pending review. If nothing goes wrong, 2.5.0 is a good candidate.
Updated by mfriedrich on 2016-05-21 18:34:22 +00:00
Test-Config (adjust this for a time window for the excluded timeperiod where no checks will happen).
If I remove "prefer_includes" checks are executed again, since "7355-anytime" wins against the excluded timeperiod.
To be honest I thought of just adding excludes and not any kind of includes, as you already have the possibility to import other timeperiod objects. Although it is cumbersome to override and modify existing timeperiod attributes from a template. Especially given its old legacy syntax.
So from an end user perspective, it totally makes sense to support both, includes and excludes. Obviously not that many users will go for includes, but rather exclude their holidays (and only update that timeperiod object then).
Added some new lines, changes the variable names to capitalised ones. The underscore in variables is old and will be gone once in a while.
I've also modified the debug log entry for the checker component to highlight which time period prevents check execution. Same goes for notifications (and users) log entries.
Added an example using holidays and weekend excludes as sub chapter for the time periods. That way the users will see how time period exclusions work in a reasonable example. It also illustrates the different ways of specifying the ranges which was missing in there.
Those calls from inside the CheckerComponent as well as API work very well since the segments are already updated.
External interfaces such as DB IDO will only dump a very "static" time period time range.
meaning to say, all time ranges parsed from the configuration will be put into the database. Nothing you possibly could rely onto Especially not in Icinga 1.x where the excludes where implemented as well, but not exported into such interfaces.
It may of course be relevant for SLA reports to somehow export the config options (although this would require additional DB IDO tables, as timeperiods would have an 1..n relationship to includes/excludes being an array.
I've tested this now for a couple of hours and reviewed it (doing that on a Saturday on vacation, no time otherwise). I don't have any better names nor a suggestion for prefer_includes.
I like the patch, and included my modifications, I've merged it to master. Thanks a lot :)