 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduction
Les services constituent la « substance » même d’un système de supervision. Chacun d’entre eux représente un rouage essentiel de votre environnement informatique complexe. L’efficacité de la supervision dans son ensemble dépend entièrement de la précision et de la pertinence avec lesquelles les services ont été configurés. Enfin, la supervision doit signaler de manière fiable tout problème détecté, mais doit également réduire au minimum les notifications erronées ou inutiles.
C’est peut-être dans la configuration des services que Checkmk démontre sa plus grande force : il dispose d’un système inégalé et très puissant pour la détection et la configuration automatiques des services. Avec Checkmk, il n’est pas nécessaire de définir chaque service individuellement via des modèles et des affectations individuelles. Checkmk est capable de détecter automatiquement et de manière fiable la liste des services à surveiller, et surtout, de la maintenir à jour. Cela permet non seulement de gagner beaucoup de temps, mais rend également la supervision précise. Cela garantit que les changements quotidiens dans un centre de données sont toujours pris en compte rapidement et qu’aucun service important n’échappe à la supervision.
La reconnaissance du service dans Checkmk repose sur un principe fondamental : la séparation entre « quoi » et « comment » :
Que faut-il surveiller ? → Le système
/varsur l’ordinateur hôtemyserver01Comment cela doit-il être supervisé ? → à 90 % d’espace utilisé WARN , à 95 % CRIT
Ce qui
est automatiquement détecté par la reconnaissance du service. Il s’agit d’
une combinaison du nom
de domaine
(myserver01
), du plugin de supervision
(donnéesdf:
de supervision du système sous Linux) et de l’élément
(/var
). Les plugins de supervision pouvant créer au maximum un service sur un
ordinateur hôte ne nécessitent pas d’élément (par exemple, le plugin de supervision de l’utilisation du processeur). Les
résultats d’une reconnaissance du service sont présentés dans un tableau comme indiqué ci-dessous :
| Ordinateur hôte | Plugin de supervision | Élément |
|---|---|---|
|
|
|
|
|
|
|
|
|
… |
… |
… |
|
|
|
… |
… |
… |
La manière de procéder — c'est-à-dire les valeurs seuils/paramètres de contrôle pour chaque
service — est configurée indépendamment via des règles. Vous pouvez
par exemple définir une règle qui effectue la supervision de tous les systèmes de données avec le point de montage /var ,
et les valeurs seuils de 90 % / 95 %, sans avoir à vous demander sur
quels ordinateurs hôtes un tel système de données existe. C'est ce qui rend la configuration
avec Checkmk si claire et simple !
Quelques services ne peuvent pas être installés à l’aide d’une identification automatique. Parmi ceux-ci figurent, par exemple, les checks interrogés via des sites web spécifiés par HTTP. Ceux-ci sont créés via des règles, comme vous pouvez le découvrir dans l’article consacré aux checks actifs.
La liste des possibilités offertes par Checkmk pour la supervision de lui-même est présentée dans l'article « Surveillance de votre propre système ».
2. Services d’ordinateur hôte dans la configuration
2.1. Ajout d'un nouvel ordinateur hôte
Une fois que vous avez ajouté un nouvel ordinateur hôte dans la configuration, l'étape suivante consiste à afficher la liste des services. Cette action déclenche la reconnaissance automatique du service pour la première fois pour cet ordinateur hôte, et l'accessibilité des sources de données est vérifiée en parallèle. Vous pouvez également afficher cette liste à tout moment par la suite afin de relancer la reconnaissance ou d'apporter des modifications à la configuration. Il existe plusieurs façons d'ouvrir la liste des services :
via le bouton «
» (Gérer les services) Save & run service discovery dans l’Properties of host (Configuration)dans les menus de l'Properties of host via Host > Run service discovery
via l'icône
dans la liste des ordinateurs hôtes d'un dossier dans la Configurationvia l'entrée
Run service discovery dans le menu d'action de l'Check_MK Discovery du service d'un ordinateur hôte
Lorsqu’un ordinateur hôte vient d’être intégré, ses services n’ont pas encore été configurés ; par conséquent, tous les services détectés apparaissent dans la catégorie « Undecided services - currently not monitored » :
La méthode habituelle pour ajouter les services nouvellement détectés consiste simplement à cliquer sur le bouton « 
» (Ajouter les services manquants).
De cette manière, toutes les étiquettes d’hôte seront également ajoutées en une seule fois.
Ensuite, cliquez rapidement sur « Activate changes » (Configurer l’hôte) ; l’hôte sera alors en supervision.
2.2. Ajouter des services manquants
Pour un ordinateur hôte déjà sous supervision, cette liste se présente différemment. Au lieu de « Undecided services - currently not monitored », vous verrez « Monitored services ». Si Checkmk détecte sur un ordinateur hôte un élément qui n’est pas sous supervision, mais qui devrait l’être, la liste ressemblera alors à ceci :
Un clic sur 
Monitor undecided services ou sur Accept all ajoute simplement tous les services manquants afin que la supervision soit à nouveau complète.
Si vous souhaitez ajouter uniquement certains des services manquants, vous pouvez également cliquer sur le bouton afin de Move to monitored services.
2.3. Services disparus
Dans les centres de données, les éléments peuvent non seulement apparaître, mais aussi disparaître. Une instance de base de données peut être supprimée, un LUN démonté, un système de fichiers supprimé, etc. Checkmk reconnaît automatiquement ces services comme ayant disparu. Dans la liste des services, par exemple, cela se présentera ainsi :
La manière la plus simple de se débarrasser de ces services consiste à nouveau à cliquer sur « » (Accept all) ou à cliquer sur le bouton « 
» (Supprimer le service) dans chaque ligne individuelle,
ce qui signifie « Remove vanished services » (Supprimer le service).
Attention : la raison de la disparition peut bien sûr être due à un problème !
La disparition d’un système de fichiers peut également signifier qu’en raison d’une erreur, il n’a pas pu être monté.
Après tout, la supervision est là pour de tels cas !
Vous ne devriez supprimer le service que lorsque vous savez vraiment qu’il n’a plus besoin d’être surveillé.
2.4. Suppression des services indésirables
Vous ne souhaiterez pas nécessairement effectuer la supervision de tout ce que Checkmk détecte. L’identification fonctionne bien sûr de manière ciblée et peut exclure à l’avance de nombreuses données inutiles. Néanmoins, comment Checkmk peut-il savoir, par exemple, qu’ une instance de base de données particulière a été configurée uniquement « pour s’amuser », et n’est pas en production ? Il existe deux façons d’éliminer de tels services :
Désactivation temporaire des services
Pour retirer temporairement certains services de la supervision, il vous suffit de cliquer sur l’icône « 
».
Le service sera ainsi déplacé vers la liste des « Undecided services ».
Vous pouvez également cliquer sur l’icône « 
» au début de la ligne afin de désactiver le service.
Et bien sûr, n’oubliez pas l’Activate changes habituelle.
Cette méthode n’est toutefois destinée qu’à des actions temporaires et de moindre envergure, car les services désélectionnés de cette manière seront signalés par Checkmk comme « missing », et le contrôle d’identification (que nous vous montrerons plus loin) affichera également un résultat négatif. Quoi qu’il en soit, cela représenterait tout simplement trop de travail et ne serait pas vraiment pratique dans un environnement comptant des milliers de services…
Désactivation permanente des services
Il est bien plus élégant et durable d’ignorer définitivement des services à l’aide du jeu de règles « Disabled services ». Ici, vous pouvez non seulement exclure des services individuels de la supervision, mais aussi formuler des règles telles que « Je ne souhaite pas superviser les services commençant par myservice sur l’ordinateur hôte myserver01."
Vous pouvez accéder à la règle via Setup > Services > Discovery rules > Discovery and Checkmk settings > Disabled Services.
Une fois les règles enregistrées, lorsque vous revenez à la liste des services de l’ordinateur hôte, vous verrez les services désactivés dans la section « Disabled Services », ainsi que tout service qui aurait pu être désactivé manuellement.
2.5. Actualisation des services
Il existe un certain nombre de plugins qui détectent des éléments lors d’une identification. Par exemple, le plugin de supervision pour les interfaces réseau checke la vitesse définie sur l’ interface lors de l’identification. Pourquoi ? Afin de pouvoir vous avertir au cas où elle changerait ! Ce n’est généralement pas bon signe lorsqu’une interface est parfois réglée sur 10 Mbit/s et parfois sur 1 Gbit/s — cela pourrait plutôt indiquer une auto-négociation défectueuse.
Que se passe-t-il lorsque ce changement est souhaité et doit être accepté comme OK à
partir de maintenant ?
Soit — supprimez le service via l’icône « », qui
signifie « Move to undecided services », puis rajoutez-le immédiatement
après.
Soit actualisez tous les services de l’ordinateur hôte en cliquant sur « Actions > Remove all
and find new » dans les menus. C’est naturellement beaucoup plus simple, mais uniquement si vous
ne souhaitez pas maintenir des services individuels dans un état d’erreur.
2.6. Mise à jour des étiquettes d'hôte et de service
La mise à jour des étiquettes uniquement peut être facilement effectuée via Actions > Host labels > Update host labels et Actions > Services > Update service labels respectivement dans les menus.
S’il est uniquement nécessaire d’ajouter ou de mettre à jour des étiquettes de service individuelles (nouvelles), cela peut être fait dans la ligne du service concerné dans la case Changed services en cliquant sur 
.
2.7. Conditions particulières avec SNMP
Il existe quelques particularités pour les périphériques SNMP sous supervision. Vous pouvez en savoir plus à ce sujet dans l'article consacré au SNMP.
3. Identification groupée — identification simultanée sur plusieurs ordinateurs hôtes
Si vous souhaitez effectuer une identification sur plusieurs ordinateurs hôtes en une seule opération, vous pouvez vous faciliter la tâche grâce aux actions Bulk de Checkmk. Commencez par sélectionner les ordinateurs hôtes sur lesquels l’identification doit être effectuée. Plusieurs options s’offrent à vous :
Dans un dossier, cochez les cases correspondant aux ordinateurs hôtes individuels, puis sélectionnez « Hosts > On selected hosts > Run bulk service discovery» dans les menus.
Recherchez des ordinateurs hôtes à l’aide de la fonction de recherche d’ordinateurs hôtes, sélectionnez tous les ordinateurs hôtes dans les résultats de recherche en cliquant sur «
», puis à nouveau
via «Hosts > On selected hosts > Run bulk service discovery» dans les menus.Dans un dossier, cliquez sur « Hosts > In this folder > Run bulk service discovery » dans les menus.
Avec la troisième variante, vous pouvez également effectuer la reconnaissance du service de manière récursive dans tous les sous-dossiers. Dans les trois options ci-dessus, l'étape suivante vous mènera au dialogue suivant :
Dans le menu déroulant « Parameters », l’option « Custom service configuration update » est présélectionnée. Les quatre cases à cocher ci-dessous offrent exactement les mêmes options que celles disponibles dans la liste des services de la configuration et que nous avons déjà expliquées ci-dessus. Dans le menu déroulant, vous avez également la possibilité de sélectionner « Refresh all services (tabula rasa) ».
Sous «Selection», vous pouvez à nouveau contrôler la sélection des ordinateurs hôtes. Cela s’avère particulièrement utile si vous les avez sélectionnés via le dossier plutôt que via les cases à cocher. La plupart des options visent à accélérer l’identification :
Include all subfolders |
Si vous avez lancé l'identification groupée pour tous les ordinateurs hôtes d'un dossier, cette option sera activée par défaut. L'identification sera également effectuée sur tous les ordinateurs hôtes de tous les sous-dossiers. |
Only include hosts that failed on previous discovery |
Les ordinateurs hôtes pour lesquels une reconnaissance du service antérieure via des actions Bulk a échoué (par exemple parce que l'ordinateur hôte n'était pas accessible à ce moment-là) sont signalés par le symbole « |
Only include hosts with a failed discovery check |
Cela limite l’identification aux ordinateurs hôtes pour lesquels la vérification d’identification a échoué. Lorsque vous travaillez avec la vérification d’identification, c’est une bonne méthode pour accélérer considérablement l’identification sur de nombreux ordinateurs hôtes. La combinaison avec l’option « Refresh all services (tabula rasa) » (Réessayer) n’a toutefois pas beaucoup de sens dans ce cas, car elle peut fausser l’état des services existants. |
Exclude hosts where the agent is unreachable |
Les ordinateurs hôtes inaccessibles entraînent de longs délais lors de l’identification en raison des timeouts de connexion. Cela peut considérablement nuire aux performances de l’identification sur un grand nombre d’ordinateurs hôtes. Si les ordinateurs hôtes sont déjà sous supervision — et que le système sait qu’ils sont en cours d’identification —, vous pouvez les ignorer ici et ainsi éviter les timeouts. |
Les Performance Options sont prédéfinis de manière à ce qu’une full service scan soit effectuée. Si vous n’êtes pas intéressé par de nouveaux plugins, l’identification peut être considérablement accélérée en ne choisissant pas cette option.
Le nombre de 10 défini dans la détection signifie que
dix ordinateurs hôtes sont toujours traités en une seule opération. Ceci est réalisé en interne
à l’aide d’une requête HTTP. Si vous rencontrez des problèmes de timeout dus au fait que certains ordinateurs hôtes
nécessitent beaucoup de temps pour être détectés, vous pouvez essayer de réduire ce nombre
(au détriment du temps total requis).
Dès que vous aurez confirmé le dialogue, la procédure démarrera et vous pourrez suivre sa progression :
4. Vérification des paramètres de contrôle dans les services
De nombreux plugins de supervision peuvent être configurés à l'aide de paramètres. La pratique la plus courante consiste à définir des valeurs seuils pour WARN et CRIT. Les paramètres peuvent être structurés de manière beaucoup plus complexe, comme le montre cet exemple de supervision de la température avec Checkmk :
Le paramètre de contrôle d'un service se compose de trois parties :
Chaque plugin dispose d’une valeur par défaut pour le paramètre.
Certains plugins définissent des valeurs lors d’une identification (voir ci-dessus).
Les paramètres peuvent être définis via des règles.
Les paramètres issus des règles ont priorité sur ceux définis par une identification, et ceux-ci ont à leur tour priorité sur les valeurs par défaut. Pour les paramètres complexes dans lesquels les sous-paramètres individuels sont définis à l’aide de cases à cocher (comme pour la température par exemple), ces règles de priorité s’appliquent séparément pour chaque sous-paramètre. Ainsi, si vous définissez un seul sous-paramètre via des règles, les autres conservent leurs valeurs par défaut respectives. De cette manière, vous pouvez, par exemple, activer le calcul de la tendance des températures avec une règle, et définir avec un jeu de règles la valeur seuil de température pour un capteur physique. L'ensemble complet des paramètres sera alors constitué à partir des deux règles.
Les paramètres exacts dont dispose un service se trouvent sur la page des paramètres
du service. Vous pouvez y accéder via l’icône «
» dans la liste des services de l’ordinateur hôte. Si vous souhaitez voir les paramètres
de tous les services directement dans le tableau des services, vous pouvez les afficher en cliquant sur «
Display > Details > Show check parameters
» dans les menus. Cela
ressemblera à ceci :
5. Personnalisation de la reconnaissance du service
Nous avons précédemment montré comment configurer la reconnaissance du service afin de masquer l'affichage des services indésirables. Il existe en outre d'autres jeux de règles pour un certain nombre de plugins qui influencent le comportement de la reconnaissance avec ces plugins. Non seulement il existe des paramètres permettant d'omettre des éléments, mais il en existe également qui recherchent activement des éléments ou les regroupent. La dénomination des éléments pose parfois également problème — par exemple pour ces ports de commutateur interfaces réseau où vous pouvez choisir une description ou un alias à utiliser comme élément (qui sera utilisé dans le nom du service) à la place de son identifiant d’interface.
Tous les jeux de règles pertinents pour la reconnaissance du service se trouvent sous Setup > Services > Discovery rules. Veuillez ne pas confondre ces jeux de règles avec ceux destinés à la paramétrisation des services proprement dits. Un certain nombre de plugins disposent en effet de deux jeux de règles — un pour l’identification et un pour les paramètres. Voici quelques exemples.
5.1. Supervision des processus
Il serait peu judicieux pour Checkmk de simplement définir un service pour surveiller chaque processus détecté sur un ordinateur hôte. La plupart des processus ne présentent aucun intérêt ou ne sont présents que temporairement. Il y a au minimum des centaines de processus en cours d’exécution sur un serveur Linux classique.
Pour la supervision des services, vous devez donc travailler avec des services imposés ou ― et c’est beaucoup plus élégant ― en utilisant l’ensemble de règles « Process discovery » pour indiquer à la reconnaissance du service quels processus elle doit rechercher. De cette manière, vous pouvez toujours permettre la mise en place automatique de la supervision lorsqu’un processus manifestement intéressant est détecté sur un ordinateur hôte.
L'image suivante montre une règle du jeu de règles «Process discovery
» qui
recherche les processus exécutant le programme/usr/sbin/apache2
.
Dans cet exemple, un service (Grab user from found processes
) sera
créé pour chaque utilisateur du système d'exploitation pour lequel un tel processus
est détecté. Le service sera nomméApache %u
, où%u
sera remplacé par le nom d'utilisateur. Pour la valeur seuil, le nombre d'instances du processus
sera défini respectivement sur 1/1 (minimum) et 30/60 (maximum) :
Veuillez noter que les valeurs seuils prédéfinies sont appelées « Default parameters for detected services». Vous pouvez les attribuer — ainsi que tous les autres services — via des règles. Pour rappel : les règles ci-dessus configurent la reconnaissance du service — le « quoi ». Si les services sont présents pour la première fois, la chaîne de règles « State and count of processes » est responsable des valeurs seuils.
Le fait de pouvoir définir des valeurs seuils lors d’une identification est un gain de confort. Il y a toutefois un bémol : les modifications apportées à la règle d’identification ne prennent effet qu’à l’identification suivante. Si vous modifiez les valeurs seuils, vous devrez lancer une nouvelle identification. Si, en revanche, vous utilisez uniquement la règle pour découvrir les services (le « quoi ») et que la règle définit l’ State and count of processespour le « comment », vous ne rencontrerez pas ce problème.
Pour superviser certains processus ou un processus unique sur un ordinateur hôte Windows, il vous suffit d’
indiquer le nom du fichier (extension comprise) sans chemin d'accès dans le champ «
Executable». Vous trouverez tous ces noms dans l’onglet « Détails » du
Gestionnaire des tâches de Windows, par exemple. Dans l’Process discovery de la règle, cela pourrait ressembler à
ceci pour le processus « svchost » :
Vous trouverez de plus amples informations sur l'identification des processus dans l'aide en ligne de cet ensemble de règles. Comme toujours, vous pouvez y accéder via « Help > Show inline help » dans les menus.
5.2. Supervision des services sous Windows
L'identification et la paramétrisation de la supervision des services Windows sont analogues à celles des processus et sont contrôlées respectivement via les jeux de règles Windows service discovery(quoi) et Windows services (comment) . Voici un exemple de règle qui surveille deux services :
Tout comme pour les processus, la reconnaissance du service n’est ici qu’ une option parmi d’autres. Si, sur la base des caractéristiques de l’ordinateur hôte et des dossiers, vous pouvez formuler des règles précises pour les ordinateurs hôtes sur lesquels des services spécifiques sont attendus, vous pouvez également travailler avec des services imposés. Cela est indépendant de la situation réellement constatée — cela peut toutefois nécessiter un effort considérablement plus important, car dans ces circonstances, vous avez besoin de nombreuses règles afin de décrire exactement quel service est attendu sur quel ordinateur hôte.
5.3. Supervision des ports du switch
Checkmk utilise la même logique pour la supervision des interfaces réseau sur les serveurs et des ports du switch. Avec les ports du switch, les options existantes pour contrôler la reconnaissance du service sont particulièrement intéressantes, même si (contrairement aux processus et aux services Windows) la reconnaissance fonctionne initialement sans règles. Autrement dit, par défaut, Checkmk surveille automatiquement tous les ports physiques qui sont actuellement en état UP. Le jeu de règles applicable s'appelle «Network interface and switch port discovery» et offre de nombreuses options de configuration qui ne sont décrites ici que brièvement :
Les options suivantes sont les plus importantes :
Dans la section « Appearance of network interface », vous pouvez déterminer comment l'interface doit apparaître dans le nom du service. Vous pouvez choisir entre Use description, Use alias et Use index.
La restriction ou l'extension des types ou des noms des interfaces sous supervision.
6. Configuration des services obligatoires
Dans certaines situations, la reconnaissance automatique du service n'a aucun sens. C'est toujours le cas lorsque vous souhaitez imposer le respect d'une directive spécifique. Comme nous l'avons vu dans le chapitre précédent, vous pouvez autoriser la supervision des services Windows à se configurer automatiquement lorsque ceux-ci sont détectés. Que se passe-t-il lorsque l'absence d'un tel service pose un problème ? Par exemple :
Un antivirus particulier doit être installé sur chaque ordinateur hôte Windows.
NTP doit être configuré sur chaque ordinateur hôte Linux.
Dans de tels cas, vous pouvez simplement imposer ces services. Vous trouverez le point de départ pour cela via Setup > Services > Enforced services. Derrière cela se cache une collection de jeux de règles qui portent exactement les mêmes noms que les jeux de règles utilisés pour configurer les paramètres de ces vérifications.
Les règles diffèrent toutefois sur deux points :
Il s'agit de règles pour les ordinateurs hôtes, et non pour les services. Les services seront créés par les règles.
Comme aucune identification n'a lieu, vous devez sélectionner le plugin de supervision à utiliser pour le contrôle.
L'exemple suivant montre le corps de la règle State of NTP time synchronisation sous Enforced services :
Outre les valeurs seuil, vous définissez ici le plugin de supervision (par exemplechrony
ountp_time
). Pour les plugins de supervision qui nécessitent un élément, vous devez également
les spécifier. C'est par exemple nécessaire pour le pluginoracle_processes
, qui requiert les détails du SID de la base de données à superviser :
Un service manuel défini de cette manière sera installé sur tous les ordinateurs hôtes auxquels ces règles s'appliquent. Il existe désormais trois conditions possibles pour la supervision proprement dite :
L'ordinateur hôte est correctement installé et le service est en état « OK ».
L'agent signale que le service demandé ne fonctionne pas ou présente un problème. Le service est alors marqué comme « CRIT » ou « UNKNOWN ».
L'agent ne fournit aucune information, par exemple parce que NTP n'est même pas installé. Le service reste alors en état PEND et le service « Check_MK » passe en état « WARN » avec la mention indiquant que la section correspondante dans les données de l'agent est manquante.
Vous n'aurez pas besoin de la plupart des jeux de règles du moduleEnforced services ; ils ne sont présents que par souci d'exhaustivité. Les cas les plus courants de vérifications manuelles sont les suivants :
Supervision des services Windows (Jeu de règles : Windows Services)
Supervision des processus (Jeu de règles : State and count of processes)
7. La vérification de l'identification
Dans l’introduction, nous vous avons promis que Checkmk ne se contente pas de détecter automatiquement la liste des services, mais qu’il est également capable de la maintenir à jour. Il serait par ailleurs logique de pouvoir lancer manuellement, de temps à autre, une identification groupée de tous les ordinateurs hôtes.
7.1. Check automatique des services non surveillés
Il est toutefois préférable de recourir à un check de découverte régulier, qui est configuré automatiquement sur les nouveaux sites. Ce service Check_MK Discovery existe pour chaque ordinateur hôte et enregistre un avertissement chaque fois qu’il détecte des éléments non surveillés :
Les détails des services non surveillés ou disparus sont disponibles sur la page de détails du service d’Check_MK Discovery, dans le champ « Details » :
La liste des services de l’ordinateur hôte dans la configuration est facilement accessible via le menu d’action « 
» du service « Check_MK Discovery »
et l’entrée « » de l’Run service discovery.
Le paramétrage de la vérification d’identification s’effectue très simplement à l’aide de l’ensemble de règles « Periodic service discovery ». Dans une instance prête à l’emploi, vous trouverez déjà une règle définie pour s’appliquer à tous les ordinateurs hôtes :
Outre l'intervalle auquel le check doit être effectué, vous pouvez définir le statut de la supervision pour les cas de services non surveillés, de services disparus, d'étiquettes de service modifiées et de nouvelles étiquettes d'hôte.
7.2. Ajout automatique de services
Vous pouvez configurer le check d’identification pour qu’il ajoute automatiquement les services manquants. Pour ce faire, activez l’option « Automatically update service configuration », ce qui rendra d’autres options disponibles.
Outre les ajouts, dans « Parameters », vous pouvez également choisir de supprimer les services disparus, voire de supprimer tous les services existants et d'effectuer une toute nouvelle identification. Cette dernière option se trouve dans le menu déroulant sous le nom « Refresh all services and host labels (tabula rasa) ». Ces deux options doivent être utilisées avec prudence ! Un service disparu peut indiquer un problème ! Le check d'identification supprimera simplement un tel service et vous laissera croire que tout est en ordre. L'actualisation est particulièrement risquée. Par exemple, le check des ports de commutateur ne prendra en compte que les ports dont le statut est « UP » dans la supervision. Les ports dont le statut est « DOWN » seront considérés comme disparus et rapidement supprimés lors du check d'identification !
Un autre problème doit être pris en compte : l'ajout de services ou même l' Activate Changesation automatique peut vous distraire — vous, l'administrateur — lorsque vous effectuez une configuration. Il peut théoriquement arriver que, pendant que vous travaillez sur des règles et des paramètres, un contrôle d'identification active vos modifications à ce moment précis. Dans Checkmk, seules toutes les modifications peuvent être activées en même temps ! Afin d’éviter de telles situations, vous pouvez redéfinir l’heure de cette fonction, par exemple pendant la nuit. L’image ci-dessus en montre un exemple.
Sous « Vanished clustered services », vous pouvez gérer les services en cluster séparément. Particularité : si un service en cluster passe d’un nœud à un autre, il pourrait être brièvement considéré comme ayant disparu et, par conséquent, supprimé par inadvertance. Si vous désactivez cette option, en revanche, les services qui ont réellement disparu ne seraient jamais supprimés.
Le paramètre « Group discovery and activation for up to » garantit que chaque service nouvellement détecté ne déclenche pas immédiatement une vérification de Activate Changes — il y aura plutôt un délai d’attente spécifié afin que plusieurs modifications puissent être activées en une seule action. Même si la vérification d’identification est réglée sur un intervalle de deux heures ou plus, cela ne s’applique qu’à chaque ordinateur hôte séparément. Les vérifications ne s’exécutent pas simultanément pour chaque ordinateur hôte — ce qui est une bonne chose, car une vérification d’identification nécessite nettement plus de ressources qu’une vérification normale.
8. Services passifs
Les services passifs sont ceux qui ne sont pas activement lancés par Checkmk, mais plutôt par des résultats de vérification régulièrement transmis depuis des sources externes. Cela se fait généralement via le canal de commande du noyau du processeur. Voici une procédure étape par étape pour créer un service passif :
Tout d'abord, vous devez signaler le service au noyau du processeur. Cela s'effectue en utilisant le même jeu de règles que pour vos propres checks actifs, à l'exception de l'Command line :
L'image montre également comment vous pouvez vérifier si les résultats des checks sont régulièrement reçus. Si ceux-ci ne s'affichent pas pendant plus de dix minutes, le service sera automatiquement marqué comme UNKNOWN.
Après une Activate Changes, le nouveau service commencera son cycle de vie à l’ état PEND :
L'envoi du résultat du check s'effectue désormais en ligne de commande via une
echode l'instruction PROCESS_SERVICE_CHECK_RESULT dans le
pipeline d'instruction ~/tmp/run/nagios.cmd.
La syntaxe est conforme aux conventions habituelles de Nagios — y compris un
horodatage actuel entre crochets. Comme argument de l’instruction, vous devez
indiquer le nom de domaine (par exemple, myhost) et le nom du service sélectionné
(par exemple, BAR). Les deux arguments suivants sont à nouveau l’état
(0 … 3) et la sortie du plugin. L’horodatage est
généré à l’aide de $(date +%s) :
Le service affiche désormais immédiatement son nouveau statut :
9. Reconnaissance du service en ligne de commande
Une interface graphique convient parfaitement, mais la bonne vieille ligne de commande reste parfois
pratique, que ce soit pour l’automatisation ou simplement pour permettre à un utilisateur expérimenté
de travailler rapidement. La reconnaissance du service peut être déclenchée à l’aide de l’instruction cmk
-I sur la ligne de commande. Ce processus comporte quelques variables.
Pour toutes celles-ci, l’option -v est recommandée, afin que
vous puissiez voir ce qui se passe. Sans -v, Checkmk se comporte comme le bon
vieux Unix traditionnel : tant que tout va bien, il ne dit rien.
Avec une simple recherche « -I » pour tous les ordinateurs hôtes par nouveaux services :
Avec l’option « -I », vous pouvez également saisir un ou plusieurs noms de domaine afin
de ne découvrir que ceux-ci. Cela a en outre un deuxième effet : alors qu’
une commande « -I » sur tous les ordinateurs hôtes fonctionne essentiellement uniquement avec des données mises en cache,
Checkmk travaille toujours avec des données actuelles provenant d’un ordinateur hôte explicitement désigné !
Vous pouvez également filtrer à l'aide de balises :
Cela permettrait d'effectuer l'identification pour tous les ordinateurs hôtes portant la balise de l’hôte mytag.
Le filtrage par balises est disponible pour toutes les options cmk qui acceptent plusieurs ordinateurs hôtes.
Avec les options --cache et respectivement --no-cache, vous
pouvez déterminer explicitement l'utilisation du cache.
Des sorties supplémentaires peuvent être obtenues avec un deuxième -v. Avec les périphériques SNMP,
vous pouvez même voir chaque OID récupéré depuis le périphérique :
Un renouvellement complet des services (tabula rasa) peut être effectué à l'aide d'une
double commande « -II » :
Vous pouvez également limiter tout cela à un seul plugin de supervision. Pour cela, l'
option est --detect-plugins= , et elle doit être placée avant le nom de domaine :
Une fois que vous avez terminé, vous pouvez activer les modifications à l'aide de la commande «cmk -O
» (cmk -R
avec Nagios Core) :
Et lorsque vous rencontrez une erreur lors d'une identification…
… grâce à une commande supplémentaire « --debug », vous pouvez générer une trace détaillée de la pile Python
indiquant l'emplacement de l'erreur :
9.1. Aperçu des options
Pour résumer — toutes les options en un coup d'œil :
|
Découvrir de nouveaux services |
|
Supprimer et redécouvrir tous les services (tabula rasa) |
|
Mode détaillé : afficher les ordinateurs hôtes et les services détectés |
|
Très détaillé : afficher un protocole précis de toutes les opérations |
|
Exécuter une identification (et également une tabula rasa) uniquement pour le plugin de supervision spécifié |
|
Effectuer une identification (et également une table rase) uniquement pour les ordinateurs hôtes portant la balise spécifiée |
|
Forcer l'utilisation des données du cache (normalement la valeur par défaut uniquement lorsqu'aucun ordinateur hôte n'est spécifié) |
|
Récupérer des données actuelles (par défaut uniquement lorsqu'un nom de domaine est spécifié) |
|
Annuler en cas d'erreur et afficher la trace complète de la pile Python |
|
Activer les modifications (éditions commerciales avec CMC comme noyau du processeur) |
|
Activer les modifications (Checkmk Community avec Nagios comme noyau du processeur) |
9.2. Enregistrement dans des fichiers
Le résultat de la reconnaissance du service — c’est-à-dire, comme expliqué précédemment, les
tableaux de noms de domaine, de plugins de supervision, d’éléments et de paramètres identifiés — se
trouve dans le dossier var/check_mk/autochecks. Ici, pour chaque
hôte, il existe un ensemble de données qui stocke les services découverts automatiquement.
Tant que vous n’altérez pas la syntaxe Python de cet ensemble de données, vous pouvez modifier ou
supprimer manuellement des lignes individuelles. La suppression de l’ensemble de données supprime tous les services
et les marque à nouveau comme quasi « non surveillés ».
[
{'check_plugin_name': 'cpu_loads', 'item': None, 'parameters': (5.0, 10.0), 'service_labels': {}},
{'check_plugin_name': 'cpu_threads', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'diskstat', 'item': 'SUMMARY', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'kernel_performance', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'kernel_util', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'livestatus_status', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'lnx_thermal', 'item': 'Zone 0', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mem_linux', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mknotifyd', 'item': 'mysite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mknotifyd', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'mounts', 'item': '/', 'parameters': ['errors=remount-ro', 'relatime', 'rw'], 'service_labels': {}},
{'check_plugin_name': 'omd_apache', 'item': 'mysite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'omd_apache', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'tcp_conn_stats', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'timesyncd', 'item': None, 'parameters': {}, 'service_labels': {}},
{'check_plugin_name': 'uptime', 'item': None, 'parameters': {}, 'service_labels': {}},
]10. Groupes de service
10.1. Pourquoi avoir recours à des groupes de service ?
Jusqu'à présent, vous avez appris à inclure des services dans la supervision. Il n'est désormais plus très judicieux de devoir parcourir des listes de milliers de services et/ou de toujours passer par les vues d'ordinateurs hôtes. Par exemple, si vous souhaitez afficher tous les services de système de fichiers ou de mise à jour ensemble, vous pouvez simplement créer des groupes de la même manière que vous le feriez avec des groupes d'hôtes.
Les groupes de service vous permettent de mettre plus facilement de l'ordre dans la supervision via les vues de la table et les cartes NagVis, et d'activer des notifications ciblées et des gestionnaires d'alertes.
À ce propos, vous pourriez presque toujours créer des vues correspondantes en utilisant uniquement les filtres de vue, mais les groupes de service sont plus clairement organisés et plus faciles à utiliser.
10.2. Création de groupes de service
Vous trouverez les groupes de service via Setup > Services > Service groups.
La création d'un groupe de service est simple :
Créez un groupe via 
Add group et attribuez-lui un nom qui ne pourra pas être modifié par la suite, ainsi qu'un alias significatif :
10.3. Ajouter des services à un groupe de service
Pour attribuer des services à des groupes de services, vous avez besoin de la règle Assignment of services to service groups. Le moyen le plus rapide d’y accéder est de passer par l’aperçu des groupes de services (Setup > Services > Service Groups). Il vous suffit ici de cliquer sur « Service Groups > Assign to group > Rules » dans les menus. Vous pouvez bien sûr également trouver cette règle via la recherche de règles dans le menu « Setup », ou en parcourant Setup > Services > Service monitoring rules > Various > Assignment of services to service groups. Utilisez maintenant Create rule in folder pour effectuer cette opération. Vous devez d’abord spécifier à quel groupe de services attribuer les services, par exemple « myservicegroup » ou son alias « My service group 1 ».
La partie intéressante se trouve ensuite dans la section « Conditions ».
D'une part, vous pouvez utiliser des dossiers, des balises de l’hôte et des noms de domaine explicites pour définir des restrictions en dehors des services.
D'autre part, vous nommez les services que vous souhaitez regrouper, tels que Filesystem et myservice, afin de créer un ensemble de systèmes de fichiers.
La spécification des services s'effectue ici sous la forme d'expressions régulières. Cela vous permet de définir des groupes avec précision.
10.4. Vérification des groupes de service pour un service
Vous pouvez checker l'affectation des services sur la page de détail d'un service particulier. Ci-dessous, par défaut, figure la ligne Service groups the service is member of.
10.5. Utilisation des groupes de service
Comme déjà mentionné, les groupes de services sont utilisés à plusieurs endroits, tels que les vues, les cartes NagVis, les notifications et les gestionnaires d'alertes. Pour les nouvelles vues, il est important que vous utilisiez l'Service groups comme source de données. Bien entendu, le widget Views contient également des vues prédéfinies pour les groupes de services, par exemple un résumé clair :
En cliquant sur les noms des groupes de service, vous obtiendrez une vue complète de tous les services du groupe concerné.
Si vous utilisez des groupes de services dans les cartes NagVis, vous obtiendrez un résumé des groupes de services ouverts dans un menu en survolant une icône :
Lorsque vous utilisez des groupes de services dans les notifications et les gestionnaires d'alertes, ils sont disponibles sous forme de conditions/filtres, dont vous pouvez utiliser un ou plusieurs :
11. Plus d'informations sur les plugins de supervision
11.1. Brève description de leur fonctionnalité
Les plugins de supervision sont nécessaires pour générer des services dans Checkmk.
Chaque service utilise un plugin de supervision pour déterminer son état, créer/gérer des métriques, etc.
Ce faisant, un tel plugin peut créer un ou plusieurs services par ordinateur hôte.
Afin de pouvoir distinguer plusieurs services provenant du même plugin, un élément (Item) est nécessaire.
Par exemple, pour le service Filesystem /var, l'élément est le texte /var.
Dans le cas des plugins qui ne peuvent générer qu’un seul service par ordinateur hôte au maximum (
CPU utilization, par exemple), l’élément est vide et n’apparaît pas.
11.2. Plugins de supervision disponibles
Une liste de tous les plugins de supervision disponibles est disponible sous Setup > Services > Catalog of check plugins. Vous pouvez y rechercher les différents plugins de supervision et les filtrer selon diverses catégories :
Pour chaque plugin, trois colonnes d'informations s'affichent : une description du service (Type de vérification), le nom du plugin de supervision (Nom du plugin) et ses sources de données compatibles (Agents) :
