Le SLO (Service Level Object) est le principal élément constitutif d'un modèle de service. Il permet de cartographier un service commercial ou informatique avec tous ses éléments redondants et constitue la condition préalable à la mise en œuvre d'une alarme de service. Un SLO peut résumer l'état des dispositifs ou des services (par exemple, la disponibilité totale des services/liens/etc. redondants). Des exemples de base pour de tels services pourraient être une fonction DNS avec ses serveurs de noms primaires et secondaires, ou un groupe de serveurs Tomcat où seulement 3 des 4 serveurs doivent fonctionner pour que le service soit disponible et offre des performances suffisantes.

Pour ajouter un SLO : par exemple, sous /root /Customer /Services, sélectionnez Add SLO dans le menu déroulant :

Après avoir saisi un nom pour le nouveau SLO, spécifiez son type (facultatif), puis cliquez sur OK ou sur OK, Ajouter suivant si un autre SLO doit être ajouté :

Les types d'OLS suivants peuvent être sélectionnés :

• Commun
  
  • Application
  • Étape de l'application
  • Entreprise
  • Client
  • Dispositif
  • Fonction
  • Infrastracture
  • INFORMATIQUE
  • Standard (par défaut)
  • Haut
• Processus
  • Processus
  • Étape du processus
  • Tâche de processus

Le type de SLO par défaut est Standard. Si l'option Haut est choisie, le SLO apparaît dans une vue de l'inventaire des services. Voir la section Afficher l'inventaire des services pour plus de détails.

Lier des objets à un SLO

Il existe deux méthodes pour lier des objets à un SLO : les dépendances (statiques) et les filtres (dynamiques).

Dépendances

Les sous-SLO ou d'autres éléments existants situés ailleurs dans l'arborescence des objets peuvent être liés en tant que dépendances à l'aide de l'élément Modifier la dépendance sur le SLO dans le menu déroulant :

Un nouveau cadre apparaît à droite, dans lequel il est possible de rechercher des objets à lier à l'OLS. Parcourez l'arborescence des objets et sélectionnez les objets en cliquant sur la flèche de chaque objet (seuls les objets pouvant être liés ont une flèche active) ou en sélectionnant d'abord les cases à cocher des objets requis, puis l'une ou l'autre des flèches dans le cadre de droite. La case à cocher de l'objet sur lequel la flèche est cliquée peut être décochée, elle sera de toute façon sélectionnée.

Une fois les objets ajoutés, ils doivent apparaître à gauche sous le SLO. Cliquez sur OK :

Lier des objets à un SLO à l'aide d'EQL

Une autre façon de lier rapidement des objets spécifiques à un SLO consiste à utiliser la ligne de commande EQL pour un filtrage récursif. Dans l'exemple ci-dessus, 2 périphériques ont été liés à l'OSS. Cependant, les modèles de service relient principalement des tâches individuelles, et non des dispositifs entiers. Il est facile de lier plusieurs tâches à l'aide d'EQL. Comme ci-dessus, choisissez Edit Dependency dans le menu déroulant SLOs et naviguez jusqu'au groupe parent des dispositifs contenant les tâches. Cliquez ensuite sur le bouton EQL dans le coin inférieur droit du volet de droite. Saisissez la requête EQL get job dans le champ EQL query (requête EQL) :

Tous les travaux situés sous le groupe /root /Customer /Devices sont répertoriés dans le volet de droite. Sélectionnez ceux qui doivent être liés au SLO et cliquez sur l'une des flèches. Confirmez en cliquant sur OK. Résultat :

Au lieu de lister tous les travaux avec get job, EQL permet un filtrage supplémentaire par nom ou par état, etc. Voir le chapitre EQL : Langage de requête de SKOOR Engine pour plus de détails.

Filtres

Au lieu d'établir des dépendances statiques avec des objets, les SLO peuvent lier dynamiquement des objets qui correspondent à certains critères. Après avoir ajouté un SLO, la méthode de la section Objets enfants doit être commutée sur Définir un filtre.

Les menus déroulants Search below et Type apparaissent dans la configuration du SLO, ainsi qu'une section de filtre pour ajouter des critères. Utilisez le bouton Parcourir pour sélectionner un groupe dans lequel les objets de ce SLO sont recherchés. Pour ajouter ou supprimer des critères de filtrage, vous pouvez cliquer sur les boutons + ou - situés à droite de la liste.

Les objets sont automatiquement ajoutés ou retirés du SLO en fonction des critères définis.

Règles de corrélation SLO

Vous pouvez maintenant configurer l'influence des états de ces objets sous-jacents sur le SLO. Choisissez Editer les paramètres dans le menu déroulant SLOs ou cliquez sur son icône en forme de crayon.

SLO avec pondération d'état ET, Tout état

Par défaut, la pondération des états du SLO est AND et les états considérés sont définis sur Any state :

Table d'états résultante

Le SLO adopte le pire état de tous les objets liés :

SLO avec pondération ET, Major uniquement

Dans cet exemple, la pondération des états est ET et les états considérés sont définis sur Major uniquement. Cela signifie que tous les objets sous-jacents doivent être dans l'état OK ou au moins ne pas être dans l'état Major, pour que l'OLS soit toujours dans l'état OK.

Table d'états résultante

Seul l'état Major des objets liés Icmp sur server1 et Icmp sur server2 est hérité par le SLO. L'état de l'OLS est Major si l'état d'un objet sous-jacent est Major.

Pour les OLS configurés avec la règle "ET", il convient de garder à l'esprit les points suivants

• AND avec Major signifie uniquement que si 1 ou plusieurs objets dépendants sont dans l'état Major, le SLO adoptera l'état Major.
• La règleET avec n'importe quel état correspond au comportement d'un objet de groupe. L'OLS adopte le pire état des objets liés (c'est-à-dire le pire état inférieur à l'état No Data). L'état Aucune donnée est considéré comme OK.
• Un SLO sans objet poussant un état (mesure) prend lui-même l'état Undefined.
• Les étatsindéfinis des objets situés en dessous de l'OSS maintiennent l'état de l'OSS également dans l'état Undefined tant qu'aucun autre objet ne pousse un autre état.
• Comme les travaux arrêtés ou inactifs prennent l'état Undefined, les SLO qui n'ont pas de travaux actifs en dessous deviennent également Undefined.

SLO avec pondération d'état OR

Dans l'exemple suivant, un troisième travail a été associé au SLO. La pondération des états est OR et les états pris en compte sont automatiquement définis sur Tout état (pour "doit"). La configuration simple OR ne prend en compte que l'état Major des objets sous-jacents. Seuls les objets marqués comme " must" peuvent amener le SLO à prendre d'autres états.

La pondération de l'impact permet de définir le nombre ou le pourcentage d'objets enfants dans l'état Major. Dès que cette valeur est atteinte, le SLO adopte l'état Major. Il existe deux façons de configurer la pondération d'état :

• Le nombre d'objets dans l'état majeur (Au moins).
• Le nombre d'objets qui doivent être dans un meilleur état que l'état majeur (Moins).

Le nombre d'objets peut être défini à l'aide du curseur situé sous la définition de la pondération d'impact ou en entrant le nombre directement dans le champ correspondant.

Le pourcentage d'objets est un bon choix, en particulier lorsque l'OLS filtre dynamiquement ses objets enfants.

SLO avec pondération d'état OR (avancé)

Pour les configurations qui doivent prendre en compte d'autres états que Major, la pondération d'état OR (avancée) doit être configurée.

Les chiffres de la matrice de corrélation définissent l'état de l'OLS en fonction de l'état des objets sous-jacents. Si un travail enfant en échec (où échec signifie Major) doit entraîner un état Warning sur le SLO, deux travaux en échec doivent entraîner un état Minor et trois travaux en échec doivent faire passer le SLO à l'état Major, la configuration se présente comme suit :

Cet exemple montre qu'un travail a échoué, ce qui fait passer l'OSS dans l'état Warning (jaune).

La matrice se lit comme suit :

• Les colonnes représentent l'état des objets sous-jacents de ce SLO. La première colonne correspond aux objets dans l'état Warning, la deuxième colonne aux objets dans l'état Minor et la troisième dans l'état Major.
• Les lignes représentent l'état résultant de l'OLS.

Table des états résultants

L'état du SLO dépend de la pondération de l'impact des objets liés :

Dans l'exemple suivant, les états Minor sont également pris en compte pour l'état général de l'OLS supérieur :

3 emplois ont un état Mineur ou pire (2 Mineurs, 1 Major), donc la règle de pondération Mineur si au moins 3 des 3 sont dans l'état Mineur ou pire s'applique, laissant le SLO dans l'état Mineur.

Table d'état résultante

OLS avec pondération de l'état OR et paramètre Must

L'état des objets enfants importants peut être propagé directement à l'OLS sans tenir compte des règles de pondération, tout en permettant le contrôle de la pondération des états des autres objets enfants. En cochant la case Must à côté d'un objet enfant, l'état de l'objet est propagé vers le haut de la manière suivante :

• Si States considered est défini sur Any state (pour "must"), tout état de l'objet Must est propagé au SLO, sauf si l'état du SLO est déjà pire en raison de l'impact de la pondération des autres objets qui ne sont pas marqués comme Must.
• Si le paramètre States considered est défini sur Major only (pour "must"), seul un état Major de l'objet Must est propagé à l'OSS.
• Si plus d'un objet est marqué comme " Must", le comportement de corrélation AND s'applique à tous les objets "Must", c'est-à-dire que le pire état de tous ces objets est poussé vers le haut.

La figure suivante illustre une telle configuration :

Remarquez que les nombres à côté des champs de la matrice (... of 2 are ...) sont automatiquement diminués de 1 lorsque l'on définit un objet comme " Must". Cependant, les valeurs à l'intérieur des champs de la matrice ne sont pas mises à jour automatiquement et doivent être réexaminées après avoir marqué un objet comme " obligatoire". La pondération de l'impact ne prend en compte que les objets dans l'état Major. En raison de l'objet Must, le SLO prend un état Minor parce que States considered est défini sur Any state (pour 'must').

Table d'état résultante

Simulation d'état

Lors de la configuration d'un SLO, en particulier avec la pondération d'impact, il est utile de tester l'impact des états de l'objet sur le SLO. L'onglet Simuler permet de tester la configuration active. Le nombre d'objets et d'objets Must peut être écrasé pour simuler la même configuration SLO avec un nombre différent d'objets enfants. Cette fonction est particulièrement utile si le SLO utilise un filtre pour relier les objets enfants et peut donc avoir différents nombres d'objets au cours de sa durée de vie.

Tout d'abord, la fenêtre de simulation affiche un court message indiquant la pondération d'état configurée et les états considérés pour les objets Must. En dessous de ce message, l'écran est divisé en deux sections. La section Inputs contient un curseur par état pour les objets Must(nombre d'enfants SLO 'must be up') et les objets normaux (nombre d'enfants SLO(sans 'must')). La section État SLO montre l'état résultant en fonction des positions des faders dans la section Entrées.

Les faders d'état Undefined et OK agissent automatiquement sur les mouvements des autres faders. Tous les autres faders doivent être réglés et réinitialisés manuellement. Notez que l'état No Data est considéré comme OK sur les SLO.

Indicateur demaintenance Ignorer

L'indicateur Ignorer la maintenance fait en sorte que tout état de maintenance des objets sous-jacents (Maintenance Major, Maintenance Minor ou Maintenance Warning) ne transmet pas leur état à l'OLO (ils sont considérés comme OK). Si, toutefois, la maintenance est définie sur l'OLO lui-même, cet indicateur n'a aucun effet et l'OLO aura la maintenance définie (voir la section Modifier la revalorisation).

Cet indicateur est surtout utilisé pour les SLO supérieurs d'un service d'entreprise, car le propriétaire du processus d'entreprise et/ou le gestionnaire du service peuvent ne pas s'intéresser aux objets situés sous le SLO supérieur, qui sont actuellement en cours de maintenance, tant que leur service n'est pas affecté.

Indicateur demotif d'alarme

Si cet indicateur est activé, ce SLO apparaîtra comme motif dans les alarmes envoyées par les dispositifs d'alarme, au lieu des travaux ou des SLO dépendants.

Parent d'interruption

En général, une organisation définit des propriétaires de services ou de processus. Dans de nombreux cas, ces propriétaires peuvent ne pas avoir le contrôle total de tous les sous-services dont dépend leur service. Dans une situation où ils dépendent de services partagés, il peut être nécessaire de s'assurer que les pannes des services partagés ne discréditent pas le niveau de service du processus ou du service d'entreprise sous-jacent. Pour ce faire, on peut définir un parent d'interruption. Le parent d'interruption peut être un autre SLO, ou un SLC, un équipement, un travail ou un objet de groupe. Par exemple, le propriétaire d'un service métier peut configurer son SLO supérieur avec un SLO parent de panne qui englobe les services d'infrastructure informatique les plus importants de son réseau, c'est-à-dire DNS, DHCP, LDAP. Si l'un de ces services tombe en panne, le service commercial, qui en dépend (implicitement), ne peut pas fonctionner correctement et ne doit donc pas être tenu pour responsable de la disponibilité de son service commercial (SLA).

Les règles suivantes s'appliquent :

• Si l'objet parent Outage passe à l'état Major, une fenêtre de maintenance de 30 jours est automatiquement créée sur tous les SLO où ce parent Outage est référencé.
• Si l'objet parent de l'interruption passe à un état différent de Major, la maintenance du parent de l'interruption est automatiquement fermée sur tous les SLO où ce parent de l'interruption est référencé.
• Les fenêtres de maintenance duparent de panne et leur comportement n'ont aucun effet sur les fenêtres de maintenance déjà existantes.

Comportement de la gestion du parent Outage

Lorsque le parent d'interruption passe à l'état Major, la maintenance est immédiatement créée sur l'OSS dépendant, de sorte qu'aucune alarme n'est émise. La maintenance est créée pour les 30 prochains jours avec le nom codé en dur outage parent maintenance:

L'Historique d'état du SLO dépendant montre également la maintenance, en surimpression avec une couleur bleue et avec la durée et le nom visibles lorsque l'on passe la souris sur la ligne noire en dessous de la fenêtre de maintenance :

Ordre des objets enfants de l'OLS

L'ordre des objets enfants des OLS, et donc leur affichage dans l'inventaire et l'arborescence des objets, peut être modifié en sélectionnant l'option Trier les objets dans la liste déroulante située au bas de la section Comportement des OLS:

• Manuellement: En cliquant sur les boutons haut et bas situés à côté des objets liés, ceux-ci sont déplacés vers la position spécifiée.
• Par nom: les objets sous-jacents sont triés par ordre alphabétique (pas de boutons haut/bas ).
• Par état: Les objets sous-jacents sont triés en fonction de leur état actuel (pas de boutons haut/bas ).