You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It may be interesting if we could have Previous State and Previous State Duration in logs.
It can be useful to work out Availabilty ... in a very simple manner.
Here is a try of an algorithm :
If current_log.type ="Service Alert" or "Host Alert"
and current_log.state != previous_log.state
then
Add previous state and duration in current log
I think that : before writing a new log, shinken has all needed informations to find last state and last state duration so that it should be easy to add it when writing the log than calculating it afterward.
What do you think ?
The text was updated successfully, but these errors were encountered:
I think we should not use log for what they are not done for, and such use case it one of them. Reporting should be with a real module that will compute it in a good way, and not just the simple availability ON/OFF. So even if it solve the availability problem, I do not solve the reporting one, and this one is the real "root problem" I think :)
Hi,
It may be interesting if we could have Previous State and Previous State Duration in logs.
It can be useful to work out Availabilty ... in a very simple manner.
Here is a try of an algorithm :
If current_log.type ="Service Alert" or "Host Alert"
and current_log.state != previous_log.state
then
Add previous state and duration in current log
I think that : before writing a new log, shinken has all needed informations to find last state and last state duration so that it should be easy to add it when writing the log than calculating it afterward.
What do you think ?
The text was updated successfully, but these errors were encountered: