Le SLO (Service Level Object) est l'élément constitutif principal d'un modèle de service. Il permet de cartographier un service métier ou informatique avec tous ses éléments redondants et constitue la condition préalable à la mise en œuvre d'une alerte de service. Un SLO peut résumer l'état des appareils ou des services (par exemple, la disponibilité totale des services/liens redondants, etc.). Des exemples simples de tels services pourraient être une fonction DNS avec ses serveurs de noms principaux et secondaires, ou un groupe de serveurs Tomcat où seuls 3 des 4 serveurs doivent être en fonctionnement 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 cliquez sur OK, Ajouter suivant si un autre SLO doit être ajouté :

Les types de SLO suivants peuvent être choisis :

• Commun
  
  • Application
  • Étape d'application
  • Entreprise
  • Client
  • Appareil
  • Fonction
  • Infrastructure
  • Informatique
  • Standard (par défaut)
  • Haut
• Processus
  • Processus
  • Étape du processus
  • Tâche du processus

Le type SLO par défaut est Standard. Si Haut est sélectionné, le SLO apparaît dans une vue d'inventaire des services. Pour plus d'informations, consultez la section Afficher l'inventaire des services.

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 autres éléments existants provenant d'un autre emplacement de l'arborescence des objets peuvent être liés en tant que dépendance à l'aide de l'élément Modifier la dépendance du SLO dans le menu déroulant :

Un nouveau cadre apparaît à droite, dans lequel vous pouvez rechercher les objets à lier au SLO. 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 cochant d'abord les cases des objets requis, puis en cliquant sur l'une des flèches dans le cadre de droite. La case de l'objet sur lequel vous cliquez peut rester décochée, il sera sélectionné de toute façon.

Une fois les objets ajoutés, ils devraient 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 le filtrage récursif. Dans l'exemple ci-dessus, deux appareils ont été liés au SLO. Cependant, les modèles de service lient principalement des tâches individuelles, et non des appareils entiers. Plusieurs tâches peuvent être facilement liées avec EQL. Comme ci-dessus, choisissez Modifier la dépendance dans le menu déroulant SLO, puis accédez au groupe parent des appareils contenant les tâches. Cliquez ensuite sur le bouton EQL dans le coin inférieur droit du volet droit. Entrez la requête EQL get job dans le champ de requête EQL :

Tous les travaux situés sous le groupe /root /Customer /Devices sont répertoriés dans le volet droit. 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 répertorier tous les travaux avec get job, EQL permet un filtrage supplémentaire par nom ou état, etc. Pour plus d'informations, consultez le chapitre EQL : langage de requête du SKOOR Engine.

Filtres

Au lieu de créer 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 dans la section Objets enfants doit être remplacée par Définir le filtre.

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

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

Règles de corrélation SLO

Il est désormais possible de configurer l'influence des états de ces objets sous-jacents sur le SLO. Choisissez Modifier les paramètres dans le menu déroulant SLO ou cliquez sur l'icône en forme de crayon.

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

La pondération par défaut des états SLO est AND et les états pris en compte sont définis sur Tout état :

Tableau d'états résultant

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

SLO avec pondération d'état AND, Major uniquement

Dans cet exemple, la pondération d'état est AND et les états pris en compte 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 le SLO reste dans l'état OK.

Tableau d'état résultant

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

Il convient de garder à l'esprit les éléments suivants pour les SLO configurés avec la règle « AND »

• ET avec Major signifie uniquement que si un ou plusieurs objets dépendants sont dans l'état Major, le SLO adoptera l'état Major.
• ET avec N'importe quel état correspond au comportement d'un objet de groupe. Le SLO adopte le pire état des objets liés (c'est-à-dire le pire état en dessous de l'état No Data). Les états No Data sont considérés comme OK.
• Un SLO sans objet poussant un état (mesure) prend lui-même l'état Undefined.
• Les états Undefined des objets sous le SLO maintiennent l'état du SLO également dans l'état Undefined tant qu'aucun autre objet ne pousse un autre état.
• Comme les tâches arrêtées ou inactives prennent l'état Undefined, les SLO qui n'ont pas de tâches actives en dessous deviennent également Undefined.

SLO avec pondération d'état OU

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

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

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

À l'aide du curseur situé sous la définition de la pondération d'impact, le nombre d'objets peut être défini, tout comme en saisissant directement le nombre dans le champ correspondant.

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

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

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

Les chiffres de la matrice de corrélation définissent l'état du SLO en fonction de l'état des objets sous-jacents. Si 1 tâche enfant ayant échoué (où « échoué » signifie Major) doit entraîner un état de Warning sur le SLO, 2 tâches ayant échoué doivent entraîner un état Minor et 3 tâches ayant échoué doivent faire passer le SLO à l'état Major, alors la configuration ressemblerait à ce qui suit :

Cet exemple montre qu'un travail ayant échoué entraîne le passage du SLO à l'état de 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 en état Warning, la deuxième colonne aux objets en état Minor et la troisième aux objets en état Major.
• Les lignes représentent l'état résultant du SLO.

Tableau 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 global du SLO supérieur :

3 tâches ont un état Minor ou pire (2 Minor, 1 Major), donc la règle de pondération Minor si au moins 3 sur 3 sont dans un état Minor ou pire s'applique, laissant le SLO dans un état Minor. 

Tableau d'état résultant

SLO avec pondération d'état OU et paramètre Must

L'état des objets enfants importants peut être propagé directement au SLO sans tenir compte des règles d'impact de pondération, tout en permettant le contrôle de la pondération des états relatifs aux 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 « États pris en compte » est défini sur « Tout état » (pour « Must »), tout état de l'objet Must est propagé au SLO, sauf si l'état du SLO est déjà moins bon en raison de l'impact de pondération des autres objets non marqués comme Must.
• Si « États pris en compte » est défini sur « Major uniquement » (pour « doit »), seul un état Major de l'objet « Doit » est propagé au SLO
• Si plusieurs objets sont marqués comme Must, le comportement de corrélation AND s'applique à tous les objets Must, c'est-à-dire que l'état le plus défavorable de tous ces objets est poussé vers le haut.

La figure suivante illustre une telle configuration :

Notez que les chiffres à côté des champs de la matrice (... sur 2 sont ...) sont automatiquement diminués de 1 lorsque vous définissez 1 objet comme Must. Cependant, les valeurs à l'intérieur des champs de la matrice ne sont pas mises à jour automatiquement et doivent être reconsidérées après avoir marqué des objets Must. 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 car States considered est défini sur Any state (pour « must »).

Tableau d'état résultant

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 des objets sur le SLO. L'onglet Simuler permet de tester la configuration active. Le nombre d'objets et d'objets obligatoires peut être remplacé afin de simuler la même configuration SLO avec un nombre différent d'objets enfants. Cela est particulièrement utile si le SLO utilise un filtre pour lier les objets enfants et peut donc avoir un nombre différent d'objets au cours de son cycle de vie.

Tout d'abord, la fenêtre de simulation affiche un court message avec la pondération d'état configurée et les états pris en compte pour les objets obligatoires. Sous ce message, l'écran est divisé en deux sections. La section Entrées contient un curseur par état pour les objets obligatoires (nombre d'enfants SLO « obligatoires ») et les objets normaux (nombre d'enfants SLO (sans « obligatoire »)). La section État SLO affiche l'état résultant en fonction des positions des curseurs dans la section Entrées.

Les curseurs d'état « Undefined » (Non défini) et « OK » agissent automatiquement sur les autres mouvements du curseur. Tous les autres curseurs doivent être réglés et réinitialisés manuellement. Notez que l'état « No Data » (No Data) est considéré comme « OK » sur les SLO.

Ignorer l'indicateur de maintenance

Le drapeau Ignorer la maintenance empêche tout état de maintenance des objets sous-jacents (Maintenance Major, Maintenance Minor ou Maintenance Warning) d'être transmis au SLO (ils sont considérés comme OK). Cependant, si la maintenance est définie sur le SLO lui-même, ce drapeau n'a aucun effet et la maintenance sera définie sur le SLO (voir la section Modifier la réévaluation).

Ceci est principalement défini sur les SLO supérieurs d'un service métier, où le propriétaire du processus métier et/ou le responsable du service peuvent ne pas être intéressés par les objets situés sous le SLO supérieur, qui sont actuellement en maintenance, tant que leur service n'est pas affecté.

Indicateur de raison de l'alarme

Si cet indicateur est activé, ce SLO apparaîtra comme raison dans les alarmes envoyées par les dispositifs d'alarme, à la place des tâches ou SLO dépendants.

Parent de la panne

En général, une organisation définit les propriétaires de services ou de processus. Dans de nombreux cas, ces propriétaires peuvent ne pas avoir le contrôle total sur 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 métier ou du service supérieur. Cela peut être réalisé en définissant un parent de panne. Le parent de panne peut être un autre SLO, ou un SLC, un dispositif, un travail ou un objet de groupe. Par exemple, le propriétaire d'un service métier peut configurer son SLO métier supérieur avec un SLO parent de panne qui englobe les services d'infrastructure informatique les plus importants de son réseau, à savoir DNS, DHCP, LDAP. Si l'un de ces services tombe en panne, le service métier qui en dépend (implicitement) ne peut pas fonctionner correctement et ne doit donc pas être tenu responsable de la disponibilité de son service métier (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ù cet objet parent « Outage » est référencé.
• Si l'objet parent Outage passe à un état différent de Major, la maintenance du parent Outage est automatiquement fermée sur tous les SLO où ce parent Outage est référencé.
• Les fenêtres de maintenance parentales Outage et leur comportement n'ont aucun effet sur les fenêtres de maintenance déjà existantes.

Comportement de la maintenance parentale de la panne

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

L'historique d'état du SLO dépendant affiche également la maintenance, superposée en bleu, avec la durée et le nom visibles lorsque vous passez la souris sur la ligne noire sous la fenêtre de maintenance :

Ordre des objets enfants SLO

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

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