Disponibilité étendue (SLA)

Dans Checkmk, vous pouvez évaluer la disponibilité et, pour cela, configurer une évaluation SLA rudimentaire. Or, la disponibilité absolue sur une période donnée n’est pas particulièrement significative. Prenons un exemple extrême : une disponibilité de 99,9 % autoriserait moins de 10 heures de période de maintenance par an — en réalité, seulement 8 heures, 45 minutes et 36 secondes pour être précis. Si l’on répartit ces 8,76 heures sur une année, cela donne en moyenne un peu plus de 43 minutes par mois — ce qui peut être acceptable pour de nombreux systèmes. Une interruption d’une heure d’affilée causerait toutefois beaucoup de dommages. Il est évident qu’une telle interruption doit être prise en compte dans l’évaluation de la disponibilité.

Si vous utilisez l’une des éditions commerciales, Checkmk dispose d’une fonction distincte pour les service level agreements (SLA). La fonctionnalité SLA s’appuie sur les données de disponibilité et permet désormais une évaluation beaucoup plus détaillée.

Deux types d'évaluation de base peuvent être mis en œuvre :

Vous pouvez combiner l'un ou les deux types pour plusieurs instances – par exemple, pour garantir que, pendant la période de reporting, un service particulier soit au moins à 90 % en état « OK », et qu'un maximum de deux événements d'une durée de deux minutes ou plus soit autorisé pour signaler la condition « CRIT ».

Les résultats de ces calculs peuvent ensuite être affichés sous deux formats dans les vues de la table :

Par exemple, vous pouvez voir ici l'évaluation d'un système de fichiers dans l'aperçu : à partir d'aujourd'hui (avec 3 icônes dans la colonne la plus à droite) et pour les 15 jours précédents — et constater immédiatement qu'il y a eu des problèmes évidents jusqu'à il y a 4 jours :

Mais que vous révèlent ces évaluations à présent ? D'une part, vous pouvez constater le respect ou le non-respect des SLA achevés et, par exemple, informer vos clients de ces évaluations. D'autre part, vous pouvez déjà identifier à l'avance une défaillance imminente : Par défaut, l'indicateur SLA s'allume en mode « CRIT » lorsque sa valeur a été dépassée. Mais il peut également être réglé de manière à passer en mode « CRIT » si, par exemple, l'état d'CRIT autorisé pour le service a atteint 80 % — et avant ce seuil, il pourrait passer à un indicateur « WARN ».

En fin de compte, les SLA sont pour la plupart des vues de la table très détaillées, générées à partir de l’analyse des données de disponibilité. Vous les verrez plus tard à deux endroits : dans des tableaux, soit pour tous les ordinateurs hôtes et services qui y sont répertoriés, soit uniquement pour les services spécifiquement liés à des SLA individuels. Deuxièmement, il existe une page de détails complète pour chaque combinaison service-SLA.

La fonction SLA repose sur les données de disponibilité. Les calculs relatifs aux spécifications SLA ne s’appliquent bien sûr pas à l’ensemble des données brutes – après tout, les rapports SLA doivent couvrir des périodes de temps spécifiques. Il faut donc d’abord déterminer pour quelle période les exigences SLA doivent être respectées – ce que l’on appelle la « période SLA ». Par exemple : « Au cours de chaque période de supervision mensuelle, l’état du service MyService doit être d’au moins 90 % d’OKité. » Pour cette période SLA, toutes les données du mois correspondant à un fonctionnement 24 h/24 et 7 j/7 ne seront pas nécessairement (inévitablement) utilisées. Les données peuvent être converties aux périodes de temps définies dans la Configuration, c’est-à-dire être limitées approximativement aux heures de travail.

Il en résulte alors une exigence plus concrète, telle que : « Le service MyService sur un mois (la période SLA), pendant les heures de travail (la période de temps) – du lundi au vendredi de 10 h 00 à 20 h 00 – doit être disponible à 90 % (exigence SLA). » Le SLA et les périodes de temps se complètent, ces dernières n’étant bien sûr pas obligatoirement limitées : vous pouvez utiliser l’ensemble des données de supervision générées au cours de la période de temps SLA.

En résumé : vous avez besoin de deux périodes pour délimiter la base de données servant au calcul d’une exigence SLA :

Un résultat indépendant est généré pour chaque période SLA. Le nombre de ces résultats individuels que vous affichez dans un tableau peut être configuré via les vues de la table. Ainsi, par exemple, les cinq dernières semaines, limitées aux jours ouvrables, sont affichées sous forme de cinq périodes SLA distinctes directement sur les ordinateurs hôtes et les services.

Comme d’habitude avec Checkmk, entre la source de données (définition du SLA) et la sortie (vue de la table), il faut encore attribuer une règle aux services spécifiques au SLA — mais ce n’est pas obligatoire. Pour les SLA, cela se traduit donc généralement par un processus en trois étapes, lorsqu’ils s’appliquent à des services spécifiés :

Voici comment configurer un SLA simple incluant une vue de la table : Les systèmes de fichiers des ordinateurs hôtes MyHost1 et MyHost2 doivent, sur une période de rapport d’une semaine, se trouver dans une condition « OK » pendant au moins 90 % du temps (dans cet exemple, un maximum de 80 % a été atteint). De plus, ils sont autorisés à passer à la condition « WARN » pendant deux minutes ou plus, pour un maximum de cinq occurrences.

Commencez par créer le SLA proprement dit. La configuration est accessible via «Customize > Business reporting > Service Level Agreements» (à noter que cet élément d'entrée n'est visible qu'en mode Show more) :

Créez un nouveau SLA via New SLA. Dans la section « General Properties », attribuez d'abord un identifiant unique, ici MySLA, ainsi qu'un titre, tel que « Filesystems » :

Sous « SLA settings », définissez la période souhaitée pour le SLA, par exemple « Weekly ». Les exigences suivantes s'appliqueront donc toujours pendant cette période d'une semaine.

Mais vous pouvez, avant de configurer les exigences proprement dites, ajouter d'autres restrictions sous « Filtering and computation options », et définir des options qui ne sont toutefois pas nécessaires pour notre exemple simple de SLA :

Spécifiez ensuite les exigences réelles dans la section «SLA requirements» (Configuration des exigences) avec «Add new timeperiod» (Définir les exigences). Tant que vous avez spécifié des périodes de temps, celles-ci peuvent également être utilisées avec les SLA, comme déjà mentionné pour la disponibilité générale. Sélectionnez une période de temps sous «Active in timeperiod» (Définir la période de temps), ou comme ici dans l’exemple «24X7 - Always» (24 h/24, 7 j/7) pour définir les exigences d’un fonctionnement 24 h/24, 7 j/7. Sous «Title» (Définir les exigences), donnez un nom significatif, par exemple «90 percent OK» :

Pour Computation Type, pour la première requête, sélectionnez Service state percentage et ajoutez un nouveau critère via Add state configuration. Un nouveau paragraphe s'ouvre pour le Monitoring state requirement. Pour exiger une disponibilité d'au moins 90 %, définissez cet enregistrement sur OK, minimum, 90. Si cette valeur n'est pas atteinte, le SLA est considéré comme rompu et prend l'état CRIT, comme on le verra plus tard sur la page des résultats.

Peut-être que le SLA ne devrait pas attendre qu’il soit rompu pour passer à CRIT, mais directement à WARN dès que 50 % de la marge est consommée, puis à CRIT s’il reste 10 % de marge. Ce qui rompt réellement le SLA produirait alors broken, mais aucun autre changement d’état (plus d’informations à ce sujet ci-dessous dans la section « Page de détails du SLA »). Pour une telle configuration, checkez la case à Levels for SLA monitoring. Vous pouvez ici saisir les valeurs résiduelles pour la transition vers WARN et CRIT. Cela achève la première requête.

Ajoutez maintenant une deuxième requête avec Add new timeperiod. Définissez à nouveau la période de temps – sous « Title », par exemple, indiquez « Max 5 warnings of 2 minutes » comme nom et, dans ce cas, définissez « Computation Type » sur « Maximum number of service outages » : La requête effective est alors : Maximum 5 times WARN with duration 0 days 0 hours 2 mins 0 secs :

Conformément au SLA, par période SLA, le service est désormais autorisé à se trouver dans l’état spécifié au maximum cinq fois, et chaque occurrence pendant deux minutes au maximum, sans que le SLA ne soit signalé comme rompu. Au lieu de « WARN », un autre état pourrait bien sûr également être spécifié à ce stade. Et là encore, via l’option « Levels for SLA monitoring », vous pouvez également affiner et déterminer combien d’incidents restants déclencheront un avertissement, avant que le SLA ne soit effectivement rompu avec un « WARN » ou un « CRIT ».

Comme mentionné précédemment, vous pouvez ajouter d’autres exigences de ce type et assembler des SLA détaillés. Mais il n’y a toujours pas de services qui « réagissent » à ce SLA — dans notre exemple, une règle doit établir cette connexion. La manière d’utiliser la configuration créée jusqu’à présent sans une telle connexion de service SLA est décrite ci-dessous dans la section consacrée aux affichages SLA spécifiques aux colonnes.

Le SLA est relié à un service via le jeu de règles «Setup > Services > Service monitoring rules > Assign SLA definition to service». Créez une règle, activez la seule option spécifique à la règle «Assign SLA to service», puis sélectionnez votre définition de SLA «MySLA», répertoriée ici sous son titre «Filesystems».

Ensuite, sous « Conditions » (Filtrer les services) dans la section « Services » (Définir les services), définissez des filtres supplémentaires pour les services souhaités. Comme toujours, vous pouvez ici utiliser des expressions régulières et, comme dans cet exemple, associer la définition du SLA à tous les systèmes de fichiers locaux via Filesystem. Vous pouvez également restreindre l'ensemble à l'aide des filtres spécifiques à la règle pour les dossiers, les balises de l’hôte et les hôtes explicites ; dans notre exemple, il s'agit des hôtes MyHost1 et MyHost2 :

Bien sûr, à ce stade, vous pourriez également omettre tout filtrage de service et simplement lier le SLA à tous les services. La manière dont il est préférable de procéder à l'aide d'une vue de la table SLA spécifique à une colonne, ainsi que les raisons de ce choix, sont expliquées ci-dessous.

Vous avez donc maintenant créé la définition de SLA MySLA et l’avez associée à tous les services des deux ordinateurs hôtes commençant par Filesystem. Créez maintenant une nouvelle vue pour les SLA. Pour l’exemple de SLA, une vue simple des deux ordinateurs hôtes avec leurs services de système de fichiers et leurs SLA devrait suffire. À titre de clarification, les services Checkmk auxquels aucun SLA n’est actuellement associé sont ajoutés. Le résultat ressemblera à l’image à la fin de ce chapitre.

Créez une nouvelle vue de la table avec Customize > Visualization > Views > Add view. Dans la première requête, spécifiez All services comme Datasource. Confirmez la requête suivante pour indiquer si les informations d’un seul objet doivent être affichées avec la valeur par défaut No restrictions to specific objects.

Sous « General Properties », saisissez un ID (ici MySLAView_Demo), un titre (tel que My SLA Demo View), puis sélectionnez un thème tel que Workplace si vous souhaitez voir les vues SLA ultérieurement sous un élément distinct du menu « Supervision ». Toutes les autres valeurs peuvent rester inchangées pour ce test.

Accédez maintenant à la case de dialogue « Columns » et, dans un premier temps, via « Add column », ajoutez les trois colonnes générales « Services: Service state », « Hosts: Hostname » et « Services: Service description » comme base de la vue de la table.

Le sélecteur de colonnes contient également deux colonnes spécifiques aux SLA : Hosts/Services: SLA - Service specific et Hosts/Services: SLA - Column specific. Cette dernière affiche une définition de SLA fixe pour chaque service de la vue de la table — ce qui constitue une meilleure alternative à un SLA unique pour tous les services, comme mentionné ci-dessus. Nous y reviendrons plus tard.

Ajoutez à ce stade la colonne « Hosts/Services: SLA - Service specific ». Vous disposez désormais de toutes sortes d’options pour la présentation des résultats des SLA :

SLA timerange : utilisez cette option pour définir la période de temps pour laquelle vous souhaitez voir les résultats SLA. Par exemple, si votre définition SLA comporte la période de reporting « Monthly » et que vous sélectionnez ici « Last Year », vous obtiendrez douze résultats individuels. Dans cet exemple, l’option « SLA period range » est utilisée pour spécifier directement le nombre de périodes de temps affichées : Pour cinq périodes de temps/résultats, définissez « Starting from period number » sur « 0 » et « Looking back » sur « 4 ».

Layout options : par défaut, cette option est définie sur Only Display SLA Name. Pour afficher les résultats des SLA, sélectionnez ici Display SLA statistics. Vous pouvez sélectionner jusqu’à trois éléments différents :

Activez les trois options pour cet exemple.

Generic plugin display options : À ce stade, pour l’affichage des SLA d’indisponibilité/pourcentage, définissez si les résumés (textes) ou respectivement les résultats individuels (icônes) pour les périodes de reporting doivent apparaître. Pour voir les deux en action, laissez l’option des SLA de pourcentage sur « Show separate result for each SLA period » et sélectionnez « Service outage count display options » pour « Show aggregated info over all SLA periods ».

Si vous souhaitez regrouper la vue par ordinateurs hôtes individuels, sous « Grouping », ajoutez la colonne « Hosts: Hostname » — ce qui garantit une séparation visuelle des ordinateurs hôtes.

Étant donné que la vue ne doit afficher que les ordinateurs hôtes MyHost1 et MyHost2, vous devez, dans la dernière étape, définir un filtre sous Context / Search Filters pour l’Hostname : MyHost1|MyHost2. Pour une vue d’exemple un peu plus claire, vous pouvez également définir un filtre sous Service, par exemple filesystem.*|Check_MK.*. Vous obtenez alors les services du système de fichiers surveillés par SLA, et en contrepartie non surveillée, les services Checkmk – de cette manière, les résultats obtenus en utilisant l’affichage SLA spécifique au service seront tout simplement plus clairs.

La configuration de la vue est terminée. Après sélection dans le menu «Monitor», vous obtiendrez une vue comportant cinq icônes d'état correspondant aux résultats individuels du SLA en pourcentage, ainsi qu'un résumé sous forme de pourcentage pour le SLA d'indisponibilité — bien sûr, uniquement dans les lignes des services du système de fichiers, les lignes Checkmk restant vides.

La vue spécifique au service présente un inconvénient : vous pouvez certes créer plusieurs règles qui attribuent le même service à différents SLA, mais vous ne pouvez afficher que le SLA attribué à la première de ces règles – il n'est pas possible d'afficher le SLA d'une deuxième règle de contrôle dans une deuxième colonne.

Vous pouvez toutefois facilement afficher plusieurs colonnes avec différents SLA fixes et spécifiés. De telles vues spécifiques à une colonne sont utiles, par exemple, si vous avez besoin de plusieurs SLA qui doivent s'appliquer à tous les services de certains ou de tous les ordinateurs hôtes. Il pourrait s’agir, par exemple, de définir des SLA « or », « argent » et « bronze », chacun dans une colonne distincte à côté des services d’un ordinateur hôte. D’un seul coup d’œil, vous verrez alors clairement à quelles définitions de SLA un service ou un ordinateur hôte répond. En résumé : la vue de la table spécifique à une colonne vous permet d’afficher plus d’un seul SLA pour les services.

Dans l’exemple ci-dessus, les trois étapes mentionnées au début ont été exécutées : créer un SLA, le lier à un service, l’intégrer dans une vue. Pour les vues spécifiques à une colonne, vous pouvez simplement omettre la deuxième étape. Créez uniquement le SLA, puis configurez une vue de la table avec la colonne « Hosts/Services: SLA - Column specific ». Les résultats du SLA s’afficheront alors sur chaque ligne, indépendamment du service concerné.

L'image suivante montre la vue de la table SLA ci-dessus pour « MyHost1 » avec une colonne supplémentaire affichant les résultats SLA (trois pannes maximum des services Checkmk) pour chaque service :

La différence entre les affichages spécifiques au service et ceux spécifiques à la colonne est ainsi clairement visible. Ce qui devrait également apparaître clairement : le SLA conçu spécifiquement pour les services Checkmk n’a bien sûr qu’un intérêt limité dans les colonnes du système de fichiers. Il vaut donc la peine de bien planifier cela avant de commencer une mise en œuvre !

Une dernière petite remarque : dans les options des vues spécifiques aux services, ci-dessus sous « Generic plugin display options », nous avons vu les paramètres relatifs aux SLA d’interruption et de pourcentage. Dans les options des vues spécifiques aux colonnes, vous pouvez également voir ces deux éléments — mais uniquement si le SLA inclut effectivement des critères d’interruption et de pourcentage. Ici, le terme « générique » n’est pas approprié ; c’est une définition SLA statique et fixe qui est invoquée. Seules les options appartenant à ce SLA seront visibles.

Il existe de nombreuses façons de combiner les SLA, les services et les vues — une bonne planification est ici nécessaire pour déterminer précisément ce que vous souhaitez afficher via les SLA.

L'intégration des informations SLA dans des tableaux offre un aperçu rapide, mais vous pouvez bien sûr également examiner les résultats en détail. Dans une vue de la table, un clic sur la cellule contenant les données SLA vous amène directement à la page de détail des résultats SLA pour le service concerné :

Vous y trouverez quatre types d'informations différents :

General information : vous pouvez y consulter les données brutes de disponibilité, et donc les calculs du SLA sous forme d'aperçu de l'état pour chaque période, ainsi que, ci-dessous, les résultats agrégés des exigences du SLA.

Viennent ensuite des tableaux pour chaque exigence individuelle du SLA. L’onglet « Timeline » affiche chaque état, tandis que la ligne « Result » présente les résultats pour chaque période de reporting individuelle. Une fonctionnalité particulière : Si, comme décrit dans l’exemple, vous avez défini des niveaux de SLA et que le SLA passe à « CRIT » avant d’être rompu, cela sera indiqué ici par une barre orange et non par la barre rouge habituelle. Les barres deviendront alors rouges lorsque le SLA sera rompu. Une fois que vous avez compris cela, placez le pointeur de la souris sur la barre de résultats où, grâce à une infobulle, vous pourrez voir les événements individuels responsables de l'état. Dans l'image suivante, l'état est « WARN » (En cours) — car il ne reste plus que deux des trois interruptions autorisées :

Le message « SLA broken » (La limite de tolérance est dépassée) apparaîtrait également dans cette infobulle.

Remarque concernant l'utilisation de la vue de la table : Si vous passez la souris sur la barre de résultats « Aggregated results » ou « Result » d'une période, cette période sera mise en surbrillance — tant pour toutes les exigences individuelles que pour le résumé sous « General information ». D'un simple clic, vous pouvez sélectionner ou désélectionner une ou plusieurs périodes.

Enfin, sous SLA specification, vous trouverez les données de configuration de votre SLA, qui vous aideront à mieux évaluer et comprendre les résultats présentés :

Dans l’article sur la disponibilité, vous avez déjà découvert comment utiliser la disponibilité pour les agrégations BI. Les SLA sont également disponibles pour les agrégations — via un petit détour : L’état d’une agrégation BI peut être surveillé via l’agent spécial BI comme un service normal. Cela apparaît alors, par exemple, sous la forme Aggr Disk & Filesystems dans les vues et peut à son tour être associé à un SLA via la règle Assign SLA definition to service déjà utilisée ci-dessus. En conséquence, cela ressemblera à quelque chose comme ceci :

La règle de l'agent spécial se trouve sous Setup > Agents > Other integrations > BI Aggregations, et une description de la règle est disponible dans l'article BI.

L'agent spécial nécessite l'instance concernée et, si nécessaire, ses identifiants de login s'il s'agit d'une instance distante. La configuration principale s'effectue sous Filter aggregations. C'est là que sont spécifiées toutes les agrégations que vous souhaitez inclure en tant que services distincts dans la supervision. Sous By aggregation name (exact match), saisissez le titre de la règle de niveau supérieur d'une agrégation — par exemple Disk & Filesystems (qui est ensuite complétée par Aggr en tant que nouveau service Aggr Disk & Filesystems).

Les noms exacts des règles/agrégations souhaitées se trouvent, par exemple, sous Setup > Business Intelligence > Business Intelligence > Default Pack - Aggregations:

Remarque : il existe un risque de confusion à ce stade : Dans la configuration BI, vous créez l’agrégation BI proprement dite, c’est-à-dire la logique, via des règles — et ces règles sont saisies ici via leurs titres sous la forme Aggregation Name.

En pratique, les SLA résultent de l’interaction de nombreuses configurations différentes : le SLA lui-même, les options d’affichage et de service, les périodes de temps, les règles et, bien sûr, les données de disponibilité. Si le SLA affiche des résultats différents de ceux attendus, il suffit de passer en revue l’ensemble de la chaîne. En cas de doute, il est également utile de visualiser l’ensemble du processus à l’aide d’un stylo et d’une feuille de papier — afin de voir d’un seul coup d’œil toutes les informations concernées. Les points suivants peuvent servir de liste de contrôle de base :

Une fois les configurations checkées, vous pouvez contrôler le fonctionnement du SLA à l'aide de changements d'état manuels (simulés) et de périodes de maintenance planifiées en appliquant des instructions aux objets d'une vue de la table.

Dans ce cas, ouvrez les paramètres de la vue concernée et vérifiez d’abord l’évidence : Existe-t-il seulement une colonne avec un SLA ? Des filtres contradictoires constituent toutefois une cause plus probable : Si vous avez lié le SLA à un service à l’aide d’une règle, ce service ne doit bien sûr pas être exclu des options de la vue sous Context / Search Filters.

Les SLA liés à un service présentent encore une autre source d’erreur : Comme décrit ci-dessus, vous ne pouvez afficher qu’un seul SLA lié à une règle pour chaque service dans une vue de la table — celui de la première règle correspondante. Enfin, la vue reçoit uniquement l’instruction d’afficher dans chaque ligne le SLA associé au service — et non le deuxième ou le cinquième SLA lié. Si vous avez créé des règles correspondantes, celles-ci seront simplement ignorées. Dans de tels cas, vous pouvez passer à l'affichage spécifique par colonne.

Dans sa forme la plus simple, l’état d’un SLA ne change dans les vues de l’interface graphique que lorsque ses exigences ne sont pas respectées. Pour être informé à l’avance d’un changement d’état, vous devez configurer les niveaux de SLA.