Timeperiods and 'check time' oddity in State file

Icinga 2
1

I am completing the base setup of an Icinga 2.x (Core) migration, and noticed something odd when reviewing it on the UI. Note we’re staying on Classic temporarily; the migration is being staged, and the Web UI will be done alongside an OS refresh (which is already in planning for other reasons).

Anyway, wondering how checks report their detail outside of timeperiods. We have a number of ‘check once’ log checks for system sanity, and I am seeing the ‘last check time’ and ‘next check time’ advance 24x7. However, the checks themselves do seem to be running at the intended times, and I have confirmed the timeperiods are being assigned properly.

If this is just something to do with how you’re writing to the old State file, I’m fine with that; just need to be sure in case it comes up after the move. Again, I do have plans to get the UI migrated to IDO/Web (as well as a proper Clustered monitoring pair, and all the fun stuff that a modern Performance Grapher can get us), but it requires some things in place that I don’t have an OK to provision yet. I am also aware of the 2.11 changes, which is why I’m confirming this behavior before finishing up the Core move (later this summer).

Things are otherwise working out well, now that I’ve figured out how to leverage the new config; the Apply rules are really great in simplifying and centralizing our setup in the long-term, though I keep finding oddball exclusions that require more and more ‘ignore’ logic. I even have a migration script that configures a basic set of host group files from a Classic Livestatus dump (and some additional local data queries). I’m just doing final master config for stuff like notifications now, which I could not do on a test server.

Core r2.10.2-1 (from pkgs),
Classic 1.14.0 (compiled locally in Standalone mode)

Thanks,
–T_S_Kimball

2

Honestly I don’t remember how the Classic UI deals with that. After we decided to mark 1.x as EOL, I have started to empty my brain and focus on our new ecosystem.

The core scheduler calculates the next check time in advance - based on the *_interval settings. If there is an active time period segment at the execution point in time, the check gets executed. If not, it is skipped and re-scheduled. There is no “forecast” with timeperiods and other possible filters to disable the checks, unlike in 1.x where this led to funny problems with checks resulting in 2 weeks time.

Cheers,
Michael

3

OK, so not only is that an expected condition, but it will also fix the other oddities we keep having in Classic Core after DST changes and holidays - for which I’ve now had to schedule a wipe of the State file every few months.

Perfect, thanks.