Service Level Objective - Fulfillment Criteria

{"URL":["/*.*/awa/pm_fulfillments"],"heroDescriptionIdentifier":"ice_SLO_FC_intro","customCards":[{"id":"ice_SLO_FC_Defining","title":"Defining the Fulfillment Criteria Page","type":"customize","languages":["en-us"]},{"id":"ice_SLO_Examples","title":"Examples","type":"customize","url":"https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU*.*/Automic%20Automation%20Guides/Content/AWA/Objects/obj_SLO_SLO.htm","languages":["en-us"]},{"id":"ice_working_with_objects","title":"Working with Objects","type":"customize","url":"https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/*.*/Automic%20Automation%20Guides/Content/AWA/Objects/obj_WorkingWithOverview.htm","languages":["en-us"]}]}

On this page you define the criteria that the services (executable objects) defined in the SLO object must meet according to the Service Level Agreement. You also specify the actions that will be taken in case they are fulfilled/not fulfilled.

defining the fulfillment criteria, SLO fulfillment criteria, defining the SLO fulfillment criteria

To define the Fulfillment Criteria do the following:

  1. In the Service Fulfillment section define the criteria that the service (object or group of objects) must meet:

    Runtime

    If you want to monitor the behavior of a service based on its runtime settings (MRT/SRT), make sure that they are specified in the corresponding object definition. For more information, see Runtime Page.

    If you select one or both of these options, a violation is generated if a service runs longer/shorter than the calculated MRT/SRT.

    • Activating Runs shorter than the Maximum Runtime (MRT) of the service means that the execution of the service cannot take longer that the Maximum Runtime specified in the object (that is, in the service) definition. If it runs longer than that, a violation is generated. This check is performed based on the Automation Engine internal timer interval defined in UC_JOB_CHECKINTERVAL (see UC_JOB_CHECKINTERVAL - Periodic Time Check in AE).

      Important! The violation is generated taking the next check interval into account. For this reason, it can be the case that a job with an MRT of 10 seconds can report a fulfillment for a run that took 15 seconds.

      Example:

      The check interval is set to 20 seconds. A Job starts 4 seconds after the check is triggered. The MRT in this Job is set to 10 seconds. The Job needs 11 seconds to run. It finishes 15 seconds after the check interval was triggered. Although the RRT of the Job is greater than its MRT, since the check interval is considered here, a false fulfillment is reported.

      This means that, based on the configured check interval (this is 20 seconds by default), the MRT has an additional threshold. In the case of the default interval, the MRT can always be MRT+20 seconds (in the worst case).

    • Activating Runs longer than the Minimum Runtime (SRT) of the service means that the execution of the service must take longer than the Minimum Runtime specified in the object definition. If it runs shorter than that, a violation is generated at service end.

    End status

    Activate this option if you want to check whether the service ends with a specific status or status group. A dropdown list is displayed, where you can select the required status. If the service ends with a status other than the selected one, a violation is generated.

    Time/Weekdays

    Activate one or more of these options if you want to check whether the service starts or ends at the times or days specified here. The latest start/end time checks are performed on the selected days only. If the start/end time of a service deviates from the entered ones, a violation is generated as soon as the indicated latest end time is reached. This check happens at full minutes (hh:mm:00 seconds).

    Note: The latest start/end time must lie within the SLO daily operation window.

  2. In the Actions section specify the actions that will be taken if those criteria are either fulfilled or not fulfilled. Activate one or both checkboxes and select the object(s) that should be executed as a result of the fulfillment/violation.

    The following script variables can be used in these objects to provide details on the services and reasons for the violation:

    • &uc_slm_slo_name#
    • &uc_slm_service_name#
    • &uc_slm_service_runid#
    • &uc_slm_service_time#
    • &uc_slm_violation_msg_number#
    • &uc_slm_violation_msg_insert#

    Important! Selecting an object that is itself SLM-monitored would lead to an endless loop of object executions. This is why the SLM Monitor ignores services/tasks that were executed based on previous fulfillments/violations.

    Sending Notifications

    One of the possible actions you may want to trigger is sending notifications to the users who are in charge of the services. For this purpose, the Automation Engine provides ready-to-use Notification templates with default scripts on their Process pages that build up either internal messages or e-mails, depending on the type of Notification you use. The service-specific information (object, client, service name, status, reasons why they failed, etc.) is retrieved from the monitored objects via the script variables they use. For more information, see Notification (CALL).

  3. Save your changes.

If the SLO object is enabled, it starts monitoring the services. The results are visible in the Services view in the Process Monitoring perspective. For more information, see Monitoring Services.

See also: