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 (UPS), 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 appareils, le serveur Zabbix doit être configuré initialement avec la prise en charge SNMP en spécifiant l’option --with-net-snmp. Il est recommandé d’installer également les fichiers MIB afin de garantir que les valeurs des éléments s’affichent dans le format correct. 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.

Le serveur Zabbix et les démons proxy 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 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 (OID unique sous forme de numéro ou de 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 l'OID) de l'élément que vous souhaitez surveiller.

Pour obtenir une liste des chaînes SNMP, utilisez la commande snmpwalk (faisant 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 correspond ici à la version SNMP, vous pouvez également le remplacer par 1 pour indiquer la version 1 de SNMP sur le périphérique.

Cela devrait vous fournir une liste de chaînes SNMP et leur dernière valeur. Si ce n'est pas le cas, il est possible que la "community" SNMP soit différente de la valeur standard public, auquel cas vous devrez la déterminer.

Vous pouvez ensuite parcourir la liste jusqu'à trouver la chaîne que vous souhaitez surveiller, par exemple : si vous vouliez surveiller les octets entrants sur votre commutateur sur le port 3, vous utiliseriez la chaîne IF-MIB::ifHCInOctets.3 à partir 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 dans la chaîne est le numéro du port que vous cherchez à surveiller. Voir aussi : Index dynamiques.

Cela devrait vous donner quelque chose comme ce qui suit :

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

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

Dans l'exemple précédent, 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'un indice d'affichage.

Étape 2

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

Ajoutez une interface SNMP pour l'hôte :

1. Saisissez l'adresse IP/le nom DNS et le numéro de port.
2. Sélectionnez la version SNMP dans la liste déroulante.
3. Ajoutez les identifiants de l'interface en fonction de la version SNMP sélectionnée :
   • SNMPv1 et v2 nécessitent uniquement la communauté (généralement 'public').
   • SNMPv3 nécessite des options plus spécifiques ; voir SNMPv3.
4. Indiquez la valeur maximale de répétition (par défaut : 10) pour les requêtes SNMP bulk natives (GetBulkRequest-PDU) ; uniquement pour les éléments discovery[] et walk[] en SNMPv2 et v3. Notez qu'une valeur trop élevée peut entraîner un dépassement du délai d'attente de la vérification de l'agent SNMP.
5. 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").

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.

SNMPv3

Les paramètres suivants sont requis pour SNMPv3 :

• Nom de contexte - Saisissez le nom de contexte pour identifier l'élément sur le sous-réseau SNMP.
  Les macros utilisateur sont résolues dans ce champ.
• Nom de sécurité - Saisissez le nom de sécurité.
  Les macros utilisateur sont résolues dans ce champ.
• Niveau de sécurité - Sélectionnez le niveau de sécurité :
  • noAuthNoPriv - aucun protocole d'authentification ni de confidentialité n'est utilisé ;
  • AuthNoPriv - le protocole d'authentification est utilisé, pas le protocole de confidentialité ;
  • AuthPriv - les protocoles d'authentification et de confidentialité sont tous deux utilisés.
• Protocole d'authentification - Sélectionnez le protocole d'authentification : MD5, SHA1 ; avec net-snmp 5.8 et versions ultérieures SHA224, SHA256, SHA384 ou SHA512.
• Phrase secrète d'authentification - Saisissez la phrase secrète d'authentification.
  Les macros utilisateur sont résolues dans ce champ.
• Protocole de confidentialité - Sélectionnez le protocole de confidentialité : DES, AES128, AES192, AES256, AES192C (Cisco) ou AES256C (Cisco).
  Consultez les remarques sur la prise en charge du protocole de confidentialité.
• Phrase secrète de confidentialité - Saisissez la phrase secrète de confidentialité.
  Les macros utilisateur sont résolues dans ce champ.

En cas d'identifiants SNMPv3 incorrects (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 du protocole 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 est supprimée pour le package net-snmp.

• Les protocoles de chiffrement AES192 et plus forts ne sont pas pris en charge nativement 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 package 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 les protocoles AES192 et 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 supervision.

Revenez 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é un modèle ou non lors de la création de votre hôte, vous disposerez soit d’une liste d’éléments SNMP associés à votre hôte, soit d’une liste vide. Nous partirons du principe que vous allez créer vous-même l’élément à 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 obligatoires dans le formulaire du nouvel élément :

Tous les champs obligatoires sont signalés par un astérisque rouge.

Enregistrez maintenant l’élément, puis accédez à Supervision > Dernières données pour consulter 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 les périphériques SNMP pour obtenir plusieurs valeurs dans une seule requête. Cela concerne plusieurs types d'éléments SNMP :

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

Tous les éléments SNMP d'une même interface et ayant des paramètres identiques sont planifiés pour être interrogés au même moment. 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, deux types d'opérations sont effectués pour interroger les valeurs : l'obtention de plusieurs objets spécifiés et le parcours d'une arborescence d'OID.

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

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

• les éléments SNMP standard bénéficient des améliorations liées à « l'obtention » ;
• les éléments SNMP avec des index dynamiques bénéficient des améliorations liées à « l'obtention » et au « parcours » : « l'obtention » est utilisée pour vérifier l'index et le « parcours » pour créer le cache ;
• les règles de découverte de bas niveau SNMP bénéficient des améliorations liées au « parcours ».

Cependant, un problème technique se pose : tous les périphériques ne sont pas capables de renvoyer 128 valeurs par requête. Certains renvoient toujours une réponse correcte, tandis que d'autres renvoient soit une erreur « tooBig(1) », soit aucune réponse lorsque 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 par interroger 1 valeur par requête. Si l'opération réussit, il interroge 2 valeurs par requête. Si elle 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 de tailles de requête suivante : 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

Cependant, lorsqu'un périphérique refuse de fournir une réponse correcte (par exemple, pour 42 variables), Zabbix effectue deux opérations.

Tout d'abord, pour le lot d'éléments actuel, il divise par deux le nombre d'objets dans une seule requête et interroge 21 variables. Si le périphérique est disponible, la requête devrait fonctionner dans la grande majorité des cas, car il était établi que 28 variables fonctionnaient et que 21 est nettement inférieur à ce nombre. Toutefois, si cela échoue également, Zabbix revient à l'interrogation des valeurs une par une. Si cela échoue encore à ce stade, 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 opération effectuée par Zabbix pour les lots d'éléments suivants consiste à commencer par le dernier nombre de variables ayant réussi (28 dans notre exemple), puis à continuer d'augmenter la taille des requêtes de 1 jusqu'à atteindre la limite. Par exemple, en supposant que la taille de réponse maximale est de 32 variables, les requêtes suivantes auront les tailles 29, 30, 31, 32 et 33. La dernière requête échouera et Zabbix n'enverra 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 avoir deux causes. 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 que ce nombre de variables soit proche de la limite réelle de taille des réponses du périphérique dans le cas général : parfois la réponse est inférieure à la limite, parfois elle lui est supérieure. La deuxième possibilité est qu'un paquet UDP ait simplement été perdu dans l'une ou l'autre direction. Pour ces raisons, si Zabbix reçoit une requête ayant échoué, il réduit le nombre maximal de variables à essayer afin de se rapprocher de la plage confortable du périphérique, mais seulement deux fois au maximum.

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

Toutefois, si 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, un paramètre « Use combined requests » est disponible pour chaque interface afin 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 malformé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 distinctes pour chaque élément ; cela permet souvent d'éviter les faux pics. Vous pouvez également envisager d'utiliser des éléments get[] ou walk[] asynchrones, 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 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 présentée dans la section Vue d'ensemble afin d'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 d'OID.