locked
SLO Warning in wrong time RRS feed

  • Question

  • Hi!

    I have configured Calendar in Service Level Management for business days 8 AM to 5PM. All SLO are related to this calendar. Warning in SLO is always half time of target time. For both statuses warning and breach I have notifications. Time when incidents breaching is ok and in scope of calendar but warnings notifications comes at night or other non business time. How can I configure it correctly?

    Thanks

    Wednesday, August 7, 2013 8:58 AM

Answers

  • The Warning Time is time is breached BEFORE target time. For instance, you have:
    Target Time: 8 hours
    Warning time: 4 hours
    Calendar is  8 AM to 5PM

    For instance, the incident registered at 10:00AM. The target time will be (8:00AM + (10:00AM - 05:00PM)) = 09:00AM. In this case the Warning time will be 09:00AM - 4 hours = 05:00AM.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    Friday, August 9, 2013 1:09 PM

All replies

  • can you please past your slo configuration? especially  target time and warning time?

    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    Thursday, August 8, 2013 1:02 AM
  • maybe I am not following. In every my SLO is Warning time always half of Target time. For example Incidents with priority 1 has SLO with 8 hours to target and 4 hours for warning.
    Thursday, August 8, 2013 9:22 AM
  • The Warning Time is time is breached BEFORE target time. For instance, you have:
    Target Time: 8 hours
    Warning time: 4 hours
    Calendar is  8 AM to 5PM

    For instance, the incident registered at 10:00AM. The target time will be (8:00AM + (10:00AM - 05:00PM)) = 09:00AM. In this case the Warning time will be 09:00AM - 4 hours = 05:00AM.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    Friday, August 9, 2013 1:09 PM
  • Yes, this is completely correct. But my problem is then I sometimes receive warning out of scope business hours. My question is - How is that possible and how can I reconfigure it?

    Thanks

    Monday, August 26, 2013 11:21 AM
  • I am looking at this stuff right now. There is something very wrong. When using small periods like few hours, things work as expected, but when using larger periods (few days) calculations are wrong!

    Example:

    - a simple calendar with 5/8 work days (MON, TUE, WED, THU, FRI) each day from 08:00 - 16:00 (UTF+1); there are also few holidays, but none concerning current dates. In DB it looks like:

    [MT_System$Calendar$WorkDay]

    StartTime

    IsEnabled

    EndTime

    2014-10-27 07:00:00.000

    1

    2014-10-27 15:00:00.000

    NULL

    0

    NULL

    2014-10-27 07:00:00.000

    1

    2014-10-27 15:00:00.000

    NULL

    0

    NULL

    2014-10-27 07:00:00.000

    1

    2014-10-27 15:00:00.000

    2014-10-27 07:00:00.000

    1

    2014-10-27 15:00:00.000

    2015-01-22 07:00:00.000

    1

    2015-02-13 15:00:00.000

    (a bit strange, do note that dates are actually not used - they indicate on which date the time has changed)

    - SLO: Target: 120M, Warning: 105M

    [MT_System$SLA$Instance$TimeInformation]

    StartDate

    EndDate

    PausedDate

    TargetEndDate

    TargetWarningDate

    13.2.2015 7:01

    NULL

    NULL

    13.2.2015 9:01

    13.2.2015 7:16

    - SLO: Target: 24H, Warning 23H

    - New Incident (data from DB): 

    StartDate

    EndDate

    PausedDate

    TargetEndDate

    TargetWarningDate

    13.2.2015 7:14

    NULL

    NULL

    18.2.2015 7:14

    17.2.2015 8:14

    - Warning should be: 13.2.2015 8:14!

    - SLO: Target: 24H, Warning 1H

    StartDate

    EndDate

    PausedDate

    TargetEndDate

    TargetWarningDate

    13.2.2015 7:37

    NULL

    NULL

    18.2.2015 7:37

    18.2.2015 6:37

    - Warning should be: 17.2.2015 14:37! (we don't work at 07:00...)

    Using larger time spans produces larger discrepancies. (I also checked if this is affected by priority and it is not, just a precaution...)

    This is on SCSM 2012R2 UR5... So clearly there is something wrong. Seems like major bug to me. Please revise thoroughly and fix. 

    Best regards.

        Blaz

    Friday, February 13, 2015 7:57 AM
  • If you think this is a bug you should submit the bug via support call to Microsoft or via Connect website. I am not sure if someone from the Microsoft Product Group is tracking this forums for bug reporting.

    Andreas Baumgarten | H&D International Group

    Friday, February 13, 2015 10:08 AM
  • Blaz, please note that only target time calculated using business hours (this wrote in console, in SLO dialog). Warning threshold is just simple time interval.

    And it's hard to say if it wrong or not. For some customers it's OK and expected, because they just want to have notification and nothing more. For some customers this is wrong.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    Friday, February 13, 2015 10:49 AM
  • Anton, thanks for clarification - I admit I newer read that text. It says:

    "Service Level Criteria
    Specify the calendar and metric you want to use for this service level objective. In addition, specify the target and warning threshold times for the metric. Target is the time frame in which you expect the service level objective to be met. Note that target time is a function of business time."

    Going through my numbers I see that the forumula is:

        TargetWarningTime = (StartDate(businessTime) + Target(businessTime)) - Warning(time)

    This can be a bit confusing and in certain cases non-functional. E. g.

    Target: 8H, Warning: 4H, WD: 08:00 - 16:00

        StartDate: 1970-1-1 08:01

        Target Time: 1970-1-2 08:01

        TargetWarningTime: 1970-1-2 04:01

    Well, no need for such warning - when you come at work you are already to late. I agree that this works fine for 24/7 - but then, you don't have to define WH :)

    Best regards,

      Blaz


    Friday, February 13, 2015 1:02 PM