Is this really “hardcoded” ?
Version: 2.4.0p19, Spooler running, Deferred files: 4, Oldest: 1 minute 54 seconds (warn/crit at 5 seconds/10 minutes 0 seconds)
Hi @Cleclercq
Yes, unfortunately the warn/crit thresholds for the “OMD Notification Spooler” check (5 seconds WARN / 10 minutes CRIT for the oldest deferred file) appear to be hardcoded in the check plugin itself. There is no dedicated rule set in Setup that allows you to adjust these values.
This makes the 5-second WARN threshold very aggressive in practice — any temporary delay in spooler processing will immediately trigger a WARNING, even if the situation resolves itself within seconds.
Workarounds:
-
Increase check attempts — Go to
Setup → Services → Service monitoring rules → Maximum number of check attempts for serviceand set it to e.g. 3 for the Notification Spooler service. This way a single WARN won’t trigger notifications immediately — it needs to stay in WARN for 3 consecutive checks (~3 minutes). -
Add a scheduled downtime or flap detection — Not ideal, but as a short-term measure it reduces noise.
-
File a feature request with Checkmk — The 5-second threshold is arguably too tight as a hardcoded default, especially for distributed setups or sites with higher notification load. A configurable rule set for this check would be the proper fix. Worth raising a new feature at https://ideas.checkmk.com/ .
If anyone has found a way to override these thresholds directly, I’d be curious to hear it too!
kR Bernd
1 Like
I don’t think this is the way. The “issues” section in the github repo is switched off.
Better go through https://ideas.checkmk.com/ as this is a new feature.
2 Likes