The SLO (Service Level Object) is the main building block of a service model. It allows mapping a business or IT service with all its redundant elements and it is the prerequisite for implementing service alarming. An SLO can summarize the state of devices or services (e.g. total availability of redundant services/links/etc.). Basic examples for such a services could be an DNS function with its primary and a secondary name servers, or a groups of Tomcat servers where only 3 out of 4 servers need to be running for the service to be available and offer sufficient performance.

To add an SLO: e.g. under /root /Customer /Services, select Add SLO from the dropdown menu:

After entering a name for the new SLO, specify its type (optional), then click OK or click OK, Add next if another SLO needs to be added:

The following SLO types can be chosen:

• Common
  
  • Application
  • Application step
  • Business
  • Customer
  • Device
  • Function
  • Infrastraucture
  • IT
  • Standard (default)
  • Top
• Process
  • Process
  • Process step
  • Process task

The default SLO type is Standard. If Top is chosen, the SLO appears in a Service inventory view. See section Show service inventory for more details.

Linking objects to an SLO

There are two methods to link objects to an SLO: dependencies (static) and filters (dynamic).

Dependencies

Sub-SLOs or other existing items from somewhere else in the object tree can be linked as a dependency using the Edit Dependency item on the SLO from the dropdown menu:

A new frame appears to the right where one can browse for objects to link into the SLO. Browse the object tree and select the objects by either clicking on each object’s arrow (only linkable objects have an active arrow attached), or by first selecting the required objects’ check boxes and then either one of the arrows in the right frame. The checkbox of the object where the arrow is clicked can be left unchecked, it will be selected anyway.

After adding the objects, they should appear on the left below the SLO. Click OK:

Linking objects to an SLO using EQL

Another way to quickly link specific objects to an SLO is using the EQL command line for recursive filtering. In the example above, 2 devices were linked to the SLO. However, service models mostly link individual jobs, not whole devices. Multiple jobs can be linked easily with EQL. As above, choose Edit Dependency from the SLOs dropdown menu, and browse to the parent group of the devices containing the jobs. Then click the EQL button in the right pane's lower right corner. Enter the EQL query get job in the EQL query field:

All jobs below the group /root /Customer /Devices are listed in the right pane. Select the ones that should be linked to the SLO and click one of the arrows. Confirm by clicking OK. The result:

Instead of listing all jobs with get job, EQL allows additional filtering by name or state etc. See Chapter EQL: SKOOR Engine query language for more details.

Filters

Instead of building static dependencies to objects, SLOs can dynamically link objects that match certain criteria. After adding an SLO, the Method in the Child objects section needs to be switched to Define Filter.

The Search below and Type dropdowns appears in the SLO configuration as well as a filter section to add criteria. Use the Browse button to select a group where objects for this SLO are searched. To add or remove filter criteria, the + or - buttons at the right side of the list can be clicked. 

Objects are added to and removed from the SLO automatically according to the defined criteria. 

SLO correlation rules

Now one can configure the influence the states of these underlying objects have on the SLO. Choose Edit parameters from the SLOs dropdown menu or click its pencil icon.

SLOs with state weighting AND, Any state

The default SLO States weighting is AND and States considered is set to Any state:

Resulting state-table

The SLO adopts the worst state of any of the linked objects:

SLOs with state weighting AND, Major only

In this example, the state weighting is AND and States considered is set to Major only. This means that all underlying objects must be in state OK or at least not in state Major, for the SLO to still be in state OK.

Resulting state-table

Only a major state of the linked objects Icmp on server1 and Icmp on server2 is inherited by the SLO. The state of the SLO is Major if the state of one underlying object is Major.

The following must be kept in mind for SLOs configured with the “AND” rule

• AND with Major only means that if 1 or more dependent objects are in state Major, the SLO will adopt the state Major.
• AND with Any state is the behavior of a group object. The SLO adopts the worst state of the linked objects (that is, the worst state below state No data). No data states are considered OK.
• An SLO without an object pushing a state (measurement) takes the state Undefined itself.
• Undefined states of objects below the SLO keep the state of the SLO also in the state Undefined as long as no other object pushes another state.
• As stopped or inactive jobs take the state Undefined, SLOs which have no active jobs below also become Undefined.

SLOs with state weighting OR

In the following example a third job has been linked to the SLO. The state weighting is OR and States considered is automatically set to Any state (for ‘must’). The simple OR configuration does only consider the major state of underlying objects. Only objects marked as Must can cause the SLO to take other states.

With the impact weighting, the number or percentage of child objects in state major is defined. As soon as this value is reached, the SLO will adopt the state major. There are two ways to configure the state weighting: 

• The number of objects in state major (At least)
• The number of objects that must be in a better state than major (Less)

With the fader below the impact weighting definition, the number of objects can be defined as well as by entering the number directly in the respective field.

The percentage of objects is a good choice especially when the SLO dynamically filters its child objects.

SLOs with state weighting OR (advanced)

For configurations that need to consider other states than major as well, the OR (advanced) state weighting must be configured. 

The numbers in the correlation matrix define the state of the SLO depending on the state of the underlying objects. If 1 failed (where failed means Major) child job should result in a Warning state on the SLO, 2 failed jobs should result in a Minor state and 3 failed jobs should make the SLO take the state Major, then the configuration would look like the following:

This example shows 1 failed job which causes the SLO to enter the Warning state (yellow).

The matrix is read as follows:

• The columns represent the state of the underlying objects of this SLO. The first column are the objects in state Warning, the second column the objects in state Minor and the third in state Major
• The rows represent the resulting state of the SLO

Resulting state-table

The state of the SLO depends on the impact weighting of the linked objects:

In the following example, also Minor states are considered for the overall state of the Top SLO:

3 jobs have a state of Minor or worse (2 Minor, 1 Major), so the weighting rule Minor if at least 3 of 3 are in state Minor or worse applies, leaving the SLO in state minor. 

Resulting state-table

SLOs with state weighting OR and Must parameter

The state of important child objects can be propagated to the SLO directly without considering any weighting impact rules, while at the same time allowing for weighting control of states pertaining to the other child objects. By checking the Must checkbox next to a child object, the object’s state is propagated upwards in the following way:

• If States considered is set to Any state (for ‘must’), any state of the Must object is propagated to the SLO, except if the state of the SLO takes a worse state already due to the weighting impact of the other objects not marked as Must
• If States considered is set to Major only (for ‘must’), only a Major state of the Must object is propagated to the SLO
• If more than one object is marked Must then the AND correlation behaviour applies to all Must objects, i.e. the worst state of all those objects is pushed upwards

The following figure depicts such a configuration:

Notice that the numbers next to the matrix fields (... of 2 are ...) are automatically decreased by 1 when setting 1 object as Must. However, the values inside the matrix fields are not updated automatically and need to be reconsidered after marking any objects Must. The impact weighting only considers objects in state Major. Due to the Must object, the SLO takes a Minor state because States considered is set to Any state (for 'must').

Resulting state-table

State simulation

While configuring an SLO, especially with impact weighting, it is helpful to test the impact of object states to the SLO. With the Simulate tab, the active configuration can be tested. The number of objects and Must objects can be overwritten to simulate the same SLO configuration with a different number of child objects. This is useful especially if the SLO uses a filter to link child objects and therefore can have different numbers of objects during its lifetime.

First, the simulation window shows a short message with the configured state weighting and the considered states for Must objects. Below this message, the screen is devided into two sections. The Inputs section contains a per state fader for Must objects (Count of 'must be up' SLO children) and normal objects (Count of SLO children (without 'must')). The SLO state section shows the resulting state depending on the fader positions in the Inputs section.

The Undefined and OK state faders automatically act upon other fader moves. All other faders must be set and reset manually. Note that the No Data state is considered as OK on SLOs.

Ignore maintenance flag

The Ignore maintenance flag causes any maintenance state of underlying objects (Maintenance Major, Maintenance Minor or Maintenance Warning) not to push their state up to the SLO (they are considered as OK). If, however, maintenance is set on the SLO itself, then this flag has no effect and the SLO will have maintenance set (see section Edit revaluation).

This is mostly set on Top SLOs of a Business service, where the business process owner and/or service manager may not be interested in objects somewhere beneath the Top SLO, which are currently under maintenance, as long as their service is not affected.

Is alarm reason flag

If this flag is set, instead of dependent jobs or SLOs, this SLO will appear as reason in alarms sent out by alarm devices.

Outage parent

Typically an organization defines service or process owners. In many cases these owners may not have full control over all of the sub-services their service depends on. In a situation where they depend on shared services, it may be required to make sure that outages of shared services will not discredit the service level of the overlying business process or service. This can be achieved by setting an Outage parent. The Outage parent can be another SLO, or an SLC, device, job or group object. For example, the owner of a business service can configure his business service top SLO with an Outage parent SLO that encompasses the most important IT infrastructure services in his network, i.e. DNS, DHCP, LDAP. If any of those services fail, the business service, which relies on them (implicitly), cannot function properly and thus should not be held responsible regarding the availability of his business service (SLA).

The following rules apply:

• If the Outage parent object goes to state Major, a maintenance window of 30 days is automatically created on all SLOs where this Outage parent is referenced.
• If the Outage parent object changes to any state different from Major, the Outage parent maintenance is automatically closed on all SLOs where this Outage parent is referenced.
• Outage parent maintenance windows and their behavior have no effect on already existing maintenance windows.

Behaviour of Outage parent maintenance

When the Outage parent changes its state to Major, the maintenance is immediately created on the dependent SLO, so no alarms are issued. The maintenance is created for the next 30 days with the hard-coded name outage parent maintenance:

The state history of the dependent SLO shows the maintenance as well, superimposed with blue colour and with the duration and name visible when hovering the mouse over the black line below the maintenance window:

Ordering of SLO child objects

The order of the SLOs child objects and thus how they are shown in the inventory and the object tree may be adjusted by selecting from the Sort objects dropdown list at the bottom of the SLO Behaviour section:

• Manually: Clicking the up and down buttons next to linked objects moves them to the specified position
• By name: The underlying objects are sorted alphabetically (no up/down buttons)
• By state: The underlying objects are sorted by their current state (no up/down buttons