Forum Discussion

CBU_BA_DUDE's avatar
7 years ago

New Columns in SLA Report

The SLA report does not have an option to include information about SDT if the event is in the past.  Since reports are often developed to look at sla information post-event it's imperative that report columns be added that reflect historical SDT info as well.

I recommend not just including the sdted field to indicate whether or not the alert began in a SDT window, but to instead add a new field/column for % in SDT or SDT Duration that provides an indicator as to how much of that alert's period was happening in a SDT window.

Example:

Planned maintenance window is 2-4.  IT change initiated at 2:30 and services are brought down.  Alert generates and flags true for insdt and sdted (i think).

If the change goes bad and services are still down at 4 AM the insdt flag is set to false (i think).  The change implementer restores service at 4:30 and the alert clears.  To report on downtime for that alert correctly we would need to know what portion of that downtime occurred within or outside of SDT.

If we assumed that since the alert was generated in an SDT window (sdted=true) the entire duration was planned then we are incorrect an SLA report on downtime for that instance check would be false.

  • Agree with this and would like to see it taken further. 

    We do a lot of Alert Analysis on a bi-weekly/monthly basis and any data we pull will only show alerts that are 'actually' in SDT at the time of data being pulled, there is no additional marker to state/indicate that an alert was generated whilst the device/datapoint was in SDT - this means that we invariably investigate & misreport on alert numbers as there is no way to differentiate. 

    This aspect needs addressing urgently so that those carrying out deep SLA & Alert Analysis can obtain accurate data from which to base reports on.

    Thanks