Supervision via SNMP

Les routeurs, commutateurs, pare-feu, imprimantes, appliances, onduleurs, capteurs matériels et de nombreux autres appareils ne permettent pas l’installation d’un agent Checkmk. Ils disposent toutefois déjà d’une interface de supervision intégrée fournie par leur fabricant : un agent SNMP. Cet agent est accessible via le protocole SNMP (Simple Network Management Protocol). Checkmk utilise le SNMP pour surveiller ces appareils. L'avantage pour vous est que la configuration de la supervision est très simple.

Il existe également des agents SNMP pour Windows et Linux, mais il n’est pas recommandé de les utiliser à la place de l’agent Checkmk. Le protocole SNMP n’est pas très performant ; son utilisation pour la supervision implique donc généralement que le serveur Checkmk ait besoin de plus de ressources CPU et de mémoire par ordinateur hôte que lorsqu’il fonctionne avec son propre agent. De plus, les données fournies via SNMP sont incomplètes. Dans certains cas, cependant, la supervision via SNMP en complément de l’agent Checkmk peut s’avérer utile. Consultez le chapitre consacré au SNMP et à l’agent Checkmk pour en savoir plus sur ce thème.

Toutefois, s’il n’existe pas de plugin d’agent Checkmk pour la supervision d’un composant matériel ou logiciel particulier (par exemple, un contrôleur RAID), mais que ce composant dispose d’une interface SNMP, vous pouvez bien sûr collecter des données de supervision supplémentaires via SNMP. Dans ce cas, assurez-vous que les intervalles de requête sont suffisamment longs.

La supervision des périphériques SNMP avec Checkmk est très simple. Si vous souhaitez simplement vous lancer rapidement avec SNMP, vous devrez probablement lire la brève section consacrée à SNMP dans le guide du débutant. Cet article, en revanche, aborde le sujet de manière beaucoup plus approfondie et vous présente tous les détails ainsi que des scénarios spécifiques relatifs à la supervision SNMP avec Checkmk.

Le protocole SNMP est disponible en différentes versions. Ces protocoles sont tous incompatibles entre eux ; le système de supervision et le périphérique surveillé doivent donc toujours utiliser la même version du protocole. Checkmk prend en charge les versions v1, v2c et v3. Dans la pratique, on estime que 99 % des installations utilisent la version v2c. Voici un aperçu de toutes les versions pertinentes de SNMP :

Checkmk utilise des requêtes actives pour la supervision SNMP – une méthode de type « pull ». Checkmk envoie un paquet UDP (port 161) contenant une requête SNMP à l’appareil, lui demandant de fournir des données spécifiques. L’appareil répond alors par un paquet UDP contenant la réponse (ou un message d’erreur).

Le protocole SNMP comporte un deuxième processus : les traps SNMP. Il s'agit de messages push spontanés envoyés par les périphériques à des adresses configurées via UDP (port 162) en mode Push. Les traps présentent de nombreux inconvénients par rapport aux requêtes actives, ce qui explique pourquoi ils ne revêtent pas une grande importance pour la supervision. Voici quelques-uns de ces inconvénients :

Toutefois, si vous souhaitez ou devez travailler avec des traps, l'Event Console offre une solution. Celle-ci peut recevoir des traps et générer des événements à partir de ceux-ci.

La première étape consiste à préparer le périphérique. Chaque périphérique SNMP dispose de son propre masque de configuration quelque part dans ses paramètres. Effectuez les réglages suivants dans ce masque de configuration :

La communauté est une sorte de mot de passe, à l’exception que l’utilisateur n’a pas de nom pour le SNMP. La convention veut que la communauté soit public. C’est la valeur par défaut pour de nombreux appareils — et également pour Checkmk. Bien sûr, vous pouvez faire valoir que cela n’est pas sécurisé et qu’il faudrait spécifier une autre communauté. Cela est certes judicieux, mais vous devez savoir que le SNMP transmet la communauté en texte clair (avec une exception pour la version 3 du SNMP). Quiconque est en mesure d’intercepter les paquets peut donc très facilement identifier la communauté. D’autre part, votre accès est limité à la lecture seule, et la plupart des informations pouvant être récupérées via le SNMP ne sont pas très critiques.

De plus, l’utilisation de communautés différentes par appareil est très fastidieuse à gérer. En effet, celles-ci doivent non seulement être gérées au niveau des appareils, mais aussi au niveau du système de supervision. C’est pourquoi, dans la pratique, les utilisateurs utilisent généralement la même communauté partout — ou du moins partout au sein d’une région, d’un service, d’un centre de données, etc.

Si vous souhaitez renforcer la sécurité même sans SNMP version 3, il est judicieux d'étendre le concept de réseau de manière à placer le trafic des services de gestion, et donc également le SNMP, dans un VLAN de gestion distinct et à sécuriser cet accès à l'aide du pare-feu.

Ajoutez les périphériques surveillés en tant qu’ordinateurs hôtes dans Checkmk de la manière habituelle. Si vous avez choisi votre structure de dossiers de manière à ce qu’un seul dossier contienne les périphériques SNMP, vous pouvez effectuer les autres réglages directement dans ce dossier. Cela facilite l’ajout ultérieur d’ordinateurs hôtes supplémentaires et permet également d’éviter les erreurs.

Dans les propriétés de l'ordinateur hôte (ou du dossier), dans la case « Monitoring agents », définissez « Checkmk agent / API integrations » sur « No API integrations, no Checkmk agent ».

Dans la même case de dialogue, activez également l'option « SNMP » et sélectionnez « SNMPv2 or v3 » comme protocole SNMP. Le choix de la version 1 du protocole n'est qu'une solution de secours pour les appareils très anciens. Vous ne devriez l'utiliser que si vous savez que la version 2 n'est vraiment pas prise en charge, ou lorsque l'implémentation pour l'appareil est défectueuse (en pratique, uniquement dans des cas isolés). Surtout, la version 1 du protocole SNMP est très lente car elle ne prend pas en charge les accès en masse. Cette différence est très importante.

Le troisième et dernier paramètre s’appelle « SNMP credentials ». Ici encore, il est nécessaire de choisir la version du protocole, car les versions v2c et v3 diffèrent sur ce point. Nous aborderons la version 3 ci-dessous. Si vos exigences en matière de sécurité ne sont pas très élevées, la version v2c vous conviendra parfaitement — ou vous pouvez placer la communication SNMP dans un VLAN de gestion et ainsi la sécuriser. SNMPv2c nécessite la saisie de la communauté, comme indiqué ci-dessus.

Il existe une autre façon de configurer les identifiants SNMP si vous ne pouvez pas les faire passer facilement via votre structure de dossiers : le jeu de règles « Setup > Agents > SNMP rules > SNMP credentials of monitored hosts ». Cela vous permettra d’attribuer les identifiants en fonction des balises de l’hôte, des étiquettes et d’autres propriétés similaires. Le principe est qu’une communauté définie directement au niveau de l’hôte ou du dossier a toujours la priorité sur les règles.

Une fois les réglages terminés, vous pouvez faire un petit détour par la page de diagnostics. Pour ce faire, enregistrez à l'aide du bouton de la barre d'action «Save & go to connection test».

Voici un exemple de diagnostic pour un commutateur. Différentes versions du protocole SNMP sont testées simultanément, à savoir :

Un appareil moderne standard devrait répondre aux quatre variantes avec les mêmes données — toutefois, cela peut être limité en fonction de la configuration. Le résultat se présentera comme suit :

Les quatre informations fournies sont décrites ci-dessous :

En réalité, il semble que toutes les erreurs imaginables pouvant théoriquement être commises lors de la mise en œuvre du SNMP aient déjà été commises par un fabricant ou un autre à un moment ou à un autre. Il existe donc des appareils avec lesquels le SNMP fonctionne raisonnablement bien, mais certaines parties du protocole ne fonctionnent pas ou ont été mal implémentées.

Si les problèmes surviennent avec les éditions commerciales, cela peut s’expliquer en partie par le fait que l’implémentation SNMP inline, plus performante et activée par défaut, repose davantage sur le respect des normes que l’option « snmpget ». Si les appareils ne répondent pas du tout ou de manière instable, il est parfois utile de désactiver le SNMP inline pour les appareils concernés et d’activer ainsi l’option « snmpget », légèrement plus robuste mais nettement plus lente.

Pour les tests en ligne de commande, la commande cmk dispose, pour certaines options, de l'option supplémentaire --snmp-backend, qui accepte inline (utilisation du SNMP inline), classic (utilisation de l'snmpget) ou stored-walk (utilisation d'un SNMP walk enregistré) comme paramètres. Si le test en ligne de commande a réussi, vous pouvez utiliser le jeu de règles Hosts not using inline SNMP pour spécifier les ordinateurs hôtes qui ne doivent pas utiliser le SNMP inline de manière permanente.

Vous avez inclus un périphérique SNMP dans la supervision, mais Checkmk ne reconnaît que les services SNMP Info et SNMP Uptime ainsi que les interfaces. Cela peut être dû à plusieurs causes :

Si le test ping fonctionne, mais qu'aucune des versions du protocole SNMP ne fonctionne, plusieurs causes sont possibles :

Par défaut, le protocole SNMP n'est pas chiffré et son authentification est donc très faible, car la communauté est transmise en clair sur le réseau. Ce niveau peut toutefois suffire pour un réseau local isolé, car la supervision se limite ici à des opérations en lecture seule.

Si vous souhaitez néanmoins bénéficier d'un niveau de sécurité plus élevé, vous aurez besoin de la version 3 de SNMP. Celle-ci offre la possibilité de chiffrer les données et d'effectuer une authentification véritable. Pour cela, une configuration appropriée est toutefois nécessaire.

SNMPv3 reconnaît différents niveaux de sécurité :

Le paramétrage requis dans Checkmk s’effectue au même endroit où vous avez défini la communauté — soit dans les propriétés de l’ordinateur hôte, soit dans la règle d’SNMP credentials of monitored hosts. À cet endroit, au lieu de « SNMP Community », sélectionnez l’un des trois niveaux de la version 3 et configurez les valeurs nécessaires :

SNMPv3 introduit le concept de contextes. Un périphérique SNMP peut afficher des informations différentes à un même emplacement dans l’arborescence SNMP, selon l’ID de contexte spécifié dans la requête.

Si vous disposez d’un périphérique prenant en charge ces contextes, deux paramétrages sont nécessaires dans Checkmk :

Heureusement, les situations dans lesquelles vous devez travailler avec des contextes sont très rares, car la supervision ne peut malheureusement pas les reconnaître automatiquement. Une configuration manuelle des contextes est toujours nécessaire.

Les performances jouent toujours un rôle — en particulier dans les environnements comportant de nombreux ordinateurs hôtes — et la supervision via SNMP consomme davantage de CPU et de mémoire que celle effectuée par les agents Checkmk.

Alors que Checkmk Community effectue les requêtes SNMP de manière classique via les instructions « snmpget » ou « snmpbulkwalk », les éditions commerciales disposent d’un moteur SNMP intégré qui exécute les requêtes SNMP de manière très efficace sans générer de processus supplémentaires. Grâce à cela, la charge CPU liée au traitement SNMP est réduite de moitié environ. Les temps d’interrogation plus courts réduisent également le nombre de processus Checkmk nécessaires simultanément, et donc la charge de travail liée à l’utilisation de la mémoire.

Si vos ressources atteignent leurs limites, ou s’il faut plus de 60 secondes pour interroger un seul périphérique, vous pouvez réduire l’intervalle auquel Checkmk interroge le ou les ordinateurs hôtes. Grâce à l’ensemble de règles « Normal check interval for service checks », que vous appliquez spécifiquement aux services Checkmk des ordinateurs hôtes, vous pouvez étendre l’intervalle général d’une minute à, par exemple, 2 ou 5 minutes.

Pour les contrôles SNMP en particulier, il existe également le jeu de règles « Fetch intervals for SNMP sections ». Cela vous permet de réduire l'intervalle pour des plugins de supervision individuels. Il est important de savoir que vous ne pouvez jamais définir un intervalle plus court que celui utilisé pour la supervision générale par le service « Check_MK ».

Dans l'ensemble, nous recommandons toutefois de configurer la supervision de manière à ce que l'intervalle standard d'une minute puisse être maintenu, et qu'il ne soit augmenté que dans des cas exceptionnels pour des ordinateurs hôtes ou des checks individuels.

Par défaut, Checkmk attend une réponse en moins d’une seconde pour une requête SNMP. Il effectue également trois tentatives au total avant d’abandonner. Pour les appareils qui répondent très lentement ou qui ne sont accessibles que via un réseau très lent, il peut être nécessaire de modifier ces paramètres. Pour ce faire, utilisez le jeu de règles « Timing settings for SNMP access » :

Veuillez noter que ces paramètres s'appliquent à une requête SNMP individuelle. Le processus complet de supervision d'un ordinateur hôte se compose de nombreuses requêtes distinctes. Le timeout total est donc un multiple des paramètres spécifiés ici.

Par défaut, SNMP transmet 10 réponses dans un paquet par requête d’GetBulk. Essayez le jeu de règles « Bulk walk: Number of OIDs per bulk » pour voir si une valeur plus élevée offre de meilleures performances. Toutefois, cela ne sera le cas que lorsque de grands tableaux sont transférés vers l’ordinateur hôte — par exemple, s’il s’agit d’un commutateur doté de nombreux ports.

Le SNMP remplit toujours les paquets jusqu’au nombre spécifié, y compris les enregistrements qui suivent ceux réellement requis. Et si seuls quelques-uns de ces enregistrements sont réellement nécessaires, des données supplémentaires sont transférées inutilement et le dépassement augmente.

D'autre part, dans la pratique, il peut parfois arriver que des périphériques dont la valeur par défaut est de 10 OID par bloc rencontrent des problèmes. Dans un tel cas, il peut être utile de réduire ce nombre.

Checkmk fonctionne normalement en récupérant toujours les informations sur tous les ports du switch, même si tous ne sont pas réellement supervisés. C'est de toute façon une bonne chose, car cela est généralement plus rapide, les requêtes individuelles ne pouvant pas être effectuées avec les requêtes groupées efficaces. De plus, de notre point de vue, il est toujours conseillé de réaliser la supervision de tous les ports afin de détecter les ports défectueux ou les câbles présentant des taux d'erreur élevés. Si les ports ne sont pas fiables UP, vous pouvez également marquer l'état de la liaison DOWN comme étant OK.

Il existe toutefois des cas isolés où des commutateurs disposent d’un très grand nombre de ports et qui, pour une raison quelconque, répondent très lentement ou effectuent le processus de traitement du protocole SNMP de manière très inefficace, de sorte qu’il n’est plus possible d’effectuer la supervision avec une récupération complète de toutes les informations relatives aux ports.

Pour ces cas, il existe le jeu de règles « Bulk walk: Limit SNMP OID Ranges ». Cela vous permet de limiter de manière statique la liste des données interrogées (par exemple, les ports). Dans la valeur de la règle, pour chaque plugin de supervision particulier, vous spécifiez quels index de la table correspondante doivent être récupérés.

Le type de check habituel pour les ports du switch s’appelle « SNMP interface check with 64 bit counters (using v2c) ». L’exemple suivant montre un paramétrage dans lequel seuls les deux premiers ports sont récupérés via SNMP :

Remarque : ce filtrage s’applique avant la reconnaissance du service et la supervision des services. Selon le paramètre « Network interface and switch port discovery », cela ne signifie pas automatiquement que ces deux ports seront effectivement supervisés.

Le moteur SNMP de Checkmk dispose d’une fonctionnalité très pratique : vous pouvez demander à un périphérique surveillé d’enregistrer un snapshot complet de toutes ses données SNMP dans un fichier, ce qu’on appelle une « SNMP walk ». Vous pouvez ensuite utiliser ce fichier pour simuler la supervision du périphérique sur un autre serveur Checkmk, même si ce dernier n’est pas réellement connecté au périphérique via le réseau.

Nous utilisons cette fonctionnalité de manière très intensive, par exemple lorsque notre équipe d’assistance développe de nouveaux plugins de supervision pour nos clients. Nos développeurs n’ont donc pas besoin d’accéder à vos appareils — un simple SNMP walk suffit.

Vous pouvez créer une exploration SNMP directement depuis l’interface graphique. Cette fonction se trouve dans le menu d’action du service « Check_MK » des ordinateurs hôtes, ainsi que dans le menu d’action des ordinateurs hôtes (entrée « Download SNMP walk ») :

La création de la balade prend quelques secondes dans le meilleur des cas, mais il n’est pas rare que cela prenne quelques minutes. Une fois la création terminée, vous pouvez télécharger le fichier créé via la ligne « Result ».

Vous pouvez également créer des walks à partir de la ligne de commande. Connectez-vous à l'instance à partir de laquelle l'appareil est surveillé. La création du walk s'effectue simplement à l'aide de l'instruction cmk --snmpwalk et de l'ordinateur hôte spécifié (qui doit être configuré dans la supervision) :

Utilisez également l'option -v pour obtenir des informations plus détaillées sur la progression :

Le fichier sera placé dans le répertoire var/check_mk/snmpwalks, où il portera simplement le nom de l'ordinateur hôte. Il s'agit d'un fichier texte. Si vous êtes curieux, vous pouvez le consulter — par exemple, avec less ; quittez le programme à l'aide de la touche Q :

L'instruction cmk --snmpwalk dispose d'autres options utiles :

Si vous souhaitez utiliser ce parcours sur une autre instance Checkmk (ou sur la même) à des fins de simulation, enregistrez le fichier de parcours sous le nom de l'ordinateur hôte de l'instance dans le répertoire « var/check_mk/snmpwalks ». Assurez-vous que l'utilisateur de l'instance est le propriétaire du fichier et que les autorisations sont définies sur « 0600 » (seul le propriétaire est autorisé à lire et à écrire).

Créez maintenant une règle dans le jeu de règles « Simulating SNMP by using a stored SNMP walk » qui accède aux ordinateurs hôtes concernés.

Désormais, seul le fichier enregistré sera utilisé pour la supervision de l’ordinateur hôte. Il n’y a désormais plus d’accès réseau à l’ordinateur hôte, à l’exception du ping pour la vérification de l’ordinateur hôte et, éventuellement, de toute vérification active configurée. Vous pouvez simplement rediriger celles-ci vers le serveur Checkmk en attribuant l’adresse IP 127.0.0.1 aux ordinateurs hôtes.