Principes de base de la supervision avec Checkmk

Tout dans Checkmk s’articule autour des ordinateurs hôtes et des services. Un ordinateur hôte peut désigner plusieurs choses, par exemple :

Lors de la supervision, un ordinateur hôte se trouve toujours dans l'un des états suivants :

Outre l'état, un ordinateur hôte possède un certain nombre d'autres attributs pouvant être configurés par l'utilisateur, par exemple :

Pour que la supervision puisse déterminer l'état d'UNREACH, elle doit connaître le chemin d'accès qu'elle peut emprunter pour contacter chaque ordinateur hôte individuellement. À cette fin, un ou plusieurs hôtes dits « parents » peuvent être spécifiés pour chaque hôte. Par exemple, si un serveur A, tel qu’il est vu par la supervision, n’est accessible que via un routeur B, alors B est un hôte parent de A. Seuls les parents directs sont configurés dans Checkmk. Il en résulte alors une structure arborescente avec l’instance Checkmk au centre (illustrée ici sous la forme ) :

Supposons que, dans l’exemple de topologie de réseau présenté ci-dessus, les ordinateurs hôtes myhost et myhost4 ne soient plus accessibles. La défaillance de myhost4 s’explique par le fait que myhost est en panne. Par conséquent, myhost4 est classé comme « UNREACH » dans la supervision. Il n’est tout simplement pas possible de déterminer clairement pourquoi Checkmk ne peut plus atteindre myhost4, et l’état « DOWN » serait donc trompeur dans certaines circonstances. Au lieu de cela, l’« UNREACH » a pour effet de supprimer les notifications par défaut. C’est après tout la tâche la plus importante du concept de parents, à savoir éviter les notifications en masse dans le cas où un segment de réseau dépendant entier deviendrait inaccessible à la supervision en raison d’une interruption en un seul point.

La prévention des fausses alertes est également assurée par une fonctionnalité du Checkmk Micro Core (CMC) utilisée dans les éditions commerciales. Ici, le changement d’état d’un ordinateur hôte défaillant est retardé de quelques instants et n’est effectué que lorsqu’il est certain que le parent est toujours joignable. Si, en revanche, le parent est définitivement inDOWN, l’ordinateur hôte passe à l’état « UNREACH » — sans qu’une notification ne soit déclenchée.

Dans certains cas, un ordinateur hôte peut avoir plusieurs parents, par exemple lorsqu’un routeur fonctionne en haute disponibilité au sein d’un cluster. Il suffit que Checkmk puisse déterminer de manière univoque l’état de l’ordinateur hôte dès lors que l’un de ces parents est joignable. Ainsi, lorsqu’un ordinateur hôte a plusieurs parents et qu’au moins l’un d’entre eux est UP, l’ordinateur hôte est considéré comme joignable dans la supervision. En d’autres termes, dans une telle situation, l’ordinateur hôte ne passera pas automatiquement à l’état UNREACH.

Un ordinateur hôte dispose d’un certain nombre de services. Un service peut être n’importe quoi — ne confondez pas cela avec les services sous Windows. Un service est toute partie ou tout aspect de l’ordinateur hôte qui peut être « OK » (en état de fonctionnement) ou « not OK » (en état de dysfonctionnement). Naturellement, l’état ne peut être déterminé que si l’ordinateur hôte est en état « UP ».

Un service sous supervision peut présenter les états suivants :

Pour déterminer quelle condition est la « pire », Checkmk utilise la séquence suivante :

OK → WARN → UNKNOWN → CRIT

Un check permet de s'assurer qu'un état peut être attribué à un ordinateur hôte ou à un service. Les états possibles sont décrits dans la section précédente. Les services et les checks sont étroitement liés. C'est pourquoi ces termes sont parfois utilisés de manière interchangeable, peut-être même dans ce guide de l'utilisateur, bien qu'il s'agisse en réalité de concepts différents.

Dans la configuration, vous pouvez afficher quel plugin de supervision est responsable de chaque service. Ouvrez les propriétés d’un ordinateur hôte avec « Setup > Hosts », puis, dans le menu « Host > Run service discovery », la liste des services pour cet ordinateur hôte. Utilisez ensuite « Display > Show plugin names » pour afficher une nouvelle colonne qui indiquera le plugin de supervision responsable de chaque service :

Comme vous pouvez le voir dans l'exemple du plugin de supervision df, un plugin de supervision peut être responsable de plusieurs services. À ce propos, les noms des plugins de supervision répertoriés dans la colonne sont également des liens qui affichent une description du plugin de supervision.

La connexion et la dépendance entre les services et les contrôles sont également visibles dans la supervision. Dans la liste des services d’un ordinateur hôte en supervision, vous pouvez constater que dans le menu d’action « » (Contrôle de l’ordinateur hôte), à l’entrée « Reschedule » (Contrôle de l’ordinateur hôte), une flèche jaune apparaît pour certains services (), tandis qu’une flèche grise s’affiche pour la plupart des autres (). Un service accompagné d’une flèche jaune repose sur un contrôle actif :

Une telle vérification active est exécutée directement par Checkmk. Les services accompagnés d’une flèche grise reposent sur des vérifications passives dont les données sont récupérées à partir d’un autre service, le service « Check_MK ». Cette approche est adoptée pour des raisons de performances et constitue une fonctionnalité spécifique de Checkmk.

Checkmk identifie comme un problème tout ordinateur hôte qui n'est pas UP et tout service qui n'est pas OK. Un problème peut présenter deux états : non traité et traité. La procédure veut qu'un nouveau problème soit d'abord considéré comme non traité. Dès que quelqu'un accuse réception d’un incident, celui-ci est marqué comme traité ; sans surprise, les problèmes non traités sont ceux qui n'ont pas encore fait l'objet d'une intervention. L'aperçu dans la barre latérale distingue donc ces deux types de problèmes :

À noter : les problèmes de service provenant d'ordinateurs hôtes qui ne sont actuellement pas UP ne sont pas identifiés comme des problèmes.

Vous trouverez plus de détails sur les confirmations dans l’article qui leur est consacré.

Lorsqu’un ordinateur hôte change d’état (par exemple, passant de « OK » à « CRIT »), Checkmk enregistre un événement de supervision. Ces événements peuvent ou non générer une notification. Checkmk est conçu de telle sorte que, dès qu’un ordinateur hôte ou un service rencontre un problème, un courrier électronique est envoyé aux contacts de l’objet (notez que tout utilisateur nouvellement créé n’est, par défaut, contact pour aucun objet). Ces paramètres peuvent toutefois être personnalisés de manière très flexible. Les notifications dépendent également d’un certain nombre de paramètres. Le plus simple est d’examiner les cas dans lesquels aucune notification n’est envoyée. Les notifications sont désactivées …​

Si aucune de ces conditions préalables à la suppression des notifications n’est remplie, le noyau de supervision crée alors une notification, qui, dans un deuxième temps, passe par une chaîne de règles. Dans ces règles, vous pouvez définir des critères d’exclusion supplémentaires et décider qui doit être notifié et sous quelle forme (courrier électronique, SMS, etc.)

Tous les détails concernant les notifications sont disponibles dans l'article dédié aux notifications.

Il arrive parfois qu’un service change continuellement et rapidement de condition. Afin d’éviter des notifications incessantes, Checkmk place un tel service en état instable. Ceci est illustré par l’icône « ».

Lorsqu’un service passe en état instable, une notification est générée pour informer l’utilisateur de la situation et désactiver les notifications suivantes. Après un délai approprié, si aucun autre changement rapide ne se produit et qu’un état final (bon ou mauvais) est évident, l’état instable disparaît et les notifications normales reprennent.

Si vous effectuez des travaux de maintenance sur un serveur, un périphérique ou un logiciel, vous souhaiterez normalement éviter les notifications de problèmes pendant cette période. De plus, vous souhaiterez probablement informer vos collègues que les problèmes apparaissant dans la supervision pendant cette période peuvent être temporairement ignorés.

À cette fin, vous pouvez définir une condition de période de maintenance planifiée sur un ordinateur hôte ou un service. Cela peut être fait juste avant de commencer les travaux, ou à l’avance. Les périodes de maintenance planifiées sont illustrées par les icônes suivantes :

Pendant qu'un ordinateur hôte ou un service est en période de maintenance planifiée :

De plus, si vous souhaitez documenter ultérieurement les statistiques relatives à la disponibilité des ordinateurs hôtes et des services, il est recommandé d'inclure les périodes de maintenance planifiées. Celles-ci peuvent être prises en compte dans les évaluations de disponibilité ultérieures.

Si vous utilisez Checkmk depuis un certain temps, il est possible que des toiles d’araignée s’affichent dans vos vues d’ordinateurs hôtes et de services. Pour les services, par exemple, cela se présente ainsi :

Ces toiles d’araignée symbolisent l’état obsolète. Chaque fois qu’il y a un ordinateur hôte ou un service obsolète, cela s’affiche également dans le snap-in « Overview », qui sera complété par la colonne « Stale ».

Mais que signifie exactement l’état obsolète ? En général, un ordinateur hôte ou un service est marqué comme obsolète lorsque Checkmk ne reçoit plus d’informations à jour sur son état pendant une période prolongée :

Vous pouvez ajuster le délai au-delà duquel les ordinateurs hôtes et les services deviennent obsolètes. Pour cela, consultez la section consacrée aux intervalles de temps.

Vous pouvez limiter les périodes de temps pendant lesquelles les vérifications sont exécutées. Les jeux de règles Check period for hosts, Check period for active services et Check period for passive Checkmk services servent à cet effet. Utilisez ces règles pour sélectionner l'une des périodes de temps disponibles comme période de check.

Les vérifications sont exécutées à intervalles fixes dans le cadre de la supervision basée sur l'état. Checkmk utilise par défaut une intervalle d'une minute pour les vérifications de service et de 6 secondes pour les vérifications d'ordinateur hôte avec un Smart Ping.

Ces valeurs par défaut peuvent être modifiées à l'aide des jeux de règles « Normal check interval for service checks » et « Normal check interval for host checks » :

Si vous combinez désormais une période de check avec un intervalle de vérification, vous pouvez vous assurer qu’une vérification active est exécutée précisément une fois par jour à une heure très précise. Par exemple, si vous définissez l’intervalle de vérification sur 24 heures et la période de check sur 2 h 00 à 2 h 01 tous les jours (c’est-à-dire une seule minute par jour), Checkmk veillera à ce que la vérification soit effectivement déplacée vers cette courte fenêtre temporelle.

L'état des services ne sera plus mis à jour en dehors de cette période de check définie et les services seront marqués comme obsolètes à l'aide de l'icône «». Grâce au paramètre global «Staleness value to mark hosts / services stale», vous pouvez définir le délai avant qu'un ordinateur hôte/service ne soit considéré comme obsolète. Ce paramètre se trouve sous «Setup > General > Global settings > User interface:»

Ce facteur représente n fois l'intervalle de vérification. Ainsi, si votre intervalle de vérification est défini sur une minute (60 secondes), un service pour lequel il n'y a pas de nouveaux résultats de vérification sera considéré comme obsolète après 1,5 fois ce délai, c'est-à-dire après 90 secondes.

Grâce à l'option « tentatives de vérification », vous pouvez éviter les notifications en cas d'erreurs sporadiques. Cela rend la vérification moins sensible, pour ainsi dire. Vous pouvez utiliser les jeux de règles Maximum number of check attempts for host et Maximum number of check attempts for service à cette fin.

Si le nombre de checks est défini sur 3, par exemple, et que le service correspondant passe à l’état « CRIT », aucune notification n’est initialement déclenchée. Ce n’est que si les deux checks suivants donnent également un résultat autre que « OK » que le compteur de checks actuels passera à 3 et que la notification sera envoyée.

Un service qui se trouve dans cet état intermédiaire — c'est-à-dire qui n'est pas en état « OK » mais qui n'a pas encore atteint le nombre maximal de tentatives de check — sera considéré comme étant en soft state. Seul un état dur déclenchera effectivement une notification.