Hi,
this variant worked perfectly with checkmk 1.
A definition on the “client side” of the validity intervall would be a possibility but would require to change the checks, have different checks for cached/non cached and have to configure somewhere the validility.
The biggest drawback lies in the fact that the client has no knowledge about the check period. It just can assume that the default of 1 minute (or another customer defined one) is used.
The checkmk is the only one who knows the check period and should take care of that. If the cachetime is less than the check period (and the last check attempt was successfull) this should in my eyes definitly not considered stale (as there was no younger attempt to check that).
For a long term solution I agree to provide a possibility to just asynchronously execute checks (perhaps all local checks?) Actually a cache time less than the check interval is the only possibility to achieve that.
Generally a threshold of exactly 100% is perhaps too strict as this could be affected by minor timing issues. That’s the reason why I suggested max(cache_time, check interval) plus 10% as threshold
btw: we have also the default configuration “consider as stale if no data in the last 1,5 check attempts” which is not taken place here (this should be enough for 45 seconds cache and check all 60 seconds)
Regards Michael