Les règles

Prenons l'exemple de la configuration des seuils de WARN et de CRIT dans la surveillance des systèmes de fichiers. Avec une configuration orientée base de données, pour chaque système de fichiers, il faudrait entrer une ligne dans un tableau :

C'est relativement simple, mais uniquement parce que le tableau de cet exemple est court. Dans la pratique, il y a souvent des centaines ou des milliers de systèmes de fichiers. Des outils comme le copier-coller et les opérations en masse peuvent simplifier le travail, mais le problème de base demeure : comment identifier et mettre en œuvre une directive standard ? Quelle est la règle générale ? Comment les valeurs seuils pour les futurs ordinateurs hôtes devraient-elles être prédéfinies ?

Une configuration basée sur des règles consiste cependant en une directive ! Nous allons remplacer la logique du tableau ci-dessus par un jeu de quatre règles. Si nous supposons que myserver001 est un système de test, et que dans chaque cas la première règle pertinente s'applique à chaque système de fichiers, le résultat sera les mêmes valeurs seuils que dans le tableau ci-dessus :

Certes, pour deux hôtes seulement, cela ne donne pas grand-chose, mais pour quelques hôtes supplémentaires, cela peut rapidement faire une grande différence. Les avantages de la configuration basée sur des règles sont évidents :

En résumé : moins de travail - plus de qualité ! C'est pourquoi vous trouverez dans Checkmk une multitude de règles pour définir les hôtes et les services - comme les seuils, les paramètres de surveillance, les responsabilités, les notifications, la configuration des agents et bien d'autres choses encore.

Dans le cadre de l'installation, Checkmk organise les règles en jeux de règles. Chaque jeu de règles a pour tâche de définir un paramètre spécifique pour les hôtes ou les services. Checkmk contient plus de 700 jeux de règles ! En voici quelques exemples :

Chaque jeu de règles est responsable soit des hôtes, soit des services, mais jamais des deux. Si un paramètre peut être défini à la fois pour les hôtes et les services, il existe une paire de règles applicables - par exemple, Normal check interval for host checks et Normal check interval for services checks.

Certains jeux de règles ne définissent pas à proprement parler de paramètres, mais créent plutôt des services. Les règles relatives aux contrôles actifs, que vous trouverez à l'adresse Setup > Services > HTTP, TCP, Email, …​, en sont un exemple. Elles vous permettent, par exemple, de configurer un contrôle HTTP pour des hôtes spécifiques. Ces règles sont classées comme des règles d'hôte, car si un tel contrôle existe sur un hôte, il est considéré comme une propriété de l'hôte.

D'autres jeux de règles contrôlent l'identification des services. Ils vous permettent, par exemple, via Windows service discovery, de définir les services Windows pour lesquels des checks automatiques doivent être créés s'ils sont trouvés sur un système. Il s'agit également de règles d'hôte.

La plupart des jeux de règles déterminent des paramètres pour des plugins de check spécifiques, comme par exemple Network interfaces and switch ports. Les paramètres de ces règles sont adaptés de manière très spécifique au plugin correspondant. Ces jeux de règles ne peuvent être utilisés qu'avec les services basés sur ce plugin. Si vous ne savez pas quel jeu de règles est responsable de quel service, vous pouvez naviguer directement via le service jusqu'à la règle correspondante. La marche à suivre sera expliquée plus loin.

Une chose que nous n'avons pas mentionnée jusqu'à présent : dans l'exemple ci-dessus, il existe une règle pour tous les systèmes de test. Où est-il défini qu'un hôte est un système de test ?

Dans Checkmk, quelque chose comme un système de test est connu sous le nom de balise hôte. Vous pouvez voir quelles sont les balises disponibles via Setup > Hosts > Tags. Certaines balises sont déjà prédéfinies - par exemple, pour un Test system défini dans le groupe Criticality.

L'application des balises aux hôtes se fait soit explicitement dans les propriétés de l'hôte, soit par héritage dans la hiérarchie des dossiers. La manière de procéder est expliquée dans l'article sur les hôtes. La manière de créer vos propres balises et la nature des balises prédéfinies sont expliquées dans l'article sur les balises d'hôte.

Si vous souhaitez créer une nouvelle règle définissant un paramètre pour un ou plusieurs ordinateurs hôtes, il existe plusieurs moyens d'y parvenir. Le moyen direct consiste à passer par le groupe correspondant dans le menu setup, en l'occurrence Setup > Hosts > Host monitoring rules. Dans la vue suivante, tous les jeux de règles pertinents pour la surveillance des hôtes sont affichés :

Dans la vue suivante, tous les jeux de règles pertinents pour la surveillance des hôtes sont affichés. Les nombres qui suivent les noms de ces jeux de règles indiquent le nombre de règles qui ont déjà été définies :

Toutefois, vous pouvez atteindre votre objectif un peu plus rapidement via le champ de recherche. Pour ce faire, vous devez bien entendu connaître approximativement le nom du jeu de règles. Voici, à titre d'exemple, le résultat d'une recherche sur host checks.

Vous pouvez également utiliser l'élément de menu Hosts > Effective parameters dans les propriétés d'un ordinateur hôte existant dans le menu de configuration ou l'icône dans la liste des ordinateurs hôtes d'un dossier.

Vous y trouverez non seulement tous les jeux de règles qui affectent l'hôte, mais aussi le paramètre actuellement en vigueur pour cet hôte. Dans l'exemple de Host check command, aucune règle ne s'applique à l'hôte indiqué, et il est donc défini sur la valeur par défaut Smart PING (only with Checkmk Micro Core) des éditions commerciales. Dans l'exemple de Raw Edition, la valeur par défaut est PING (active check with ICMP echo request).

Cliquez sur Host check command pour voir le jeu de règles complet.

Si une règle existe déjà, le numéro de la règle définissant ce paramètre apparaît à la place de Default value.

En cliquant dessus, vous accédez directement à la règle.

Le chemin d'accès aux jeux de règles pour les services est similaire. L'accès général se fait par le menu Setup, en l'occurrence Setup > Services > Service monitoring rulesou, de manière plus appropriée, par le champ de recherche.

Si vous n'êtes pas encore très familiarisé avec les noms des ensembles de règles, le chemin via le service est plus simple. Comme pour les hôtes, il existe également une page dans laquelle tous les paramètres d'un service sont affichés et où vous avez la possibilité d'accéder directement aux ensembles de règles applicables. Vous pouvez accéder à cette page de paramètres à l'aide de l'icône dans la liste des services de l'hôte dans la configuration. L'icône permet d'accéder au chemin d'accès qui définit les paramètres du plugin de surveillance pour ce service.

Par ailleurs, l'icône de la page de paramètres se trouve également dans la surveillance, dans le menu d'action de chaque service :

Dans le menu Setup, vous trouverez également une entrée pour Enforced Services. Comme le nom le suggère, vous pouvez utiliser ces jeux de règles pour forcer la création de services sur vos hôtes. Des détails peuvent être trouvés dans l'article sur les services. Un petit nombre de jeux de règles - tels que Simple checks for BIOS/Hardware errors- ne peuvent être trouvés que dans les services forcés. Ce sont des services qui ne résultent pas de la reconnaissance du service, mais qui sont créés manuellement par vous.

Dans chacune des listes de jeux de règles susmentionnées - que ce soit dans Host monitoring rules ou Service monitoring rules- vous pouvez utiliser Related > Used rulesets dans la barre de menu, pour afficher uniquement les jeux de règles dans lesquels vous avez défini au moins une règle. C'est souvent une façon pratique de commencer si vous voulez faire des ajustements à vos règles existantes. Incidemment, certaines des règles auront été générées par défaut lors de la création du site Checkmk et font partie de l'exemple de configuration. Elles sont également affichées ici.

La surveillance est un sujet complexe. Il peut arriver que certaines règles ne saisissent pas un seul hôte ou service - soit parce que vous avez fait une erreur, soit parce que les hôtes et services correspondants ont disparu. Ces règles inefficaces peuvent être trouvées dans les listes de jeux de règles susmentionnées via Related > Ineffective rulesets dans la barre de menus.

Checkmk est en développement constant. Il arrive que des choses soient standardisées et que certains jeux de règles soient remplacés par d'autres. Si vous utilisez de tels jeux de règles, le moyen le plus simple de les retrouver est de faire une recherche de règles. Ouvrez-la via Setup > General > Rule search. Cliquez ensuite dans la barre de menus sur Rules > Refine search, sélectionnez Search for deprecated rulesets comme option pour Deprecatedet sélectionnez Search for rule sets that have rules configured comme option pour Used. Après un clic supplémentaire sur Search, vous obtenez l'aperçu souhaité.

Lorsque vous accédez à un jeu de règles pour un hôte ou un service dans Setup, Checkmk vous montrera ce jeu de règles en mode analyse. Vous pouvez y accéder en cliquant sur l'icône du menu d'action dans Setup dans la liste des hôtes ou des services. La page Effective parameters of suivante montre la liste des règles qui s'appliquent à l'hôte/au service. Pour accéder au mode analyse, cliquez sur le nom d'un jeu de règles pour lequel il existe au moins une règle, c'est-à-dire un jeu qui n'est pas défini dans Default value. Ce mode a deux fonctions :

Ce mode présente deux caractéristiques : tout d'abord, un deuxième bouton permettant de définir des règles apparaît -Add rule for current host bzw. Add rule for current host and service.

Ce bouton vous permet de créer une nouvelle règle pour laquelle l'hôte ou le service en cours est déjà présélectionné. Vous pouvez ainsi créer une règle exceptionnelle très facilement et directement. Deuxièmement, une icône "feu tricolore" apparaît sur chaque ligne, dont la couleur indique si et/ou comment cette règle affecte l'hôte ou le service en cours. Les conditions suivantes sont possibles :

La dernière condition - la règle est une correspondance partielle - ne peut se produire que pour les ensembles de règles dans lesquels une règle peut définir plusieurs paramètres en sélectionnant des cases à cocher individuelles. En théorie, chaque paramètre d'une autre règle peut également être défini individuellement ici. Nous y reviendrons plus tard.

Tout ce qui se trouve dans le premier bloc, Rule Properties, est facultatif et sert principalement de documentation :

La deuxième section est différente pour chaque règle, mais précise toujours ce qui doit être fait. L'illustration suivante montre un type de règle très répandu (DB2 Tablespaces). Vous pouvez utiliser des cases à cocher pour déterminer les paramètres individuels que la règle doit définir. Comme décrit ci-dessus, Checkmk détermine quelle règle définit chaque paramètre individuel séparément. La règle de l'illustration ne définit donc qu'une seule valeur et laisse tous les autres paramètres inchangés :

Vous pouvez également contrôler les valeurs de cette règle et d'autres règles sur une base temporelle/calendaire. Par exemple, vous pouvez définir des valeurs seuils de sorte que l'utilisation du tablespace pendant les heures de bureau diffère de celle des week-ends.

Cliquez d'abord sur le bouton Enable timespecific parameters, puis sur Add new element, vous verrez apparaître les options dépendant du temps :

Sélectionnez maintenant une période de temps dans la liste Match only during time period, puis sélectionnez les paramètres auxquels cette période doit s'appliquer.

Certains jeux de règles ne définissent pas de paramètre, mais décident seulement quels sont les hôtes qui sont dans le système et ceux qui n'y sont pas. Un exemple est le jeu de règles Hosts to be monitored, dont la plage de paramètres se présente comme suit :

En sélectionnant l'une des deux valeurs disponibles, vous décidez de ce qu'il faut faire avec les hôtes concernés. En sélectionnant Positive match (Add matching hosts to the set), vous ajoutez les hôtes concernés à l'ensemble des hôtes à surveiller. En sélectionnant Negative match (Exclude matching hosts from the set), vous retirez les hôtes concernés de la surveillance. Les valeurs Positive match ou Negative match font référence au contenu de la règle actuelle. Il ne s'agit pas d'un critère de filtrage supplémentaire pour la sélection des hôtes. Vous filtrez le jeu de règles des hôtes concernés exclusivement à l'aide de la valeur suivante : Conditions.

Dans la section précédente, vous avez défini comment tous les hôtes ou services affectés par votre règle doivent être traités. Dans la troisième section Conditions, vous définissez maintenant quels hôtes ou services doivent être affectés par la règle - et donc ses effets. Il existe différents types de conditions qui doivent toutes être remplies pour que la règle prenne effet. Les conditions sont donc logiquement liées par un ET :

Dans l'introduction au concept de règles, vous avez vu que la première règle qui s'applique détermine toujours le résultat final. Ce n'est pas tout à fait vrai. Il existe au total trois types d'évaluation différents :

Les informations relatives à l'évaluation de la règle sont affichées pour chaque jeu de règles directement sous la barre de menus :

Maintenant, comment sera évaluée concrètement la règle si l'on a créé plusieurs règles qui doivent être appliquées à plusieurs hôtes ? Pour illustrer cela, prenons un exemple simple :

Admettons que vous ayez trois hôtes et que vous souhaitiez définir des notifications différentes répétées périodiquement pour chacun d'entre eux (ainsi que pour tous les hôtes ajoutés à l'avenir) à l'aide de la règle Periodic notifications during host problems:

Si vous activez maintenant votre configuration, Checkmk parcourt la chaîne de règles de haut en bas, ce qui donne l'évaluation suivante :

Veuillez noter ici que, puisque le principe "La première règle correspondante définit le paramètre" s'applique à ce jeu de règles, le traitement de la chaîne de règles se termine toujours après la première correspondance. L'ordre des règles est donc déterminant pour le résultat ! Cela apparaît clairement lorsque l'ordre des règles est modifié et que les règles B et C sont interverties :

Si l'on reprend la chaîne de règles de haut en bas pour les différents hôtes, le résultat change également : la règle C s'applique désormais non seulement à l'hôte 3, mais aussi à l'hôte 2, de sorte que la notification pour les deux hôtes a lieu toutes les 30 minutes. Le traitement est ainsi terminé pour les deux hôtes. Bien que la règle B soit pertinente pour l'hôte 2, et qu'elle ait même été écrite pour cet hôte, elle ne sera plus évaluée et appliquée. En mode analyse, le processus se déroulera alors comme suit :

En combinant les différents paramètres expliqués dans cet article - en gardant à l'esprit l'ordre de processus correct - vous pouvez les utiliser pour construire des chaînes de règles complexes pour des complexes d'hôtes entiers.