Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SLA #710

Open
wants to merge 14 commits into
base: main
Choose a base branch
from
Open

SLA #710

wants to merge 14 commits into from

Conversation

yhabteab
Copy link
Member

@yhabteab yhabteab commented Feb 3, 2023

Daily breakdown:
Bildschirm­foto 2023-02-13 um 09 36 30

Weekly breakdown:
Bildschirm­foto 2023-02-13 um 09 37 38

fixes #713

@cla-bot cla-bot bot added the cla/signed CLA is signed by all contributors of a PR label Feb 3, 2023
@yhabteab yhabteab changed the title WIP SLA WIP Feb 3, 2023
@yhabteab yhabteab changed the title SLA WIP WIP: SLA Feb 3, 2023
@yhabteab
Copy link
Member Author

yhabteab commented Feb 8, 2023

@yhabteab yhabteab changed the title WIP: SLA SLA Feb 9, 2023
@yhabteab
Copy link
Member Author

@yhabteab
Copy link
Member Author

yhabteab commented Feb 13, 2023

Bildschirm­foto 2023-02-13 um 11 21 58

Copy link

@julianbrost julianbrost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm focusing only on the algorithm itself as I'm not very familiar with PHP and IPL.

General remarks:

  • The query for the timeline itself is now split across two files (one with the column definitions and one with the filters). That would probably be better to understand if it was possible to keep this in one place and include comments.
  • If I understand correctly, in case of a breakdown report, this currently fetches the timeline for each sub-interval separately. Generally, since now instead of a single value, the entire SLA history is fetches, it would be possible to do all this in a single query and split the result into the sub-intervals in PHP (could be an optimization, someone else has to judge if this is worth putting effort into).

The test data looks sensible but I didn't compare every single detail with the current test data on the Go side. Are there any intentional changes, especially to accommodate the change in handling 99/pending?

Also to anyone else reviewing this: if there are any question regarding the algorithm, just ask me.

library/Icingadb/Model/HostSlaHistory.php Outdated Show resolved Hide resolved
library/Icingadb/Model/HostSlaHistory.php Outdated Show resolved Hide resolved
library/Icingadb/Model/HostSlaHistory.php Outdated Show resolved Hide resolved
$time = $this->time[$i];
$state = $this->state[$i];

if ($this->previousState[$i] === 99 || ($lastHardState === 99 && $event !== 'state_change')) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This condition is changed to compared to the current one: https://github.com/Icinga/icingadb/blob/4ed4db3ab642622bb917797a8207589ce5f89f07/schema/mysql/schema.sql#L139

I think this is the change that's actually supposed to address Icinga/icingadb#558. If we want to mix this in here, I'd try change the order of actions in the loop, the current condition was my suggestion for a quick test to see if this would bring an improvement. The general idea was to check if $lastHardState would be 99 at the end of the iteration. So it could make sense to just move this branch of the conditional after the update to $lastHardState (the update of $lastEventTime would have to be moved behind that then).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it could make sense to just move this branch of the conditional after the update to $lastHardState (the update of $lastEventTime would have to be moved behind that then).

$lastHardState is only updated when the current row event type is a state_change. How would this make any difference compared the current implementation?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should do exactly the same. My hope is that the change makes the code easier to understand.

@yhabteab
Copy link
Member Author

yhabteab commented Feb 22, 2023

Are there any intentional changes, especially to accommodate the change in handling 99/pending?

Yes! ffee32b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla/signed CLA is signed by all contributors of a PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Total SLA different depending on breakdown setting
2 participants