Fix sla report inconsistencies #560
Conversation
yhabteab
force-pushed
the
fix-sla-reports
branch
7 times, most recently
from
e3f9693 to
b997831
Compare
yhabteab
force-pushed
the
fix-sla-reports
branch
4 times, most recently
from
9ca60c8 to
c10871d
Compare
yhabteab
force-pushed
the
fix-sla-reports
branch
from
c10871d to
dfaa535
Compare
There was a problem hiding this comment.
Can you please share the data from the SLA history tables you were using (so probably one of the hosts you had for testing in #558).
| AND s.hard_state IS NOT NULL | ||
| AND s.previous_hard_state IS NOT NULL |
There was a problem hiding this comment.
Don't these columns already have a NOT NULL constraint?
| -- row count "1" because of the faked ending result used for the | ||
| -- cursor loop, whose result set is never used. | ||
| IF rowCounts > 1 THEN |
There was a problem hiding this comment.
This would also count downtime rows returned by that query which I doubt you want. But also if this would just count the state rows, this makes the assumption that if there's no event in the interval, there's no valid result to report. Problem with this is that if nothing happens on a checkable, there is no history. So for something that's 100% up, had no downtimes, this would now no longer return a value.
|
Superseded by Icinga/icingadb-web#710 |
This PR only fixes that the host/service reports with empty history event entries are returning
nullrather than100. However, the total report results for the same timeframe are still different depending on whether you select host reports for a week at a time or split them into a 7-day period (in reporting module is called this abreakdown), i.e. instead of for a week at a time, they are only generated for one day at a time and that 7 times.fixes #558
refs Icinga/icingadb-web#713