2 Agent SNMP

Aperçu

Vous pouvez utiliser la supervision SNMP sur des périphériques 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 impossible 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 périphériques, le serveur Zabbix doit être configuré initialement avec le support SNMP.

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

Les démons du serveur Zabbix et des proxys interrogent les périphériques SNMP pour plusieurs valeurs dans une seule requête. Cela affecte tous les types d'éléments SNMP (éléments SNMP standard, éléments SNMP avec index dynamiques et découverte SNMP de bas niveau) et rend le traitement SNMP beaucoup plus efficace. Veuillez consulter la section des détails techniques ci-dessous pour savoir comment cela fonctionne en interne. Il existe également un paramètre "Utiliser les requêtes de masse" pour chaque interface qui permet de désactiver les requêtes groupées pour les périphériques qui ne peuvent pas les gérer correctement.

Les démons des serveurs Zabbix et des proxys inscrivent dans les logs zabbix les lignes similaires à ce qui suit 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'ils ne couvrent pas tous les cas problématiques, ils sont utiles pour identifier les périphériques SNMP individuels pour lesquels les requêtes de masse doivent être désactivées.

Le serveur Zabbix et les proxy vont toujours réessayer au moins une fois : soit via le mécanisme de nouvelle tentative de la bibliothèque SNMP, soit via le mécanisme interne de traitement des requêtes de masse.

Configuration de la surveillance SNMP

Pour démarrer la surveillance d'un appareil via SNMP, les étapes suivantes doivent être effectuées :

Étape 1

Découvrez la chaîne SNMP (ou OID) de l'élément que vous souhaitez surveiller.

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 outil équivalent :

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

Comme '2c' signifie ici la version SNMP, vous pouvez également le remplacer par '1', pour indiquer la version SNMP 1 sur l'appareil.

Cela devrait vous donner une liste de chaînes SNMP et leur dernière valeur. Si ce n'est pas le cas, il est possible que la 'communauté' SNMP soit différente du 'public' standard, auquel cas vous devrez trouver de quoi il s'agit.

Vous pouvez ensuite parcourir la liste jusqu'à ce que vous trouviez la chaîne que vous souhaitez surveiller, par ex. si vous vouliez surveiller les octets entrant dans votre commutateur sur le port 3, vous utiliseriez la chaîne IF-MIB::ifInOctets.3 de cette ligne :

IF-MIB::ifInOctets.3 = Counter32: 3409739121

Vous pouvez maintenant utiliser la commande snmpget pour connaître l'OID numérique de 'IF-MIB::ifInOctets.3' :

shell> snmpget -v 2c -c public -On 10.62.1.22 IF-MIB::ifInOctets.3

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

Cela devrait vous donner quelque chose comme ceci :

.1.3.6.1.2.1.2.2.1.10.3 = Counter32: 3472126941

Encore une fois, le dernier numéro de l'OID est le numéro de port.

Dans le dernier exemple ci-dessus, le type de valeur est "Counter32", qui correspond en interne au type ASN_COUNTER. 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 (depuis 2.2.8, 2.4.3). Ces types correspondent approximativement à "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" dans la sortie snmpget, mais peut également être affiché sous la forme "STRING", "Hex-STRING", "OID" et autre, en fonction de la présence d'un indicateur d'affichage.

Étape 2

Créez 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 le menu déroulant
• Ajoutez les informations d'identification de l'interface en fonction de la version SNMP sélectionnée :
  • SNMPv1, v2 ne nécessitent que la communauté (généralement 'public')
  • SNMPv3 nécessite des options plus spécifiques (voir ci-dessous)
• Laissez la case Utiliser les requêtes en masse cochée pour permettre le traitement en masse des requêtes SNMP

En cas d'informations d'identification SNMPv3 erronées (nom de sécurité, protocole d'authentification/phrase de passe, protocole de confidentialité), Zabbix reçoit une ERREUR de net-snmp, à l'exception d'une mauvaise phrase de passe de confidentialité, auquel cas Zabbix reçoit une erreur TIMEOUT de net-snmp.

Vous pouvez utiliser l'un des modèles SNMP fournis (Template SNMP Device et autres) qui ajoutera automatiquement un ensemble d'éléments. Cependant, le modèle peut ne pas être compatible avec l'hôte. Cliquez sur Ajouter pour enregistrer l'hôte.

Étape 3

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

Alors, revenez maintenant à 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 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 vous-même l'élément en utilisant les informations que vous venez de récolter à l'aide de snmpwalk et snmpget, cliquez donc sur Créer un élément. Dans le nouveau formulaire d'élément :

• Entrez le nom de l'article
• Remplacez le champ 'Type' par 'Agent SNMP'
• Entrez la 'Clé' comme quelque chose de significatif, par ex. SNMP-InOctets-Bps
• Assurez-vous que le champ 'Host interface' contient votre switch/routeur
• Entrez l'OID textuel ou numérique que vous avez récupéré précédemment dans le champ 'SNMP OID', par exemple : .1.3.6.1.2.1.2.2.1.10.3
• Définissez le 'Type d'informations' sur Numérique (flottant)
• Entrez un 'Intervalle de mise à jour' et une période de 'Stockage de l'historique' si vous voulez qu'ils soient différents de la valeur par défaut
• Dans l'onglet Preprocessing, ajoutez une étape Change per second (important, sinon vous obtiendrez des valeurs cumulées du périphérique SNMP au lieu de la dernière modification). Choisissez un multiplicateur personnalisé si vous en voulez un.

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

Enregistrez maintenant l'élément et accédez à Surveillance → Dernières données pour voir vos données SNMP !

Exemple 1

Exemple général :

Notez que l'OID peut être donné sous forme numérique ou sous forme de chaîne. Cependant, dans certains cas, la chaîne OID doit être convertie en représentation numérique. L'utilitaire snmpget peut être utilisé à cette fin :

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

Exemple 2

Surveillance de la disponibilité :

Native SNMP bulk requests

The walk[OID1,OID2,...] item allows to use native SNMP functionality for bulk requests (GetBulkRequest-PDUs), available in SNMP versions 2/3.

A GetBulk request in SNMP executes multiple GetNext requests and returns the result in a single response. This may be used for regular SNMP items as well as for SNMP discovery to minimize network roundtrips.

The SNMP walk[OID1,OID2,...] item may be used as the master item that collects data in one request with dependent ityems that parse the response as needed using preprocessing.

Note that using native SNMP bulk requests is not related to the option of combining SNMP requests, which is Zabbix own way of combining multiple SNMP requests (see next section).

Fonctionnement interne du traitement en masse

À partir de 2.2.3, le serveur Zabbix et le proxy interrogent les périphériques SNMP pour plusieurs valeurs en une seule requête. Cela affecte plusieurs types d'éléments SNMP :

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

Tous les éléments SNMP sur une seule interface avec des paramètres identiques sont programmé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, il existe deux types d'opérations effectuées pour interroger des valeurs : obtenir plusieurs objets spécifiés et parcourir une arborescence d'OID.

Pour le SNMP "get", une GetRequest-PDU est utilisée avec au plus 128 liaisons de variables. Pour le SNMP "walk", un GetNextRequest-PDU est utilisé pour SNMPv1 et GetBulkRequest avec un champ "max-repetitions" d'au plus 128 est utilisé pour SNMPv2 et SNMPv3.

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

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

Cependant, il existe un problème technique qui fait que tous les appareils ne sont pas capables de renvoyer 128 valeurs par requête. Certains renvoient toujours une réponse appropriée, mais d'autres répondent avec une erreur "tooBig(1)" ou ne répondent pas du tout une fois que la réponse potentielle dépasse une certaine limite.

Afin de trouver un nombre optimal d'objets à interroger pour un appareil 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 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, une fois qu'un appareil refuse de donner une réponse appropriée (par exemple, pour 42 variables), Zabbix fait deux choses.

Tout d'abord, 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 l'appareil est actif, la requête devrait fonctionner dans la grande majorité des cas, car 28 variables étaient connues pour fonctionner et 21, c'est nettement moins que cela. Cependant, si cela échoue toujours, Zabbix revient à interroger les valeurs une par une. S'il échoue toujours à ce stade, l'appareil ne répond définitivement pas et la taille de la demande n'est pas un problème.

La deuxième chose que Zabbix fait pour les lots d'éléments suivants est qu'il commence par le dernier nombre de variables réussi (28 dans notre exemple) et continue d'incrémenter les tailles de requête de 1 jusqu'à ce que la limite soit atteinte. Par exemple, en supposant que la plus grande taille de réponse est de 32 variables, les requêtes suivantes seront de tailles 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 plus 32 variables pour cet appareil.

Si de grandes requêtes échouent avec ce nombre de variables, cela peut signifier deux choses. Les critères exacts qu'un appareil utilise pour limiter la taille de la réponse ne peuvent pas être connus, mais nous essayons d'en faire une approximation en utilisant le nombre de variables. Ainsi, la première possibilité est que ce nombre de variables se situe autour de la limite de taille de réponse réelle de l'appareil dans le cas général : parfois la réponse est inférieure à la limite, parfois elle est supérieure à cela. La deuxième possibilité est qu'un paquet UDP dans l'une ou l'autre direction soit simplement perdu. Pour ces raisons, si Zabbix obtient une requête ayant échoué, il réduit le nombre maximum de variables pour essayer d'approfondir la plage confortable de l'appareil, mais (à partir de 2.2.8) jusqu'à deux fois seulement.

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 d'autres échecs sont dus à la perte de paquets UDP, plutôt qu'à la limite du périphérique.

Si, toutefois, un appareil ne peut pas gérer correctement les demandes groupées pour d'autres raisons et que l'heuristique décrite ci-dessus ne fonctionne pas, depuis Zabbix 2.4, il existe un paramètre "Utiliser les demandes groupées" pour chaque interface qui permet de désactiver les demandes groupées pour cet appareil.