Supervision de Windows

Vous installez l'agent Windows en installant le package MSI.

Avant l'installation, vous devez récupérer le paquet et le transférer sur l'ordinateur hôte sur lequel l'agent sera exécuté (par exemple avec scp ou WinSCP).

Les éditions commerciales disposent d'un module logiciel, la boulangerie d’agents, permettant de créer automatiquement des agents personnalisés. Vous trouverez une description détaillée de ce module dans l'article général consacré aux agents. L'installation du package MSI généré s'effectue de la même manière que celle décrite ci-dessus pour le package inclus.

Dans Checkmk Ultimate, vous pouvez en outre utiliser la boulangerie d’agents pour doter les paquets d'agents d'une configuration d'enregistrement automatique, ce qui facilite la création automatique d'ordinateurs hôtes. Dans ce cas, l'enregistrement de l'agent s'effectue automatiquement une fois le paquet d'agent installé, et l'enregistrement manuel, tel que décrit dans le chapitre suivant, n'est plus nécessaire.

Si vous utilisez la boulangerie d’agents, vous pouvez également configurer les mises à jour automatiques de l’agent. Ces mises à jour sont décrites dans un article dédié.

Lors d'une installation, le package MSI stocke les fichiers spécifiques au programme dans C:\Program Files (x86)\checkmk\service\ et les fichiers spécifiques à l'ordinateur hôte dans C:\ProgramData\checkmk\agent\. Vous n'avez pas besoin de personnaliser les fichiers spécifiques au programme. Les fichiers spécifiques à l'ordinateur hôte servent à stocker les plugins, les fichiers journaux et de configuration, ainsi qu'à configurer le comportement de l'agent.

Remarque : par défaut, l'intégralité du répertoire C:\ProgramData est masquée sous Windows.

L'agent lit trois fichiers de configuration à la suite :

Si une option a été définie dans plusieurs fichiers, c'est le dernier fichier lu qui détermine la valeur de cette option. Pour les interventions manuelles sur l'agent, seul le dernier fichier de configuration check_mk.user.yaml est donc pertinent, car il est lu en dernier et a donc le dernier mot. Si la boulangerie d’agents n'est pas utilisée, c'est en fait le seul fichier dans lequel des personnalisations de la configuration de l'agent peuvent être effectuées.

Comme vous l'avez peut-être déjà remarqué d'après l'extension des fichiers de configuration, le format de fichier utilisé est YAML.

Après l'installation de l'agent, y compris l'Agent Controller, l'étape suivante est l'enregistrement, qui configure le chiffrement TLS afin que les données chiffrées de l'agent puissent être déchiffrées par le serveur Checkmk et affichées dans la supervision.

Une particularité existe lorsque l’agent a été installé avec l’Agent Controller pour la première fois. Dans ce cas, l’agent bascule vers le mode legacy pull non chiffré, afin que le serveur Checkmk ne soit pas privé des données de supervision et puisse continuer à les afficher. Cela s’applique aussi bien à une nouvelle installation qu’à une mise à jour d’un agent de version 2.0.0 et antérieure.

Voici à quoi cela ressemblera dans la supervision :

Le site Checkmk détecte, à partir de la sortie de l'agent, que l'Agent Controller est présent et que le chiffrement TLS est donc possible — mais pas encore activé. Le service Check_MK Agent passe à l'état « WARN » et y reste jusqu'à ce que vous l'enregistriez. Après l'enregistrement, seul le mode Pull chiffré sera utilisé pour la communication. Le mode legacy Pull est désactivé et le restera. Il peut toutefois être réactivé par instruction si nécessaire.

La situation sera différente si vous utilisez un agent hérité sur un système Windows très ancien. Sans l’Agent Controller, l’enregistrement n’est pas possible. Ainsi, pour les agents hérités, les seules sections pertinentes du chapitre Enregistrement concernent l’ajout de l’ordinateur hôte à la Configuration, puis à la supervision. Dans le chapitre « Test et dépannage », vous devez omettre le test d'appel de l'Agent Controller, car celui-ci n'est pas disponible pour un agent hérité. Comme il n'y a pas non plus de chiffrement TLS sans l'Agent Controller, vous devrez utiliser d'autres méthodes de chiffrement si nécessaire. Dans ce cas, nous vous recommandons d'utiliser le chiffrement intégré (symétrique) via la règle « Symmetric encryption (Linux, Windows) ».

Remarque : dans le jeu de règles « Checkmk Agent installation auditing », vous trouverez divers paramètres permettant de vérifier l'état de l'agent et de le rendre visible dans la supervision. Vous pouvez notamment y spécifier l'état que doit présenter le service « Check_MK Agent » si la configuration TLS n'a pas encore été effectuée.

Immédiatement après l'installation de l'agent (ou lors de la mise à jour d'un agent de version 2.0.0 ou antérieure), seules les communications non chiffrées sont possibles en mode legacy pull. Une transmission de données exclusivement chiffrée ne peut être activée qu'une fois qu'une relation de confiance a été établie.

Les paquets préconfigurés pour l'enregistrement automatique et téléchargés via la boulangerie d’agents constituent une exception à cette règle. Ces paquets effectuent l'enregistrement automatiquement après l'installation.

Dans tous les autres cas, vous devez effectuer l'enregistrement manuellement immédiatement après l'installation de l'agent. Ce chapitre explique comment procéder à l'enregistrement.

L'enregistrement, et donc l'établissement de la relation de confiance mutuelle, s'effectue sous un utilisateur Checkmk disposant d'un accès à l'API REST. Pour cela, l'utilisateur de l'automatisation agent_registration constitue un bon choix : il dispose uniquement de l'autorisation d'enregistrer des agents et est créé automatiquement lors de chaque installation de Checkmk. Vous pouvez générer aléatoirement le mot de passe d'automatisation correspondant (secret d'automatisation) à l'aide de l'icône « ». Vous devez enregistrer l'utilisateur avant de pouvoir utiliser le nouveau mot de passe.

Remarque : comme il n'y a pas d'Agent Controller, et donc pas de registre ni de chiffrement TLS, sur les très anciens systèmes Windows, vous devrez utiliser d'autres méthodes de chiffrement si nécessaire. Dans ce cas, nous vous recommandons d'utiliser le chiffrement intégré (symétrique) via la règle Symmetric encryption (Linux, Windows).

Commencez par créer le nouvel ordinateur hôte via Setup > Hosts > Add host. Un ordinateur hôte doit exister dans l'environnement de configuration avant de pouvoir être enregistré.

Dans Checkmk Ultimate, vous trouverez l'option « Checkmk agent connection mode » dans les propriétés de l'ordinateur hôte, dans la section consacrée aux agents de supervision. Vous pouvez y activer le mode Push pour l'agent Checkmk, en remplacement du mode Pull, disponible dans toutes les éditions.

L'enregistrement s'effectue à l'aide de l'Agent Controller cmk-agent-ctl , qui fournit une interface de commande pour configurer les connexions. Vous pouvez afficher l'aide relative aux instructions avec cmk-agent-ctl help , ainsi que pour des sous-commandes spécifiques disponibles, par exemple avec cmk-agent-ctl help register.

Le fait que l'ordinateur hôte soit configuré en mode Pull ou en mode Push n'a aucune incidence sur les exemples d'instruction. L'Agent Receiver indique à l'Agent Controller le mode dans lequel il doit fonctionner lors de l'enregistrement.

Accédez maintenant à l'ordinateur hôte à enregistrer. Vous devez ici envoyer une requête à l'instance Checkmk avec des droits d'administrateur :

Le nom de domaine suivant l'option --hostname doit être exactement le même que celui utilisé lors de sa création dans la Configuration. Les options --server et --site spécifient le nom du serveur Checkmk et du site. Le nom du serveur peut également être l'adresse IP ; le nom du site (ici mysite) correspond à celui que vous voyez dans le chemin d'accès de l'interface web. Ces options sont complétées par le nom et le mot de passe utilisés par l'utilisateur de l'automatisation. Si vous omettez l'option --password, le mot de passe vous sera demandé de manière interactive.

Attention, piège pour les imprudents : si vous administrez principalement des machines Unix, vous avez l'habitude d'encadrer les chemins d'accès ou les paramètres contenant des espaces ou des caractères spéciaux entre des guillemets simples (apostrophes, 0x27). Windows interprète ce caractère comme faisant partie de l'appel — dans ce cas, le mot de passe — et l'enregistrement échouera. Utilisez plutôt des guillemets doubles (0x22).

Si les valeurs spécifiées sont correctes, il vous sera demandé de confirmer l'identité de l'instance Checkmk à laquelle vous souhaitez vous connecter. Pour plus de clarté, nous avons abrégé le certificat du serveur à confirmer :

Confirmez en cliquant sur « Y » pour terminer le processus.

Si aucun message d'erreur ne s'affiche, la connexion cryptée aura été établie. Toutes les données seront désormais transmises sous forme compressée via cette connexion.

Si vous souhaitez désactiver la vérification interactive du certificat — par exemple pour automatiser entièrement l'enregistrement —, vous pouvez utiliser le paramètre supplémentaire --trust-cert. Dans ce cas, le certificat transféré sera automatiquement considéré comme fiable. N'oubliez pas que vous devez prendre d'autres mesures pour vérifier l'intégrité du certificat. Cela peut être effectué (manuellement ou via un script) en inspectant le fichier C:\ProgramData\checkmk\agent\registered_connections.json.

Checkmk Ultimate offre la possibilité de créer automatiquement des ordinateurs hôtes lors de l'enregistrement. Pour un tel enregistrement automatique, outre un utilisateur disposant des autorisations nécessaires pour enregistrer des ordinateurs hôtes, vous devez disposer d'au moins un dossier configuré pour contenir les ordinateurs hôtes qui doivent être créés automatiquement.

Si ces conditions sont remplies, vous pouvez également effectuer l'enregistrement, y compris la création automatique d'ordinateurs hôtes, via la ligne de commande.

En général, vous utiliserez la procédure de configuration de la boulangerie d’agents, qui inclut le fichier de configuration C:\ProgramData\checkmk\agent\pre_configured_connections.json dans le paquet de l'agent et qui effectue l'enregistrement automatiquement lors de l'installation. L'instruction de ligne de commande présentée ici est donc principalement utilisée à des fins de test et de débogage, par exemple pour essayer vos propres étiquettes de l'agent avec l'option --agent-labels <KEY=VALUE>.

La principale différence réside ici dans la sous-commande register-new modifiée, qui sert à demander l'enregistrement et la création d'un nouvel ordinateur hôte dans l'instance Checkmk. Le nom de l'ordinateur hôte est celui stocké dans la variable d'environnement %COMPUTERNAME%. La confirmation du certificat qui s'ensuit est identique à celle présentée dans la section précédente.

Le fait que l'ordinateur hôte soit créé en mode Pull, en mode Push ou pas du tout est défini par vos paramètres dans le jeu de règles Agent registration. Une fois l'enregistrement réussi, plusieurs minutes peuvent s'écouler avant que l'ordinateur hôte n'apparaisse dans la supervision.

L'instruction cmk-agent-ctl status affiche désormais exactement une relation de confiance avec le serveur Checkmk :

Si vous avez besoin de ces informations dans un format lisible par machine, ajoutez le paramètre supplémentaire --json pour récupérer la sortie au format JSON.

Remarque : il ne peut y avoir qu’une seule relation de confiance entre un hôte et un site. Par exemple, si vous enregistrez un hôte déjà enregistré mynewhost sous un nom différent (mynewhost2) mais avec la même adresse IP, la nouvelle connexion remplacera alors celle qui existe déjà. La connexion entre mynewhost et l’instance sera interrompue et aucune donnée d’agent ne sera plus fournie à l’hôte à des fins de supervision.

Pour faciliter l'enregistrement de plusieurs ordinateurs hôtes, tout ordinateur hôte sur lequel l'agent est installé peut effectuer un enregistrement au nom d'autres ordinateurs hôtes. Le processus d'enregistrement exporte un fichier JSON, qui peut ensuite être transféré vers l'ordinateur hôte cible et y être importé. Là encore, comme précédemment, l'ordinateur hôte enregistré dans la tâche doit déjà être configuré sur le site.

Tout d'abord, sur n'importe quel ordinateur hôte de la Configuration, l'enregistrement est effectué par procuration. Ici, bien sûr, le serveur Checkmk s'avère très pratique, car il est généralement le premier ordinateur hôte à être configuré. Comme dans l'exemple ci-dessus, vous pouvez transmettre le mot de passe via l'option ou être invité à le saisir de manière interactive si vous omettez l'option --password. Dans l'exemple, nous redirigeons la sortie JSON vers un fichier :

Nous transférons ensuite le fichier /tmp/mynewhost3.json vers l'ordinateur hôte que nous avons enregistré et importons ce fichier :

Une fois l'enregistrement terminé, effectuez un test de connexion et une reconnaissance du service dans la configuration du serveur Checkmk. Enfin, incluez les services découverts dans la supervision en activant les modifications.

Si le test de connexion échoue, consultez le chapitre suivant pour obtenir des informations sur les tests et le dépannage.

Vous pouvez également désenregistrer un ordinateur hôte.

Sur un ordinateur hôte connecté au serveur Checkmk, vous pouvez révoquer la confiance. Ici, dans l'instruction suivante, l'identifiant unique universel (UUID) à spécifier est celui généré par la commande `cmk-agent-ctl status` :

Pour supprimer toutes les connexions de l'ordinateur hôte et rétablir en outre le mode legacy pull, entrez l'instruction suivante :

Par la suite, l'agent se comportera comme lors de l'installation initiale et avant le premier enregistrement, et enverra ses données en clair.

Terminez la désinscription sur le serveur Checkmk : Dans la configuration, sur la page « Properties of host », sélectionnez l'entrée « Host > Remove TLS registration » et confirmez l'invite.

Si vous préférez utiliser la ligne de commande : Sur le serveur Checkmk, pour chaque connexion d'un ordinateur hôte sous supervision, il existe un lien symbolique avec l'UUID qui pointe vers le dossier contenant la sortie de l'agent :

Dans Checkmk Ultimate , vous pouvez faire passer les ordinateurs hôtes du mode Push au mode Pull et inversement. Cela peut s’avérer nécessaire dans certains cas particuliers si des modifications de la topologie du réseau sont en attente, ou si une mise à niveau vers Checkmk Pro — où seul le mode Pull est possible — doit être effectuée.

Commencez par définir le mode d’accès dans la configuration, dans les propriétés de l’ordinateur hôte, à l’aide de l’option « Checkmk agent connection mode ». Dans la minute qui suit, tous les services passeront au statut « UNKNOWN » (Inconnu) car aucune donnée de supervision n’est reçue. Effectuez ensuite un nouvel enregistrement. Au cours de ce réenregistrement, l’Agent Receiver du serveur Checkmk indique à l’Agent Controller s’il attend des données en mode Pull ou mode Push. Une check ultérieure à l'aide de cmk-agent-ctl status affichera alors un nouvel UUID et un mode correspondant à la modification effectuée dans la Configuration.

Pour vérifier que la configuration a été lue comme prévu, appelez le programme de l'agent avec l'option showconfig. Avec cette option, vous obtiendrez non seulement la configuration telle qu'elle est actuellement utilisée par l'agent, mais en outre, les variables d'environnement ainsi que les fichiers de configuration utilisés seront toujours affichés.

Si seule une partie de la configuration vous intéresse, vous pouvez limiter la sortie à cette partie spécifique. Ici, par exemple, on checke si les options de la section ps ont été correctement définies :

Vous obtenez ainsi un aperçu rapide de la manière dont les trois fichiers de configuration différents ont été fusionnés et utilisés par le programme de l'agent. Les erreurs seront immédiatement visibles.

Si l'enregistrement d'un ordinateur hôte échoue avant même qu'un certificat ne soit présenté, la connaissance des méthodes de communication peut aider à identifier le problème — et bien sûr à le résoudre.

Une fois l’instruction « cmk-agent-ctl register » saisie, l’Agent Controller demande d’abord au serveur Checkmk le port de l’Agent Receiver à l’aide de l’API REST. Dans un deuxième temps, une connexion à l’Agent Receiver est établie pour demander le certificat. Vous pouvez simuler la première requête sur l’ordinateur hôte à l’aide d’un programme tel que curl :

Le paramètre --insecure indique à curl d’ignorer la vérification du certificat. Ce comportement reflète celui de l’Agent Controller à cette étape. La réponse ne comporte que quelques octets et contient le numéro de port de l’Agent Receiver. Pour la première instance, il s’agit généralement de 8000, pour la deuxième de 8001, et ainsi de suite.

Les problèmes courants liés à cette requête sont les suivants :

Si la requête ci-dessus échoue, vous pouvez modifier les paramètres de routage ou de pare-feu pour permettre l'accès.

Si l'ordinateur hôte que vous essayez d'enregistrer utilise un proxy HTTP, curl l'utilisera, mais cmk-agent-ctl ne le fera pas avec la configuration par défaut. Utilisez l'option supplémentaire --detect-proxy pour indiquer à cmk-agent-ctl d'utiliser un proxy configuré via les paramètres système.

Cependant, il est souvent plus simple d'identifier le port de l'Agent Receiver et de le noter. Pour ce faire, sur le serveur Checkmk, après vous être connecté en tant qu'utilisateur de l'instance, exécutez :

Vous pouvez désormais spécifier le port lors de la saisie de l'instruction d'enregistrement. Cela permet d'éviter la première requête vers l'API REST. La communication s'effectue alors directement avec l'Agent Receiver, sans détours :

Le port 8000 doit également être accessible depuis l'ordinateur hôte. Si ce n'est pas le cas, vous obtiendrez ce message d'erreur :

À l'instar du port 443 (ou 80) mentionné ci-dessus, vous pouvez désormais ajuster les paramètres de routage ou de pare-feu afin que l'ordinateur hôte puisse atteindre le serveur Checkmk sur le port de l'Agent Receiver (8000 ou 8001…​)

Dans le cas d'un enregistrement en mode Push, les règles suivantes s'appliquent : Si l'enregistrement a fonctionné, le transfert minute par minute de la sortie de l'agent sera également réussi.

Si les directives de sécurité interdisent l'accès à l'Agent Receiver, il est toujours possible d'utiliser l'enregistrement par proxy sur le serveur Checkmk.

Étant donné que le programme de l'agent doit être exécuté sous le compte LocalSystem afin de transmettre exactement les données qui parviennent à la supervision, vous ne devez jamais le lancer dans un shell. Si vous souhaitez examiner la sortie de l'agent localement, utilisez l'Agent Controller en mode dump (sous-commande dump). Cela lance le programme de l'agent avec l'environnement correct et sous l'ID utilisateur approprié, puis affiche le résultat.

La sortie pouvant être assez longue, le paginateur « more » s'avère très pratique dans ce cas. Vous pouvez quitter ce mode à l'aide de la touche Q :

Cela vous permet de vérifier que les données provenant du programme de l'agent sont bien parvenues au Agent Controller. Cette sortie ne prouve pas encore que l'agent est également accessible via le réseau.

Si, en mode Pull, il a été vérifié que le programme de l'agent et ses plugins installés s'exécutent correctement, vous pouvez ensuite vérifier via netcat (ou nc) si le port 6556 est accessible via l'adresse IP externe de l'ordinateur hôte :

La sortie 16 indique si la connexion a été établie avec succès et si la négociation TLS peut désormais avoir lieu. Étant donné que tout le reste est ici chiffré par TLS, aucune vérification plus détaillée n'est possible.

Si la communication entre l'agent et le serveur Checkmk n'est toujours pas chiffrée (comme en mode legacy pull) ou si elle est et reste non chiffrée (comme dans le cas d'un agent hérité), vous obtiendrez la sortie complète non chiffrée de l'agent avec cette instruction au lieu de l'16.

Pour effectuer d'autres diagnostics sur le serveur Checkmk, consultez l'article général sur les agents de supervision. Vous pouvez notamment effectuer un test de connexion à l'aide de l'interface Checkmk. Le résultat s'affichera dans la zone « Agent: ».

Si vous n'obtenez aucune information ou uniquement un message d'erreur de timeout lors du test de connexion, comme dans l'exemple ci-dessus, vous devez vérifier la configuration du pare-feu Windows sur l'ordinateur hôte.

L'agent crée déjà une règle dans le pare-feu Windows lors de son installation, afin que l'Agent Controller soit accessible depuis l'extérieur via le port 6556. Lorsque vous utilisez le mode Push, il n'est généralement pas nécessaire de modifier ses paramètres. Si vous utilisez une configuration de pare-feu très stricte, les règles sortantes pour les connexions au serveur de supervision doivent être configurées de manière à ce qu’au moins le port 8000 (pour faciliter l’enregistrement, ainsi que le 80 ou le 443) soit accessible.

Dans les versions actuelles de Windows, vous pouvez accéder à l'Windows Defender Firewall with Advanced Securityr via les Paramètres Windows (Settings > Windows Security) ou le lancer en exécutant l'instruction wf.msc depuis la ligne de commande :

Si vous ne trouvez pas cette entrée dans les paramètres du Pare-feu Windows, vous pouvez l'ajouter à cet emplacement précis. Pour ce faire, cliquez sur « New Rule » dans le menu « Action ».

Cela ouvre un assistant permettant de créer une nouvelle règle de pare-feu. Définissez les cinq options comme suit :

Vous pouvez également automatiser cette étape et définir la règle directement à partir de la ligne de commande. Modifiez l'instruction suivante en fonction de votre chemin d'accès personnalisé si nécessaire :

Remarque : l’instruction a été divisée en quatre lignes pour plus de lisibilité.

Dans le dossier « ~/var/agent-receiver/received-outputs/ » de votre instance Checkmk, vous trouverez, pour chaque ordinateur hôte enregistré, un lien symbolique dont le nom correspond à l’UUID de l’ordinateur hôte. Pour les ordinateurs hôtes en mode Push, ce lien symbolique pointe vers le dossier contenant la sortie de l’agent Checkmk ; pour les ordinateurs hôtes en mode Pull, il pointe vers un fichier inexistant portant le nom de l’ordinateur hôte tel qu’il est utilisé dans la supervision.

En fonction de l'ancienneté de la sortie de l'agent mis en cache, vous pouvez déterminer si la transmission régulière a abouti ou si elle est interrompue, par exemple par des problèmes réseau sporadiques.

De plus, vous pouvez consulter le fichier journal C:\ProgramData\checkmk\agent\log\check_mk sur l'ordinateur hôte (les chemins d'accès peuvent être configurés différemment). Des lignes telles que celles-ci indiquent des problèmes de connexion :

Si un ordinateur hôte a été configuré pour l'enregistrement automatique avec le jeu de règles Agent controller auto-registration et que l'option Keep existing connections est définie sur no, chaque fois que le service cmk-agent-ctl-daemon est redémarré (par exemple, lors du redémarrage d'un ordinateur hôte), toutes les autres connexions seront supprimées — à l'exception de la connexion configurée pour l'enregistrement automatique. Cela affecte, par exemple, les ordinateurs hôtes sur lesquels des connexions vers plusieurs instances ont été configurées avant l'installation du paquet d'agent précompilé, ou sur lesquels des connexions ont été ajoutées manuellement après l'installation du paquet d'agent.

Vous pouvez temporairement contourner ce comportement en définissant la variable keep_existing_connections sur true dans le fichier C:\ProgramData\checkmk\agent\pre_configured_connections.json sur l’ordinateur hôte. Vous pouvez obtenir une modification permanente lors d’une mise à jour du paquet d’agent en définissant Keep existing connections sur yes dans le jeu de règles ci-dessus.

Lors de l'enregistrement automatique d'un ordinateur hôte, il faut généralement compter environ deux minutes avant que l'ordinateur hôte n'apparaisse dans la supervision.

La sécurité est un critère important pour tout logiciel, et la supervision ne fait pas exception. Étant donné que l’agent de supervision est installé sur chaque serveur surveillé, un problème de sécurité aurait ici des conséquences particulièrement graves.

C'est pourquoi la sécurité a été mise en avant lors de la conception de Checkmk et constitue un principe absolu depuis les tout débuts de Checkmk : l'agent ne lit pas les données du réseau. Point final. Cela signifie qu'il est impossible pour un attaquant d'injecter des instructions ou des composants de script via le port de supervision 6556.

Pour un attaquant, cependant, même une liste de processus peut constituer un premier indice permettant de tirer des conclusions sur des cibles intéressantes. Par conséquent, le chiffrement de la couche de transport entre l’agent et le serveur Checkmk à l’aide du protocole Transport Layer Security (TLS) est obligatoire. Ici, le serveur Checkmk « ping » l’ordinateur hôte, qui établit alors la connexion TLS avec le serveur Checkmk et transmet la sortie de l’agent par ce biais. Étant donné que seuls les serveurs Checkmk avec lesquels une relation de confiance existe peuvent initier ce transfert de données, il n’y a aucun risque que les données tombent entre de mauvaises mains.

Pour sécuriser la connexion TLS, Checkmk utilise un certificat auto-signé qui est automatiquement remplacé peu avant l'expiration de sa validité. L'Agent Controller se charge du renouvellement du certificat à temps avant son expiration. Seuls les agents qui sont restés inactifs pendant une longue période, c'est-à-dire sans Agent Controller en cours d'exécution, peuvent perdre leur enregistrement à l'expiration et doivent alors être réenregistrés. La durée de vie du certificat peut être spécifiée via le paramètre global « Agent Certificates > Lifetime of certificates ».

Remarque : Étant donné qu’il n’y a pas d’Agent Controller, et donc pas de registre ni de chiffrement TLS, sur les très anciens systèmes Windows, vous devrez choisir d’autres méthodes de chiffrement si nécessaire. Dans ce cas, nous vous recommandons d’utiliser le chiffrement intégré (symétrique) via la règle Symmetric encryption (Linux, Windows).

La restriction de l'accès à des adresses IP spécifiques peut également être configurée via le pare-feu. Cependant, l'agent lui-même offre également la possibilité d'ignorer simplement les requêtes provenant d'adresses IP étrangères. Il suffit d'ajouter la restriction suivante au fichier de configuration dans les options globales. Notez qu'il peut y avoir d'autres paramètres définis dans le fichier de configuration avant ou après celui-ci et qu'il ne s'agit ici que d'un extrait :

Comme vous pouvez le voir dans l'exemple, vous pouvez autoriser un nombre illimité de sous-réseaux. Par exemple, avec /32, vous spécifiez un sous-réseau de taille 1, de sorte que seule cette adresse soit autorisée, tandis qu'avec 192.168.42.0/24, vous autorisez toutes les adresses comprises entre 192.168.42.0 et 192.168.42.255.

Dans la boulangerie d’agents, vous pouvez configurer les adresses IP autorisées à l’aide du jeu de règles suivant : Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Allowed agent access via IP address (Linux, Windows) .

En particulier lors de la mise à jour de l'agent, il se peut que le chiffrement intégré (symétrique) soit actif, lequel est effectué par le programme de l'agent lui-même. Si le chiffrement TLS et le chiffrement intégré sont actifs simultanément, l’entropie des données transmises est si élevée que la compression, active à partir de la version 2.1.0, ne permettra pas de réduire le volume des données transmises — et imposera aux processeurs de l’ordinateur hôte et du serveur Checkmk des processus de chiffrement et de déchiffrement supplémentaires.

C'est pourquoi vous devez désactiver le chiffrement intégré dès que possible après être passé à TLS.

Dans un premier temps, désactivez le chiffrement dans la règle existante sous Setup > Agents > Access to agents > Checkmk agent > Symmetric encryption (Linux, Windows).

Dans un deuxième temps, sur l'ordinateur hôte de l'agent, dans le fichier de configuration C:\ProgramData\checkmk\agent\check_mk.user.yml, remplacez la valeur du paramètre encrypted par no :

À la troisième et dernière étape, utilisez la règle « Enforce agent data encryption » pour spécifier que le serveur Checkmk n'accepte que les données chiffrées via TLS. Pour ce faire, sélectionnez la valeur « Accept TLS encrypted connections only » dans la règle.

La désactivation du chiffrement avec la boulangerie d’agents se déroule comme suit : Avec la première étape, qui consiste à modifier la règle « Symmetric encryption (Linux, Windows) », vous avez presque terminé. Il ne vous reste plus qu’à créer et à distribuer de nouveaux agents. Le fichier de configuration C:\ProgramData\checkmk\agent\check_mk.user.yml sera automatiquement modifié pour vous et inclus dans les paquets d’agents. Il ne reste plus que la troisième étape, à savoir la modification de la règle « Enforce agent data encryption ».

Après la prochaine mise à jour automatique de l'agent, le chiffrement du programme de l'agent sera désactivé, mais le chiffrement sera assuré par l'Agent Controller. Veuillez noter qu'après la mise à jour automatique de l'agent, seuls les ordinateurs hôtes enregistrés pourront fournir des données de supervision.

Le programme de l'agent check_mk_agent.exe contient un ensemble complet de sections qui fournissent des données de supervision pour divers plugins de supervision, lesquels sont ensuite automatiquement détectés par la reconnaissance du service. Cela inclut toutes les surveillances importantes du système d'exploitation.

De plus, il est possible d’étendre l’agent à l’aide de plugins d’agent. Il s’agit de petits scripts ou programmes appelés par l’agent qui l’étendent avec des sections supplémentaires contenant des données de supervision complémentaires. Le projet Checkmk fournit un certain nombre de ces plugins qui, s’ils sont correctement installés et configurés, fournissent automatiquement de nouveaux services dans la reconnaissance du service.

Pourquoi ces plugins ne sont-ils pas simplement intégrés en dur dans l’agent ? Pour chacun des plugins, l’une des raisons suivantes s’applique :

Les plug-ins inclus pour Windows se trouvent tous sur l’ordinateur hôte surveillé, dans le répertoire d’installation de l’agent, sous C:\Program Files (x86)\checkmk\service\plugins. Ils y sont stockés afin d’être directement disponibles. Les plug-ins pour Windows se trouvent également sur le serveur Checkmk, sous ~/share/check_mk/agents/windows/plugins.

Ils sont également disponibles depuis la page de téléchargement de l’agent dans le menu de configuration (comme décrit dans le chapitre Installation) dans la case Plugins :

Pour tous les plugins d'agent que nous fournissons, il existe des plugins de supervision correspondants qui peuvent évaluer leurs données et générer des services. Ceux-ci sont déjà installés, de sorte que les nouveaux services détectés sont immédiatement reconnus et peuvent être configurés.

Remarque : avant d'installer un plugin sur l'ordinateur hôte, consultez le fichier correspondant. Vous y trouverez souvent des informations importantes concernant l'utilisation correcte du plugin.

L'installation proprement dite est ensuite simple : Copiez le fichier dans C:\ProgramData\checkmk\agent\plugins.

Une fois que le plugin se trouve dans le répertoire approprié, il sera automatiquement appelé par l’agent et une nouvelle section sera créée dans la sortie de l’agent. Celle-ci porte généralement le même nom que le plugin. Les plugins complexes (par exemple mk_oracle.ps1) créent même tout un ensemble de nouvelles sections.

Certains plugins nécessitent un fichier de configuration dans C:\ProgramData\checkmk\agent\config pour fonctionner. Pour d’autres, la configuration est facultative (par exemple mssql.vbs) et permet d’activer des fonctionnalités spéciales ou des personnalisations. D’autres encore fonctionnent tout simplement ainsi. Vous disposez de plusieurs sources d’information :

Pour les langages spéciaux (de script), il peut être nécessaire de les activer au préalable dans la configuration de l'agent. Par exemple, les scripts Python ne seront pas exécutés à moins d'être explicitement activés. Vous pouvez le faire en ajoutant les extensions de fichiers dans le fichier de configuration check_mk.user.yml, dans la section global, comme indiqué dans l'extrait suivant :

Important : l'utilisation de tels plugins nécessite que les fichiers puissent également être appelés dans une ligne de commande standard sans chemins d'accès spéciaux. Dans le cas de Python, celui-ci doit être correctement installé et le chemin d'accès à l'interpréteur doit figurer dans les variables d'environnement. Vous trouverez des instructions sur la manière de configurer correctement Python directement sur les pages de la Python Software Foundation.

Chaque plugin peut être exécuté selon différents modes. Les options suivantes peuvent être saisies dans le fichier de configuration.

Une configuration du plugin Veeam ressemble alors par exemple à ceci (l'extrait est raccourci et ne contient que la partie pertinente pour l'exemple) :

Selon la configuration exemplaire ci-dessus, le plugin situé dans le répertoire de données C:\ProgramData\checkmk\agent\plugins est exécuté de manière asynchrone toutes les cinq minutes (300 secondes) et peut s'exécuter pendant deux minutes (120 secondes) au maximum. Si le plugin atteint ce timeout, il effectuera une deuxième tentative pour obtenir un résultat.

Dans les éditions commerciales, les plugins inclus peuvent être configurés via la boulangerie d’agents. Celui-ci se charge à la fois de l'installation du plugin lui-même et de la création correcte du fichier de configuration, si nécessaire.

Chaque plugin est configuré via une règle d'agent. Vous trouverez les jeux de règles appropriés dans Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Agent Plugins :

Les plugins d'agent étant des programmes exécutables, vous pouvez les lancer manuellement à des fins de test et de diagnostic. Cependant, certains plugins nécessitent que l'agent définisse certaines variables d'environnement pour trouver leur fichier de configuration, par exemple. Si nécessaire, définissez-les manuellement si elles sont requises dans le script ou le programme.

Il existe deux bonnes raisons de continuer à utiliser les plugins Nagios sous Checkmk. Si vous avez migré votre supervision d’une solution basée sur Nagios vers Checkmk, vous pouvez continuer à utiliser d’anciens plugins de supervision pour lesquels il n’existe pas encore d’équivalent Checkmk. Dans de nombreux cas, il s’agit de plugins développés en interne en Perl ou en shell.

La deuxième raison est la véritable supervision de bout en bout. Supposons que vous disposiez d’un serveur Checkmk, d’un serveur web et d’un serveur de base de données répartis dans un grand centre de données. Dans un tel cas, les temps de réponse du serveur de base de données mesurés depuis le serveur Checkmk ne sont pas très significatifs. Il est bien plus important de connaître ces valeurs pour la connexion entre le serveur web et le serveur de base de données.

L'agent Checkmk fournit un mécanisme simple pour répondre à ces deux exigences : le Remote Plugin Executor de Checkmk, ou MRPE en abrégé. Ce nom est délibérément une analogie avec le NRPE de Nagios, qui y remplit la même fonction.

Le MRPE est intégré à l’agent et est contrôlé par divers fichiers de configuration.

Au lieu de configurer directement sur un ordinateur hôte dans le fichier de configuration spécifique à l'utilisateur, vous pouvez également définir vos plug-ins MRPE directement dans le menu Setup. Pour ce faire, utilisez le jeu de règles « Setup > Agents > Windows, Linux, Solaris, AIX > Agent > Agent rules > Execute MRPE checks ». L'entrée nécessaire est alors automatiquement créée dans le fichier de configuration de la boulangerie d’agents.