3 agent SNMP

Vue d'ensemble

Vous pouvez souhaiter utiliser la supervision SNMP sur des appareils 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 d'essayer 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 appareils, le serveur Zabbix doit être configuré initialement 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 format correct. Sans les fichiers MIB, des problèmes de formatage peuvent survenir, par exemple l'affichage de valeurs en HEX au lieu d'UTF-8, ou inversement.

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

Les démons serveur et proxy Zabbix enregistrent 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 appareils 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éer un hôte correspondant à un périphérique.

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 informations d'identification 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).
• Indiquez la valeur maximale de répétition (par défaut : 10) pour les requêtes bulk SNMP 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élai d'attente du contrôle de l'agent SNMP.
• Cochez la case Utiliser des requêtes combinées pour autoriser le traitement combiné des requêtes SNMP (sans rapport avec les requêtes bulk SNMP natives "walk" et "get").

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

• Zabbix reçoit une erreur ERROR de net-snmp, sauf en cas de Phrase secrète de confidentialité incorrecte, auquel cas 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.

Revenez maintenant dans Zabbix et cliquez sur Items pour l'hôte SNMP que vous avez créé précédemment. Selon que vous ayez utilisé un modèle ou non lors de la création de votre hôte, vous aurez 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 Create item.

Renseignez les paramètres requis dans le nouveau formulaire d'élément :

Tous les champs obligatoires sont marqués d'un astérisque rouge.

Enregistrez maintenant l'élément, puis allez dans Monitoring > Latest data 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 Zabbix et le proxy 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 réguliers
• éléments SNMP avec des index dynamiques
• [règles de découverte de bas niveau] SNMP(/manual/discovery/low_level_discovery/examples/snmp_oids_walk)

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 par les pollers par lots d'au plus 128 éléments, tandis que les règles de découverte de bas niveau sont traitées individuellement, comme auparavant.

Au niveau inférieur, deux types d'opérations sont effectués pour l'interrogation des valeurs : obtenir plusieurs objets spécifiés et parcourir un arbre OID.

Pour l'opération "getting", un GetRequest-PDU est utilisé avec au plus 128 liaisons de variables. Pour l'opération "walking", un GetNextRequest-PDU est utilisé pour SNMPv1 et un GetBulkRequest avec un champ "max-repetitions" d'au plus 128 est utilisé pour SNMPv2 et SNMPv3.

Ainsi, les avantages du traitement combiné pour chaque type d'élément SNMP sont les suivants :

• les éléments SNMP réguliers bénéficient des améliorations de "getting" ;
• les éléments SNMP avec des index dynamiques bénéficient à la fois des améliorations de "getting" et de "walking" : "getting" est utilisé pour la vérification des index et "walking" pour la construction du cache ;
• les règles de découverte de bas niveau SNMP bénéficient des améliorations de "walking".

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 par requête. Si cela réussit, il interroge 2 valeurs par requête. Si cela réussit à nouveau, il interroge 3 valeurs par requête et continue de la même manière 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 effectue deux actions.

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 actif, la requête devrait fonctionner dans la grande majorité des cas, car 28 variables étaient connues pour fonctionner et 21 est nettement inférieur à cela. Cependant, si cela échoue encore, Zabbix revient alors à l'interrogation des valeurs une par une. Si cela échoue toujours à 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 action que Zabbix effectue pour les lots d'éléments suivants consiste à commencer avec le dernier nombre de variables ayant réussi (28 dans notre exemple) et à continuer d'augmenter la taille des requêtes 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 les requêtes volumineuses échouent avec ce nombre de variables, cela peut signifier l'une de deux choses. Les critères exacts utilisés par un périphérique pour limiter la taille des réponses ne peuvent pas être connus, mais nous essayons de les approximer à l'aide du nombre de variables. La première possibilité est donc que ce nombre de variables se situe à peu près à 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 l'un ou l'autre sens ait simplement été perdu. Pour ces raisons, si Zabbix obtient une requête en échec, il réduit le nombre maximal de variables à essayer afin de se rapprocher davantage de la plage 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 aussi, 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 à la perte de paquets UDP, 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 qui entraînent 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 empêche 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 Use combined requests par interface — ils peuvent être utilisés à la place des vérifications OID synchrones héritées pour éviter les problèmes liés aux requêtes combinées. Recherchez dans les journaux du serveur/proxy des entrées similaires à celle présentée dans la section Vue d'ensemble afin d'identifier les périphériques concernés.

De plus, 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.