downtime relevant or not for SLA

[btrnka63]

Hello,

I'd like to ask to add one more attribute/field for the Downtime and Acknowledge form which would say if commented unavailability of the service is or is not relevant for the SLA.

Intention is to have an option to mark certain downtime/unavailability of the monitored service whenever it is planned maintenance or unexpected interruption of the service. This would be beneficial e.g. for the SLA reports for the calculation of the agreed availability (SLA).

Expected would be to have this into stored in the icinga DB for further processing; in addition to existing attributes like author, comment, start/end time, etc.

Thanks.

[oxzi]

The current SLA logic honors downtimes and ignores acknowledgements. In other words, if your host was unreachable but within a downtime, you can still get a SLA value of five nines. However, if your host was down and you set an acknowledgment, the SLA value will reflect the unavailability.

So, at the moment, there is a difference between a downtime and an acknowledgment for the SLA value.

Is this already helpful for you? Having SLA-altering and SLA-ignoring downtimes and acknowledgments sounds confusing for me, both for implementation and for end users.

Implementation details are available in the SQL function. However, I am not sure if this is documented prominently. Otherwise, this is definitely a task.

[btrnka63]

Hi, thanks for the quick response.

Yes, we already considered the differences in the meaning of Downtime and Acknowledgement objects, but it does not work for us.
Acknowledgment has certain disadvantages like: it is removed once the state changes to OK - during the unstable situation (like overloaded server, unstable network connection) this is not helpful and ACK needs to be re-entered.
Also, ACK cannot be cascaded; DT set for Host object can be cascaded to services (latter, reporting SLA for the service we would get this info). Same for parent-host/child-host defined dependency and DT for the parent host being cascaded to the children hosts.

Due mentioned the end-users use to set the Downtimes for planned maintenances as well as during the service interruptions (incidents) when the ACK could be defined/used.

Latter, for the SLA reports, the time for planned maintenances is deducted from the total month time. Only the time when the service was unavailable (and not always perfectly fitting the times of the State changes) is considered as SLA relevant. For the service which is going up and down during the issues, the "UP" times cannot be reported as OK within the SLA reports.

Additionally, even using the ACK as intended (to be set during the issues) does not mean it's actually SLA relevant unavailability of the service. Target service is monitored from the internal monitoring servers, once the connection is lost, it does not mean the target service is down. It's temporary issue on internal monitoring site and it should not be reported as SLA relevant.

I know the Downtime/Acknowledge features are intended to suppress the Notifications (not to document the unavailability for SLA reports), but still these are valuable information for further processing of monitored data.