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)