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 #2136] freshness checks are generating stale alerts, even if result was received in time #802
This issue has been migrated from Redmine: https://dev.icinga.com/issues/2136
Created by mfriedrich on 2011-12-01 19:12:21 +00:00
the recent patch #2027 on the freshness checking on startup is heavily affecting the normal scheduled run under weird circumstances.
as remarked in #2027 description, it could most likely fail.
a tested reverted fix in OMD 0.52 nightly is working, so this actually needs to be pushed an released into 1.6.1 then.
2011-12-01 20:02:26 +00:00 by mfriedrich 2208b71
Updated by mfriedrich on 2011-12-01 20:06:04 +00:00
seeking out into the snippet, it might be that the 60 seconds delay on the alert has something to do with the hardcoded 60 seconds in the addition (missing brackets, different and operator?).
requires further investigation though. the patch for removal will be in r1.6
Updated by mfriedrich on 2011-12-01 22:16:52 +00:00
Updated by mfriedrich on 2011-12-02 13:01:59 +00:00
Updated by mfriedrich on 2011-12-02 13:44:14 +00:00
further debug logs (cleaned private stuff)
from the new calculation algorithm
if (1322812958 < 1322812951 + 60 && 1322812958 - x < 300 * 0.618)
if (1322813*258* < 1322813*318*)
analze the above
if (1322812958 < 1322813011 && 1322812958-x < 185,4)
the overall conclusion is that the freshness threshold with the retention.dat creation date calculation between the event_time and a 61,8 percent freshness threshold will cause an error if
event_start is within
actually the problem is not the last_program_stop, but the condition on the program_start and the 60 seconds. this value is just an assumption and therefore not correct for further usage.