2 Agent SNMP

Aperçu

Vous pouvez souhaiter utiliser la supervision SNMP sur des équipements tels que des imprimantes, des commutateurs réseau, des routeurs ou des onduleurs, qui sont généralement compatibles SNMP et sur lesquels il serait peu pratique de tenter d’installer des systèmes d’exploitation complets et des agents Zabbix.

Pour pouvoir récupérer les données fournies par les agents SNMP sur ces équipements, le serveur Zabbix doit être initialement configuré avec la prise en charge de SNMP en spécifiant l’option --with-net-snmp. Il est également recommandé d’installer les fichiers MIB afin de garantir que les valeurs des éléments soient affichées dans le bon format. Sans les fichiers MIB, des problèmes de formatage peuvent survenir, par exemple l’affichage des valeurs en HEX au lieu de UTF-8 ou inversement.

Les vérifications SNMP sont effectuées uniquement via le protocole UDP.

Les démons serveur et proxy Zabbix consignent des lignes similaires à la suivante s’ils reçoivent une réponse SNMP incorrecte :

SNMP response from host "gateway" does not contain all of the requested variable bindings

Bien qu’elles ne couvrent pas tous les cas problématiques, elles sont utiles pour identifier les équipements SNMP individuels pour lesquels les requêtes combinées doivent être désactivées.

Le serveur/proxy Zabbix réessaiera jusqu’à 5 fois pour les éléments SNMP walk et get. Le mécanisme de nouvelle tentative ne s’applique pas aux échecs de résolution DNS.

Pour les vérifications SNMP héritées (numéro OID unique ou chaîne), le serveur/proxy Zabbix réessaiera au moins une fois après une tentative de requête infructueuse : soit via le mécanisme de nouvelle tentative de la bibliothèque SNMP, soit via le mécanisme interne de traitement combiné.

Configuration de la supervision SNMP

Pour commencer à superviser un appareil via SNMP, les étapes suivantes doivent être effectuées :

Étape 1

Déterminez la chaîne SNMP (ou OID) de l’élément que vous souhaitez superviser.

Pour obtenir une liste des chaînes SNMP, utilisez la commande snmpwalk (qui fait partie du logiciel net-snmp, que vous devriez avoir installé dans le cadre de l’installation de Zabbix) ou un outil équivalent :

snmpwalk -v 2c -c public <host IP> .

Comme « 2c » représente ici la version SNMP, vous pouvez également le remplacer par « 1 », afin d’indiquer SNMP version 1 sur l’appareil.

Cela devrait vous fournir une liste des chaînes SNMP et de leur dernière valeur. Si ce n’est pas le cas, il est possible que la « communauté » SNMP soit différente de la valeur standard « public », auquel cas vous devrez déterminer laquelle est utilisée.

Vous pouvez ensuite parcourir la liste jusqu’à trouver la chaîne que vous souhaitez superviser, par exemple : si vous vouliez superviser les octets entrants sur le port 3 de votre commutateur, vous utiliseriez la chaîne IF-MIB::ifHCInOctets.3 de cette ligne :

IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

Vous pouvez maintenant utiliser la commande snmpget pour déterminer l’OID numérique de IF-MIB::ifHCInOctets.3 :

snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

Notez que le dernier nombre de la chaîne est le numéro du port que vous cherchez à superviser. Voir aussi : Index dynamiques.

Cela devrait vous donner quelque chose comme ceci :

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

Là encore, le dernier nombre de l’OID est le numéro du port.

Dans le dernier exemple ci-dessus, le type de valeur est « Counter64 », ce qui correspond en interne au type ASN_COUNTER64. La liste complète des types pris en charge est ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR et ASN_OBJECT_ID. Ces types correspondent approximativement à « Counter32 », « Counter64 », « UInteger32 », « INTEGER », « Float », « Double », « Timeticks », « Gauge32 », « IpAddress », « OCTET STRING », « OBJECT IDENTIFIER » dans la sortie de snmpget, mais peuvent aussi être affichés comme « STRING », « Hex-STRING », « OID » et autres, selon la présence d’une indication d’affichage.

Étape 2

Créez un hôte correspondant à un appareil.

Ajoutez une interface SNMP pour l'hôte :

• Saisissez l'adresse IP/le nom DNS et le numéro de port.
• Sélectionnez la version SNMP dans la liste déroulante.
• Ajoutez les identifiants de l'interface en fonction de la version SNMP sélectionnée :
  • SNMPv1, v2 nécessitent uniquement la communauté (généralement « public »).
  • SNMPv3 nécessite des options plus spécifiques (voir ci-dessous).
• Spécifiez la valeur de répétition maximale (par défaut : 10) pour les requêtes SNMP bulk natives (GetBulkRequest-PDUs) ; uniquement pour les éléments discovery[] et walk[] en SNMPv2 et v3. Notez qu'une valeur trop élevée peut provoquer un dépassement du délai d'attente de la vérification de l'agent SNMP.
• Cochez la case Utiliser des requêtes combinées pour autoriser le traitement combiné des requêtes SNMP (sans lien avec les requêtes SNMP bulk natives « walk » et « get »).

En cas d'identifiants SNMPv3 incorrects (nom de sécurité, protocole/phrase secrète d'authentification, protocole de confidentialité) :

• Zabbix reçoit une ERROR de net-snmp, sauf en cas de phrase secrète de confidentialité incorrecte, où Zabbix reçoit une erreur TIMEOUT de net-snmp.
• La disponibilité de l'interface SNMP passera au rouge (indisponible).

Vous pouvez utiliser l'un des modèles SNMP fournis, qui ajoutera automatiquement un ensemble d'éléments. Avant d'utiliser un modèle, vérifiez qu'il est compatible avec l'hôte.

Cliquez sur Ajouter pour enregistrer l'hôte.

Prise en charge des protocoles de confidentialité

Selon votre système d’exploitation et la configuration de net-snmp, certains protocoles de confidentialité peuvent ne pas être disponibles :

• Sur certains systèmes d’exploitation plus récents (par exemple, RHEL9), la prise en charge de DES a été abandonnée dans le paquet net-snmp.

• Les protocoles de chiffrement AES192 et supérieurs ne sont pas pris en charge prêts à l’emploi sur les systèmes d’exploitation antérieurs à RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.

Pour vérifier si la bibliothèque net-snmp prend en charge AES192+, utilisez l’une des options suivantes :

1. net-snmp-config :

net-snmp-config --configure-options

Si la sortie contient --enable-blumenthal-aes, AES192+ est pris en charge.

Notez que net-snmp-config fait partie du paquet de développement pour SNMP (libsnmp-dev pour Debian/Ubuntu, net-snmp-devel pour CentOS/RHEL/OL/SUSE) et peut ne pas être installé par défaut.

2. snmpget :

snmpget -v 3 -x AES-256

Si la sortie contient Invalid privacy protocol specified after -3x flag: AES-256, AES192+ n’est pas pris en charge. Si la sortie contient No hostname specified., AES192+ n’est pas pris en charge.

Si votre bibliothèque net-snmp ne prend pas en charge AES192 et les protocoles supérieurs, recompilez net-snmp avec l’option --enable-blumenthal-aes, puis recompilez le serveur Zabbix en spécifiant l’option --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.

Étape 3

Créez un élément pour la surveillance.

Retournez maintenant dans Zabbix et cliquez sur Éléments pour l’hôte SNMP que vous avez créé précédemment. Selon que vous avez utilisé ou non un modèle lors de la création de votre hôte, vous verrez soit une liste d’éléments SNMP associés à votre hôte, soit simplement une liste vide. Nous partirons du principe que vous allez créer l’élément vous-même à l’aide des informations que vous venez de recueillir avec snmpwalk et snmpget ; cliquez donc sur Créer un élément.

Renseignez les paramètres requis dans le formulaire du nouvel élément :

Tous les champs de saisie obligatoires sont marqués d’un astérisque rouge.

Enregistrez maintenant l’élément et allez dans Surveillance > Dernières données pour vos données SNMP.

Exemple 1

Exemple général :

Notez que l’OID peut être fourni sous forme numérique ou textuelle. Cependant, dans certains cas, l’OID textuel doit être converti en représentation numérique. L’utilitaire snmpget peut être utilisé à cette fin :

snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

Exemple 2

Surveillance du temps de fonctionnement :

Requêtes SNMP groupées natives

L’élément walk[OID1,OID2,...] permet d’utiliser la fonctionnalité SNMP native pour les requêtes groupées (GetBulkRequest-PDUs), disponible dans les versions 2/3 de SNMP.

Une requête GetBulk en SNMP exécute plusieurs requêtes GetNext et renvoie le résultat dans une seule réponse. Cela peut être utilisé pour les éléments SNMP classiques ainsi que pour la découverte SNMP afin de réduire le nombre d’allers-retours réseau.

L’élément SNMP walk[OID1,OID2,...] peut être utilisé comme élément maître qui collecte les données en une seule requête, avec des éléments dépendants qui analysent la réponse selon les besoins à l’aide du prétraitement.

Notez que l’utilisation de requêtes SNMP groupées natives n’est pas liée à l’option de combinaison des requêtes SNMP, qui est la méthode propre à Zabbix pour combiner plusieurs requêtes SNMP (voir la section suivante).

Jusqu’à cinq nouvelles tentatives seront effectuées pour les éléments SNMP groupés afin d’éviter un échec si l’un des paquets est perdu. Le délai d’expiration des éléments SNMP avec get et walk (défini dans le formulaire de configuration de l’élément) s’applique à l’ensemble d’une session. Le délai d’expiration s’applique indépendamment du fait que les données soient récupérées complètement ; si les données ne sont reçues que partiellement (par exemple, si les données ne sont collectées avec succès que pour un seul des multiples OID), alors l’élément devient non pris en charge avec le message « Only partial data received ». Si le délai d’expiration est atteint, une nouvelle tentative aura lieu, le délai sera réinitialisé et la dernière requête sera renvoyée, ce qui permettra de poursuivre la session à partir de la dernière requête si un seul paquet est perdu ou arrive trop tard. Envisagez de définir une valeur de délai d’expiration faible afin d’éviter de longs retards si l’appareil est inaccessible, car jusqu’à 5 nouvelles tentatives seront effectuées si les précédentes expirent ou échouent (par exemple, un délai d’expiration de 3 secondes peut entraîner un temps d’attente de 15 secondes).

Fonctionnement interne du traitement combiné

Le serveur et le proxy Zabbix peuvent interroger des périphériques SNMP pour plusieurs valeurs dans une seule requête. Cela affecte plusieurs types d’éléments SNMP :

• éléments SNMP classiques
• éléments SNMP avec index dynamiques
• règles de découverte de bas niveau SNMP

Tous les éléments SNMP sur une même interface avec des paramètres identiques sont planifiés pour être interrogés en même temps. Les deux premiers types d’éléments sont pris en charge par les pollers par lots de 128 éléments au maximum, tandis que les règles de découverte de bas niveau sont traitées individuellement, comme auparavant.

À un niveau inférieur, il existe deux types d’opérations effectuées pour interroger les valeurs : l’obtention de plusieurs objets spécifiés et le parcours d’un arbre OID.

Pour « l’obtention », un GetRequest-PDU est utilisé avec au maximum 128 liaisons de variables. Pour le « parcours », un GetNextRequest-PDU est utilisé pour SNMPv1, et GetBulkRequest avec un champ « max-repetitions » de 128 au maximum est utilisé pour SNMPv2 et SNMPv3.

Ainsi, les avantages du traitement combiné pour chaque type d’élément SNMP sont décrits ci-dessous :

• les éléments SNMP classiques bénéficient des améliorations de « l’obtention » ;
• les éléments SNMP avec index dynamiques bénéficient à la fois des améliorations de « l’obtention » et du « parcours » : « l’obtention » est utilisée pour la vérification des index et le « parcours » pour construire le cache ;
• les règles de découverte de bas niveau SNMP bénéficient des améliorations du « parcours ».

Cependant, il existe un problème technique : tous les périphériques ne sont pas capables de renvoyer 128 valeurs par requête. Certains renvoient toujours une réponse correcte, mais d’autres répondent soit avec une erreur « tooBig(1) », soit ne répondent pas du tout dès que la réponse potentielle dépasse une certaine limite.

Afin de trouver un nombre optimal d’objets à interroger pour un périphérique donné, Zabbix utilise la stratégie suivante. Il commence prudemment en interrogeant 1 valeur dans une requête. Si cela réussit, il interroge 2 valeurs dans une requête. Si cela réussit à nouveau, il interroge 3 valeurs dans une requête et continue de manière similaire en multipliant le nombre d’objets interrogés par 1,5, ce qui donne la séquence suivante de tailles de requête : 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

Cependant, dès qu’un périphérique refuse de fournir une réponse correcte (par exemple, pour 42 variables), Zabbix fait deux choses.

Premièrement, pour le lot d’éléments en cours, il divise par deux le nombre d’objets dans une seule requête et interroge 21 variables. Si le périphérique est joignable, alors la requête devrait fonctionner dans la grande majorité des cas, car 28 variables étaient connues pour fonctionner et 21 est nettement inférieur à cette valeur. Cependant, si cela échoue encore, Zabbix revient à l’interrogation des valeurs une par une. Si cela échoue encore à ce stade, alors le périphérique ne répond définitivement pas et la taille de la requête n’est pas en cause.

La deuxième chose que fait Zabbix pour les lots d’éléments suivants est de commencer avec le dernier nombre de variables ayant réussi (28 dans notre exemple) et de continuer à incrémenter les tailles de requête de 1 jusqu’à atteindre la limite. Par exemple, en supposant que la plus grande taille de réponse soit de 32 variables, les requêtes suivantes auront des tailles de 29, 30, 31, 32 et 33. La dernière requête échouera et Zabbix n’émettra plus jamais de requête de taille 33. À partir de ce moment, Zabbix interrogera au maximum 32 variables pour ce périphérique.

Si de grandes requêtes échouent avec ce nombre de variables, cela peut signifier l’une des deux choses suivantes. Les critères exacts qu’un périphérique utilise pour limiter la taille de réponse ne peuvent pas être connus, mais nous essayons de les approximer à l’aide du nombre de variables. La première possibilité est que ce nombre de variables soit proche de la limite réelle de taille de réponse du périphérique dans le cas général : parfois la réponse est inférieure à la limite, parfois elle la dépasse. La deuxième possibilité est qu’un paquet UDP dans un sens ou dans l’autre ait simplement été perdu. Pour ces raisons, si Zabbix obtient une requête échouée, il réduit le nombre maximal de variables afin d’essayer de revenir plus profondément dans la plage de fonctionnement confortable du périphérique, mais seulement jusqu’à deux fois.

Dans l’exemple ci-dessus, si une requête avec 32 variables échoue, Zabbix réduira le nombre à 31. Si cela échoue également, Zabbix réduira le nombre à 30. Cependant, Zabbix ne réduira pas le nombre en dessous de 30, car il supposera que les échecs supplémentaires sont dus à des paquets UDP perdus, plutôt qu’à la limite du périphérique.

Si, toutefois, un périphérique ne peut pas gérer correctement les requêtes combinées pour d’autres raisons et que l’heuristique décrite ci-dessus ne fonctionne pas, il existe un paramètre « Use combined requests » pour chaque interface qui permet de désactiver les requêtes combinées pour ce périphérique.

Si les requêtes combinées provoquent des réponses partielles ou mal formées entraînant des calculs incorrects par seconde (delta) (par exemple, des pics apparents dans les compteurs d’interface), désactivez Use combined requests pour l’interface concernée afin de forcer des requêtes séparées par élément ; cela évite souvent les faux pics. Vous pouvez également envisager d’utiliser des éléments asynchrones get[] ou walk[], qui sont exécutés de manière asynchrone et ne sont pas soumis au regroupement par interface de Use combined requests — ils peuvent être utilisés à la place des vérifications OID synchrones héritées afin d’éviter les problèmes liés aux requêtes combinées. Recherchez dans les journaux du serveur/proxy des entrées similaires à celle affichée dans la section Vue d’ensemble pour aider à identifier les périphériques concernés.

En outre, si l’interface devient fréquemment indisponible, il peut être nécessaire d’augmenter le paramètre UnavailableDelay dans les fichiers de configuration du serveur Zabbix ou du proxy Zabbix afin de réduire la fréquence des requêtes. Les éléments peuvent devenir non pris en charge si des données partielles sont reçues pendant la découverte ou les parcours OID.