Service Agreements

Service Agreements, also called Service Level Agreements or Service Level Objectives, are collections of metrics associated with services performance, availability and traffic volumes validated against assigned thresholds. Service Agreements, hereafter called Sentinet SLA or just SLA, serve two purposes. They can define service consumption, availability, and other metrics related to business and operational agreements that are established between the service provider and service consumers. They can also be considered as isolated system events that are triggered when service performance or other monitoring metrics violate configured thresholds.

Sentinet Service Agreements Management helps organizations and IT operations understand and implement best practices for monitoring, diagnostics and reporting to maintain reliable and scalable applications. As degradations in IT Service delivery can be costly and damaging to business, many organizations are implementing strict Service Level Agreements to ensure high standards of IT service. Defining Service Level Agreements is even more critical in the case of remote cloud deployments, where Service Agreements may exist between the service provider and the cloud provider, but lack relationship implementation between the service provider and the service consumers.

Consider all messages processed by Sentinet during a defined period, these can be filtered, selected and reported on by targeted virtual services, their interfaces, operations, or endpoints as well as by specific Access Rules. Sentinet uses these collections to calculate assigned aggregate metrics and validate these aggregate metrics against configured thresholds. Ultimately, a Sentinet SLA is defined as an entity that covers a specific scope of virtual service(s) filtered by access rules and validated against one or more aggregate metrics and their thresholds.

Service Agreement = Time Period Coverage + Scope + Access Rule + Metrics + Metric Thresholds

From business and IT operational perspectives, a Sentinet SLA monitors a specific service (or multiple services) accessed by specific consumers against those metrics configured for the SLA. Sentinet users can create different SLAs covering the same service (or services) but for different service consumers. A single SLA can be created to monitor a collection of metrics or multiple SLAs can be created to monitor one metric at a time.

The ultimate purpose of each SLA is to provide monitoring and subsequent alerting in the event of violations. SLA violations do not block access to services but can be configured with alert handlers (see the Alert Actions chapter for more details), that may implement custom actions beyond simple notifications. For example, custom alert actions can start external management scripts.

Select the Repository folder for which a new SLA needs to be created (or select the Service Agreements Repository tree item element), right-click and select the + Add->Service Agreement menu option. Alternatively, use the Add->Service Agreement menu in the main toolbar.

Service Agreement SUMMARY screen
Figure. Service Agreement SUMMARY screen

  1. Enter a Service Agreement friendly name in the Name field. The friendly name will be used in alerts when SLA is violated.

  2. Enter a valid start date and time in the Start Date field. All active Service Agreements must be provided with a start date and time that identify which period it covers. A start date and time can be in the future, which allows configuring and activating a Sentinet SLA, before it is actively monitored.

  3. Enter an optional end date and time in the End Date field. If an end date and time is not specified, the Sentinet SLA is monitored indefinitely until its end date is assigned at a later time.

  4. Select SLA monitoring Time Zone. Sentinet Service Agreement monitoring depends on the data aggregated over relevant time intervals. Results of these aggregations may depend on the time zone used to calculate aggregations. By default, Sentinet selects the local time zone of the Sentinet server machine that hosts the Repository Services application.

    Example of the Time Zone relevance:

    1. SLA states that there should be no more than 100,000 transactions per day.
    2. Suppose that in the time zone defined for the Sentinet SLA there were 100,001 transactions sent in one day, which means that SLA was violated.
    3. In another time zone the same physical period falls in two different days, and it happens that total of 100,001 transactions were distributed as 50,000 in one day and 50,001 in another day. In that time zone, there were no SLA violations in either day.

  5. Set Service Agreement lifecycle state. Below is the summary of each state definition:

  • Draft

    Any SLA property can be changed. Service Agreements in draft state are neither monitored nor is any relevant monitoring data collected.

  • Active

    Requires a valid start date and time, targeted service scope(s) and at least one monitoring metric. An active Service Agreement is actively monitored if its SLA period covers current time (SLA period is not in the past and is not in the future).

  • Retired

    Remain visible in the Repository but are not actively monitored. One of the reasons to keep SLAs in Retired state (rather than to delete them), is to keep an SLA definition and its violations for historical reporting.

  1. Enter an optional Service Agreement description in the Description field.

  2. Define the SLA service coverage scope (see Service Agreement Scope below).

  3. Define one or more monitoring metrics (see Service Agreement Metrics below).