Disponibilité

Comme Checkmk surveille en permanence tous les ordinateurs hôtes et services à intervalles de temps réguliers, il offre une base exceptionnelle pour l’évaluation ultérieure de leur disponibilité. Et ce n’est pas tout : il est également possible de calculer pendant quel pourcentage d’une période donnée un objet s’est trouvé dans un ou plusieurs états spécifiques, à quelle fréquence cet état s’est produit, la durée de son arrêt le plus long, et bien plus encore.

Chaque calcul repose sur une sélection d’objets et une période spécifiée dans le passé. Checkmk reconstitue alors, au sein de cette période, une séquence chronologique des états de tous les objets sélectionnés. Pour chaque état, les durées sont additionnées et affichées dans un tableau. Ce tableau peut, par exemple, montrer qu’un service particulier a connu des états de 99,95 % d’OK, et de 0,005 % d’WARN au cours de la période définie.

Lors de ces calculs, Checkmk prend également correctement en compte des facteurs tels que les périodes de maintenance planifiées, les périodes de maintenance des services, les périodes non surveillées et d'autres facteurs particuliers, permet de résumer les états et d'ignorer les « brèves interruptions ». De nombreuses options de personnalisation sont également disponibles. Des agrégations BI sont également possibles.

En raison de la prise en compte des périodes de maintenance planifiées et d’autres états spéciaux similaires, il existe en théorie un grand nombre de combinaisons d’états possibles, par exemple : «CRIT» + «In Period of Maintenance» + «In Service Time» + «Instable». Comme la plupart de ces combinaisons ne sont pas très utiles, Checkmk les réduit à un petit nombre et procède ainsi selon un principe de priorités. Étant donné que, dans l’exemple ci-dessus, le service était en période de maintenance, l’état « in scheduled downtime » s’applique simplement, et l’état réel est ignoré. Cela réduit la liste des états possibles à ce qui suit :

Ce graphique montre l'ordre de priorité des états. Nous verrons plus tard comment certains états peuvent être ignorés ou combinés. Voici à nouveau les états, en détail :

La génération d'une analyse de disponibilité est très simple. Commencez par afficher n'importe quelle vue des ordinateurs hôtes, des services ou des agrégations BI. Vous y trouverez, dans le menu «Services» ou «Hosts», l'élément «Availability», qui vous mènera directement au calcul de la disponibilité des objets sélectionnés. Les données s'afficheront sous forme de tableau :

Le tableau présente les mêmes objets que ceux affichés dans la vue de la table précédente. Chaque colonne indique la proportion de la période demandée pendant laquelle un objet se trouvait dans l’état faisant l’objet de la requête. La valeur est exprimée en pourcentage, par défaut avec deux décimales — ce que vous pouvez également personnaliser facilement.

La requête de période peut être personnalisée à l’aide de l’entrée « Availability > Change display options > Time Range ». Nous y reviendrons plus tard…​

Vous avez la possibilité de recevoir le tableau au format PDF (éditions commerciales uniquement). Il est également possible de télécharger les données au format CSV via (Export as CSV). Voici à quoi cela ressemblera pour l'exemple ci-dessus :

À l’aide d’un utilisateur de l’automatisation, qui peut s’authentifier via l’URL, vous pouvez également récupérer des données — par exemple avec wgetou curl — et traiter automatiquement ces données sous le contrôle d’un script.

Le symbole se trouve sur chaque ligne du tableau. Ce bouton vous permet d’accéder à un affichage chronologique de l’objet concerné, dans lequel sont répertoriés avec précision les éléments d’état survenus au cours de la période spécifiée (résumée ici) :

Quelques conseils utiles :

Comme nous venons de le mentionner, grâce au symbole « », les chronologies offrent la possibilité d’ajouter une annotation à une période de temps. Un formulaire prérempli (« Propriétés ») est fourni, dans lequel vous pouvez saisir des commentaires :

Cela vous permet de définir et d’étendre la période avec différentes valeurs selon vos besoins. Cela s’avère pratique, par exemple, si vous souhaitez annoter une période plus large ayant subi des changements d’état répétés. Si vous omettez de saisir un service, l’annotation sera créée pour l’ordinateur hôte. Elle sera alors automatiquement associée à tous les services de l’ordinateur hôte.

Dans chaque vue de la table, toutes les annotations applicables à la période et aux objets affichés seront automatiquement visibles.

Mais les annotations ont une fonction supplémentaire. Les périodes de maintenance peuvent être saisis rétrospectivement — ou, à l’inverse, supprimées. L’analyse de disponibilité prend en compte ces corrections exactement de la même manière que pour les périodes de maintenance « normales ». Il existe au moins deux justifications légitimes à cela :

Pour reclasser les périodes de maintenance, il suffit de cocher la case à cocher «Reclassify downtime of this period» :

Dans le tableau de disponibilité, à côté du symbole de la chronologie, vous trouverez un autre symbole : « ». Celui-ci vous permet d’accéder à une vue de l’historique de la supervision avec un filtre prérempli pour l’objet concerné et la période de la requête. Vous y verrez non seulement l’événement sur lequel repose l’analyse de disponibilité (les changements d’état), mais aussi les notifications associées et les événements similaires :

Ce qui n’apparaît pas ici, c’est l’état de l’objet au début de la période de temps couverte par la requête. Le calcul de la disponibilité remonte encore plus loin dans le temps afin de déterminer de manière fiable l’état initial.

De nombreuses options influencent le format des affichages, tandis que d’autres influencent les méthodes de calcul. Pour commencer, examinons les affichages :

Les états décrits dans l'introduction peuvent être personnalisés et condensés de très nombreuses façons. De cette manière, des formes d'évaluation très différentes peuvent être générées de manière flexible. Il existe diverses options pour cela.

La supervision génère parfois des messages d’erreur momentanés, mais dans des conditions normales, l’objet est déjà réOKé au moment où le check suivant s’exécute (après une minute) — et aucun moyen n’a été trouvé, par le réglage des valeurs seuils ou autre, pour gérer correctement ces cas. Une solution courante consiste à régler le Maximum number of check attempts entre 1 et 3 afin d’autoriser davantage de défaillances avant qu’une notification ne soit déclenchée. C’est ainsi que le concept d’Soft states a été développé — c’est-à-dire les états WARN, CRIT ou UNKNOWN — tant que toutes les tentatives autorisées n’ont pas été « épuisées ».

Les utilisateurs de cette fonctionnalité nous demandent parfois pourquoi le module de disponibilité de Checkmk ne dispose pas d’une fonction permettant de calculer en utilisant uniquement les états «Hard states». La raison en est simple : il existe une meilleure solution ! On pourrait utiliser les états durs comme base…​

L'option « Short time Intervals » est bien plus flexible et, en même temps, très simple. Il suffit de définir une durée qui doit être dépassée avant que les états ne soient évalués.

Supposons que la valeur temporelle ait été fixée à 2,5 minutes (150 secondes). Si un service a été en état « OK » de manière continue, puis en état « CRIT » pendant 2 minutes, avant de revenir à l’état « OK », le court intervalle « CRIT » sera simplement évalué comme « OK » ! La situation inverse fonctionne d’ailleurs également ! Un court intervalle « OK » au sein d’une longue phase « WARN » sera de même évalué comme « WARN ».

D’une manière générale, les intervalles courts pour lesquels, avant et après, le même état prévaut se verront attribuer ce même état. Pour une séquence deOK , puis unWARN de 2 minutes, suivi deCRIT , l’WARN persistera — même si sa durée était inférieure à la durée définie !

Gardez à l’esprit, lors de la définition de la durée, que dans Checkmk, l’intervalle de vérification standard est d’une minute. Ainsi, chaque état a une durée qui est un multiple d’ environ une minute. Comme les temps de réponse réels de l’agent varient légèrement, cela peut facilement correspondre à 61 ou 59 secondes. Il est donc plus prudent de ne pas saisir de durée exacte en minutes, mais plutôt d’inclure une marge de sécurité — d’où l’exemple de 2,5 minutes.

Une fonction importante des calculs de disponibilité dans les éditions commerciales de Checkmk réside dans le fait que ces calculs peuvent être rendus dépendants de périodes de temps. Cela permet de définir des plages horaires pour chaque ordinateur hôte ou service individuel. Pendant ces plages horaires, l’ordinateur hôte/le service est censé être disponible et l’état correspondant est alors utilisé pour les calculs. C’est pourquoi chaque objet dispose de l’attribut « Service period ». La procédure est la suivante :

Il existe ici trois possibilités simples. L’ Base report only on service timespar défaut masque les heures situées en dehors des heures de service définies. Ces heures masquées ne sont alors pas prises en compte dans le calcul des 100 %. Seules les périodes comprises dans les heures de service seront effectivement prises en compte. Dans l’affichage de la chronologie, les heures restantes seront « grisées ».

Base report only on non-service times effectue l’inverse, et calcule en fait l’affichage inverse : quelle était la disponibilité en dehors des heures de service ?

La troisième option, Include both service and non-service times, désactive le concept des heures de service et affiche les calculs pour toutes les heures comprises entre le lundi 00h00 et le dimanche 24h00.

À propos : si un ordinateur hôte n’est pas dans la période de service, cela ne signifie pas automatiquement pour Checkmk que cela s’applique également aux services sur cet ordinateur hôte. Les services nécessitent toujours leur propre règle dans « Service period for services ».

Lors du calcul de la disponibilité, l’historique complet de l’objet sélectionné doit être rouvert. Vous trouverez plus bas des informations détaillées sur le fonctionnement de ce processus. En particulier dans l’e Checkmk Community, l’analyse peut prendre un certain temps, car son noyau ne dispose pas de cache pour les données requises et les données de journalisation textuelles doivent être recherchées de manière séquentielle.

Afin qu’une requête excessivement complexe — qui aurait pu être lancée par inadvertance — ne bloque pas un processus Apache, ne consomme pas de CPU et ne provoque ainsi de « blocage », deux options permettent de limiter la durée du calcul. Les deux sont activées par défaut :

L'option « Query time limit » limite la durée de la requête sous-jacente vers le noyau de supervision à un temps spécifié. Ce temps est prédéfini à trente secondes. Si ce délai est dépassé, l'analyse sera interrompue et une erreur sera signalée. Si vous êtes certain que l'analyse peut s'exécuter plus longtemps, il vous suffit d'augmenter manuellement le timeout.

L'option « Limit processed data » protège contre les calculs portant sur un grand nombre d'objets. Une limite sera alors appliquée, fonctionnant de manière analogue à celle des vues de la table. Si la requête adressée au noyau de supervision produit plus de 5 000 périodes de temps, le calcul sera interrompu et un avertissement s'affichera. La limitation aura été prétraitée dans le noyau du processeur — là où les données sont collectées.

Une fonctionnalité puissante du calcul de disponibilité de Checkmk réside dans la possibilité de calculer la disponibilité à partir des agrégations BI. Le principal attrait réside ici dans le fait que, à cette fin, Checkmk reconstitue rétroactivement l’état précis des agrégations concernées à un moment donné en utilisant les protocoles relatifs aux états des ordinateurs hôtes et des services individuels.

Pourquoi tant de temps et d’efforts ? Pourquoi ne pas simplement interroger l’agrégation BI avec un check actif, puis afficher sa disponibilité ? Eh bien, cet effort présente de nombreux avantages pour l’utilisateur :

La récupération de la vue de disponibilité est initialement analogue à celle des ordinateurs hôtes et des services. Sélectionnez une vue comportant une ou plusieurs agrégations BI, puis sélectionnez l’entrée « BI Aggregations > Availability » du menu. Il existe également une deuxième méthode : chaque agrégation BI dispose d’un chemin d’accès direct vers sa disponibilité via le symbole « » :

En soi, le calcul est initialement similaire à celui des services, mais sans les colonnes « Host down » et « flapping », car ces états n'existent pas pour la BI :

La grande différence réside dans la vue chronologique de l’. L’exemple suivant montre un agrégat sur notre serveur de démonstration, qui était en état « CRIT » pendant un intervalle de temps très bref d’une seconde (ce serait un bon exemple pour l’ utilisation de l’option « Short time intervals »).

Souhaitez-vous connaître la cause de la panne ? Il suffit d’un simple clic sur la baguette magique . Cela permet un voyage dans le temps jusqu’au moment précis où la panne s’est produite, et ouvre un affichage de l’agrégation BI à ce moment-là — dans l’image suivante, déjà ouverte à l’emplacement correct :

Pour calculer la disponibilité, Checkmk accède aux journaux d'historique de supervision archivés et, pour ce faire, se base sur les changements d'état. Si, par exemple, le 20/10/2021 à 17 h 14, un service passe à l'état « CRIT », puis revient à l'état « OK » à 17 h 24, vous savez alors que pendant cette période de temps de 10 minutes, le service était dans un état « CRIT ».

Ces changements d'état sont enregistrés dans le journal de supervision, ont pour type d'alerte « HOST ALERT» ou « SERVICE ALERT », et se présentent par exemple comme suit :

Il existe toujours un fichier journal actuel qui contient les entrées relatives à l’activité la plus récente jusqu’au moment présent, ainsi qu’un répertoire contenant une archive des périodes précédentes. L’emplacement de ces fichiers varie en fonction du noyau de supervision utilisé :

L'interface utilisateur n'accède pas directement à ces fichiers, mais les interroge à l'aide d'une requête Livestatus émise depuis le noyau de supervision. Cela est important, entre autres, car dans une supervision distribuée, les fichiers d'historique ne sont pas stockés sur le même système que l'interface graphique.

La requête Livestatus utilise la table statehist. Contrairement à la table log – qui fournit un accès « brut » à l’historique – la table statehist est ici utilisée car elle a déjà effectué les étapes de calcul initiales, qui prennent beaucoup de temps. Elle se charge notamment de remonter dans l’historique pour déterminer l’état initial, ainsi que du calcul des périodes de temps présentant le même état, avec leurs dates de début, leurs durées et leurs dates de fin.

La procédure de condensation des états est effectuée dans l’aperçu de l’utilisateur par le module de disponibilité, comme décrit au début de cet article.