The query would previously return all lines from report_data regardless
of their event_type. The theory here is that when comparing states
between Livestatus and the SQL data we have, there are certain data
points that we don't want as they may cause false positives. This commit
excludes rows that are of the following event types:
1000 (FLAPPING STARTED)
1001 (FLAPPING STOPPED)
1103 (DOWNTIME START)
1104 (DOWNTIME STOP)
100 (PROCESS START)
103 (PROCESS SHUTDOWN)
Hopefully dev will agree that these types of events are not useful when
comparing the state of an object between Livestatus and our report data,
as these are not actually states. If these points are kept, you may
theoretically compare a service/host critical from Livestatus with a
"FLAPPING STARTED" point (state = 0) from our report data only because
it's the newest for an object, causing a false positive. This hopefully
fixes that since these dud rows should no longer be a part of the result
set.
lgrn
commented
4 years ago
The query would previously return all lines from report_data regardless of their event_type. The theory here is that when comparing states between Livestatus and the SQL data we have, there are certain data points that we don't want as they may cause false positives. This commit excludes rows that are of the following event types:
Hopefully dev will agree that these types of events are not useful when comparing the state of an object between Livestatus and our report data, as these are not actually states. If these points are kept, you may theoretically compare a service/host critical from Livestatus with a "FLAPPING STARTED" point (state = 0) from our report data only because it's the newest for an object, causing a false positive. This hopefully fixes that since these dud rows should no longer be a part of the result set.