Le SLO (Service Level Object) est le principal élément constitutif d’un modèle de service. Il permet de cartographier un service métier ou informatique avec tous ses éléments redondants et constitue le prérequis à la mise en œuvre d'un service d'alarme. Un SLO peut résumer l'état des appareils ou des services (par exemple, 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 principal et secondaire, ou un groupe de serveurs Tomcat où seuls 3 serveurs sur 4 doivent être exécutés pour que le service soit disponible et offre des performances suffisantes.

Pour ajouter un SLO : par exemple, sous /root /Customer /Services , sélectionnez Ajouter un 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 ensuite si un autre SLO doit être ajouté :

Les types de SLO suivants peuvent être choisis :

• Commun
  
  • Application
  • Étape de candidature
  • Entreprise
  • Client
  • Appareil
  • Fonction
  • Infrastructures
  • IL
  • Standard (par défaut)
  • Haut
• Processus
  • Processus
  • Marche à suivre
  • Tâche de processus

Le type de SLO par défaut est Standard . Si Top est choisi, le SLO apparaît dans une vue d'inventaire de service . 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 ailleurs dans l'arborescence des objets peuvent être liés en tant que dépendance à l'aide de l'élément Modifier la dépendance sur le SLO dans le menu déroulant :

Un nouveau cadre apparaît à droite où l'on peut rechercher des objets à lier au SLO. Parcourez l'arborescence des objets et sélectionnez les objets en cliquant soit sur la flèche de chaque objet (seuls les objets pouvant être liés ont une flèche active attachée), soit en cochant d'abord les cases des objets requis, puis l'une des flèches dans le cadre de droite. La case de l'objet sur lequel la flèche est cliquée peut être laissée décochée, elle sera quand même sélectionnée.

Après avoir ajouté les objets, 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, 2 appareils étaient liés au SLO. Cependant, les modèles de service relient 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 et 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. Saisissez la tâche d'obtention de requête EQL dans le champ de requête EQL :

Toutes les tâches situées sous le groupe /root /Customer /Devices sont répertoriées 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 . Le résultat:

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

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 basculée sur Define Filter .

Les listes déroulantes Rechercher ci-dessous et Type apparaissent dans la configuration 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 filtre, vous pouvez cliquer sur les boutons + ou - situés à droite de la liste.

Les objets sont ajoutés et supprimés automatiquement du SLO selon les critères définis.

Règles de corrélation SLO

On peut désormais 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 son icône en forme de crayon.

SLO avec pondération d'état ET, n'importe quel état

La pondération par défaut des États SLO est AND et les États considérés sont définis sur N'importe quel état :

Table d'état résultante

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

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

Dans cet exemple, la pondération de l'état est AND et l'état considéré est défini sur Major uniquement . Cela signifie que tous les objets sous-jacents doivent être dans l'état OK ou du moins pas dans l'état Major pour que le SLO soit toujours dans l'état OK .

Table d'état résultante

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

Les éléments suivants doivent être gardés à l’esprit pour les SLO configurés avec la règle « AND »

• AND avec Major signifie seulement que si 1 ou plusieurs objets dépendants sont dans l'état Major , le SLO adoptera l'état Major .
• ET avec Any state est le comportement d'un objet groupe. Le SLO adopte le pire état des objets liés (c'est-à-dire le pire état inférieur à l'état No data ). Aucun état de données n'est considéré comme OK .
• Un SLO sans objet poussant un état (mesure) prend lui-même l'état Undefined .
• Les états Undefined des objets situés en dessous du SLO maintiennent également l'état du SLO 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 ci-dessous deviennent également Undefined .

SLO avec pondération d'état OU

Dans l'exemple suivant, une troisième tâche a été liée au SLO. La pondération de l'état est OR et les États considérés sont automatiquement définis sur Any state (pour « must »). La configuration OR simple ne prend en compte que l'état majeur des objets sous-jacents. Seuls les objets marqués comme Must 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 sera atteinte, le SLO adoptera la major d'État. Il existe deux manières de configurer la pondération des états :

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

Avec le curseur situé sous la définition de la pondération d'impact, le nombre d'objets peut être défini ainsi qu'en saisissant le nombre directement dans le champ correspondant.

Le pourcentage d'objets est un bon choix, surtout 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 des états autres que majeurs, la pondération de l'état OR (avancé) doit être configurée.

Les nombres dans 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ù échec signifie Major ) doit entraîner un état Warning sur le SLO, 2 tâches ayant échoué doivent entraîner un état Minor et 3 tâches ayant échoué doivent faire prendre au SLO l'état Major , alors la configuration ressemblera à celle-ci. suivant:

Cet exemple montre 1 tâche ayant échoué, ce qui fait passer le SLO à 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 sont les objets en état Warning , la deuxième colonne les objets en état Minor et la troisième en état Major
• Les lignes représentent l'état résultant du SLO

Table d'état résultante

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

Dans l'exemple suivant, les états Minor sont également pris en compte pour l'état global du Top SLO :

3 emplois 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 mineur.

Table d'état résultante

SLO avec pondération d'état OR 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 en même temps un contrôle de 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 se propage vers le haut de la manière suivante :

• Si States considéré est défini sur Any state (pour 'must') , tout état de l'objet Must est propagé au SLO, sauf si l'état du SLO prend déjà un état moins bon en raison de l'impact de pondération des autres objets non marqués. comme il faut
• Si States considéré est défini sur Major uniquement (pour 'must') , seul un état Major de l'objet Must est propagé au SLO.
• Si plusieurs objets sont marqués Must, alors 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 :

Notez que les nombres à côté des champs de la matrice (... sur 2 sont ...) sont automatiquement diminués de 1 lors de la définition d'un objet comme Must . Cependant, les valeurs à l'intérieur des champs matriciels ne sont pas mises à jour automatiquement et doivent être reconsidérées après avoir marqué des objets Must . La pondération d'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 considéré 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 des objets sur le SLO. Avec l'onglet Simuler , la configuration active peut être testée. 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. Ceci 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 sa durée 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 considérés pour les objets Must . Sous ce message, l'écran est divisé en deux sections. La section Entrées contient un fader 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 affiche 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 autres mouvements de fader. 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.

Ignorer l'indicateur de maintenance

L'indicateur Ignorer la maintenance empêche tout état de maintenance des objets sous-jacents ( Maintenance Major , Maintenance Minor ou Maintenance Warning ) de pousser leur état jusqu'au SLO (ils sont considérés comme OK ). Toutefois, si la maintenance est définie sur le SLO lui-même, cet indicateur 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 Top SLO d'un service Business, où le propriétaire du processus métier et/ou le gestionnaire de services peuvent ne pas être intéressés par les objets quelque part sous le Top SLO, qui sont actuellement en maintenance, tant que leur service n'est pas affecté.

Est-ce qu'il s'agit d'un indicateur de motif d'alarme

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

Parent en panne

Généralement, une organisation définit les propriétaires de services ou de processus. Dans de nombreux cas, ces propriétaires peuvent ne pas avoir un 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 de services partagés ne discréditeront pas le niveau de service du processus métier ou du service sous-jacent. Ceci peut être réalisé en définissant un parent Outage . Le parent de panne peut être un autre SLO ou un SLC, un périphérique, une tâche ou un objet de groupe. Par exemple, le propriétaire d'un service métier peut configurer son SLO principal de service métier avec un SLO parent 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 pourra pas fonctionner correctement et ne pourra 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ù ce parent Outage est référencé.
• Si l'objet parent Outage passe à un état différent de Major , la maintenance parent Outage est automatiquement fermée sur tous les SLO où ce parent Outage est référencé.
• Les fenêtres de maintenance parent en cas de panne et leur comportement n'ont aucun effet sur les fenêtres de maintenance déjà existantes.

Comportement de la maintenance parentale en cas de panne

Lorsque le parent Panne change son état en Major , la maintenance est immédiatement créée sur le SLO dépendant, donc aucune alarme n'est émise. La maintenance est créée pour les 30 prochains jours avec le nom codé en dur maintenance parent panne :

L'historique de l'état du SLO dépendant montre également la maintenance, superposée en bleu et 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 des SLO et donc la manière dont ils sont affichés dans l'inventaire et l'arborescence des objets peuvent être ajustés en les sélectionnant dans la liste déroulante Trier les objets au bas de la section Comportement du 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 (pas de boutons haut / bas )
• Par état : Les objets sous-jacents sont triés selon leur état actuel (pas de boutons haut / bas