Quels sont les périphériques réseau surveillés par Zabbix 3.0 ?-Sécurité-php.cn

Introduction à SNMP

1 Présentation de SNMP

SNMP s'est développé pour devenir le protocole de gestion de réseau le plus utilisé. Les versions actuellement appliquées incluent principalement SNMP v1, SNMP v2c et SNMP v3. Les principales différences entre les versions résident dans la définition des informations, le fonctionnement des protocoles de communication et le mécanisme de sécurité. Parallèlement, deux extensions des applications SNMP, RMON (Remote Network Monitoring) et RMON2, sont également apparues.

Du point de vue de la couche physique, l'utilisation de SNMP pour gérer le réseau doit inclure : la station de gestion réseau (NMS), l'agent (agent) et le serveur proxy (proxy). Dans la gestion de réseau, au moins un NMS est requis pour émettre des instructions et recevoir des informations de notification. Les agents peuvent répondre aux demandes des nœuds de gestion et peuvent également générer de manière proactive des informations de notification. Il peut y avoir un ou plusieurs agents dans la gestion du réseau. Le proxy transmet les requêtes SNMP et les messages de notification entre différents réseaux ou différentes versions.

Du point de vue de la couche protocolaire, SNMP comprend : SMI (Structure of Management Information, Management Information Structure) et MIB (Management Information Base, Management Information Base). SMI est un sous-ensemble d'ASN.1 (Abstract SyntaxNotation one). SMI stipule que les éléments, types de données personnalisés et macros en ASN.1 peuvent être utilisés dans SNMP. Ces éléments, types de données, macros et autres syntaxes associées peuvent être utilisés pour définir. MIB dans SNMP. MIB est une description abstraite des objets gérables dans Agent. Dans SNMP, MIB est organisé et visualisé dans une structure arborescente. Chaque nœud de l'arborescence est appelé un OID (Object Identifier). Il est organisé d'une manière similaire à un nom de domaine de site Web, et chaque nœud est représenté par un certificat, tel qu'un certificat. comme 1.3.

SNMP est un protocole de couche application appartenant à la pile de protocoles TCP/IP, similaire aux protocoles HTTP et FTP. C'est juste que la couche de transport SNMP utilise le protocole UDP.

Dans SNMP v1, un mode d'authentification simple du NMS à l'agent est fourni : Communauté Lorsque le NMS envoie une demande à l'agent, il doit fournir une chaîne de communauté. Après avoir reçu la chaîne, l'agent doit vérifier si elle est cohérente avec la chaîne locale. un. Il existe des risques de sécurité évidents dus à l'utilisation de texte clair pour transférer la Communauté.

En 1996, l'IETF a publié SNMP v2c (Community-BasedSNMP v2), qui définissait la communication entre les stations de gestion basée sur la v1. Toutes prennent en charge la gestion de réseau distribuée, mais le mécanisme de sécurité est toujours le même que celui de la v1.

En 1998, l'IETF a publié SNMP v3, qui a étendu la sécurité (modèle de sécurité basé sur l'utilisateur et modèle de contrôle d'accès basé sur la vue) et les mécanismes de gestion basés sur SNMP v2. En termes de sécurité, la version v3 ajoute des paramètres de sécurité aux messages du protocole, permettant une transmission cryptée et une vérification obligatoire des messages. Il s'agit d'un protocole sécurisé. SNMP v3 utilise l'idée modulaire pour définir chaque module composant du protocole, améliore l'architecture du protocole et, surtout, reste compatible avec SNMP v1 et SNMP v2.

2 Fonctions de SNMP

L'agent dans SNMP est principalement responsable du téléchargement des informations. En plus des fonctions de niveau du protocole SNMP, NMS a également les fonctions de journalisation des informations envoyées et reçues, d'enregistrement et de gestion des informations de notification, et configuration. Et peut fournir une configuration graphique et une interface de gestion.

Afin de réaliser ces fonctions, SNMP contient une série de commandes d'opération, notamment :

Commandes de lecture : obtenez des commandes de série, NMS envoie des requêtes pour collecter des informations de gestion comme l'agent.
Commande Set : commande Set, NMs écrit les données contenues dans le message dans l'agent.
Fonction d'alarme : série de pièges, l'agent envoie activement des informations de message d'alarme/événement au NMS.

Zabbix 3.0监控网络设备有哪些

Figure 13-1

1. Opération Get

L'opération Get est une opération activement initiée par NMS. En plus de l'indicateur de demande Get, le message envoyé comprend également la paire nom et valeur de l'OID à demander, et les informations sur l'objet de gestion sont transférées sous la forme d'une liaison de cette paire nom et valeur. Bien entendu, la valeur correspondant à OID dans l’opération Get est NILL.

2. Opération Get-Next

L'opération Get-Next est similaire à la fonction Get. La différence est que les informations interrogées ne sont pas les informations OID liées dans le message mais les informations OID suivantes de l'objet (si le suivant est le suivant). Les informations OID sont lisibles). Par exemple, NMS souhaite collecter les informations de sysLocation, le nœud suivant de sysName côté agent. Dans le message de demande, il s'agit de sysName.0 et le message renvoyé est lié à sysLocation.0 et à la valeur.

3. L'opération Get-Bulk

est en fait un ensemble de plusieurs opérations Get-Next, qui est une nouvelle méthode d'opération ajoutée dans SNMP v2.

4. Opération de réglage

L'opération de réglage peut définir des paramètres pour les OID avec des autorisations d'écriture pour réaliser la gestion des paramètres, la configuration et le contrôle de l'appareil. Différent des variables de liaison de l’opération Get, Set doit lier la valeur du paramètre OID correspondant.

5. Get-Response

Get-Response est une réponse aux commandes Get et Set de NMS. En fonction de la commande et des paramètres de la commande, les informations de liaison de variable de retour correspondantes et les informations sur l'état d'erreur (indiquent le succès de l'exécution de la commande. ou échec), etc.

6. Série Trap

Trap est un mécanisme permettant à l'agent de signaler de manière proactive les événements importants au NMS. Pour de tels rapports, le NMS n'a pas besoin de répondre à l'agent. Le contenu des informations sur le piège indique ce qui s'est passé, à quel moment et où.

3 SMI et MIB

1, SMI

SMI est un module d'information défini dans la syntaxe ASN.1 dans SNMP et est un sous-ensemble d'ASN.1. Ces modules contiennent de nombreuses macros spécifiques à SNMP, des types de données et des règles personnalisées, etc. La définition de ces macros, types de données et règles a trois objectifs principaux : l'un est de représenter et de définir des types de données uniques dans les applications SNMP ; l'autre est de simplifier la méthode de définition des objets de gestion ; le troisième est d'allouer l'espace d'identification des objets ; et des objets de gestion dans la méthode de codage SNMP. SNMP s'appuie sur ces modules d'information définis dans les documents RFC pour standardiser le protocole, permettant ainsi à diverses organisations, entreprises et individus de maintenir une cohérence lors de la définition des objets de gestion.

Dans SNMP, deux versions de SMI sont actuellement définies, à savoir SMI v1 défini dans la RFC 1151 et SMI v2 défini dans la RFC 2578. Dans SMI v1, plusieurs types de données, descriptions de règles, macros OBJECT-TYPE, etc. sont simplement définis. Dans SMI v2, tout le contenu associé est entièrement organisé de manière modulaire.

Les types de données de base définis dans SMI v1 sont :

INTEGER : Il s'agit en fait d'un entier de 32 bits.
OCTET STRING : 0 ou plusieurs caractères de 8 bits (un seul octet), qui peuvent représenter des caractères de texte ou des adresses physiques. La plage de valeurs va de 0 à 65535.
IDENTIFIANT DE L'OBJET : OID exprimé en notation décimale pointée.
NULL : Il est uniquement défini dans SMI v1 et n'est plus utilisé dans SMI v2.
SEQUENCE : Liste de définitions.
SEQUENCE DE : Définir le tableau.

Dans SMI v2, les limitations de portée et les mises à jour des types de données ci-dessus sont davantage clarifiées, et le type BITS est également introduit.

Les types de données personnalisés dans SMI v1 incluent :

NetworkAddress (adresse réseau), qui peut être une famille d'adresses réseau autre qu'Internet, # Adresse IP 32 bits en octets réseau Représentation séquentielle

IPAddress ::= [APPLICATION 0 ] CHAÎNE D'OCTETS IMPLICITE (TAILLE (4))

#🎜 🎜#

# 🎜🎜#

La valeur du type de jauge peut être augmentée ou diminuée, atteignant le maximum. La valeur est maintenue à la valeur maximale. Par exemple, le débit de l'interface dans le routeur peut être représenté par ce type.

Gauge::= [APPLICATION 2]ENTIER IMPLICITE (0.. 4294967295)

TimeTicks utilise 0,01 seconde comme unité de chronométrage, indiquant l'intervalle de temps entre deux points temporels. Nécessite que la base de synchronisation soit indiquée dans la description.

TimeTicks ::= [ APPLICATION 3 ] ENTIER IMPLICITE (0.. 4294967295)

Opa que Les valeurs codées par d'autres types ASN.1 sont encapsulées deux fois. Pour des raisons de compatibilité descendante, ce type est également défini dans SMIv2 et n'est pas recommandé.

Opaque ：：= [APPLICATION 4 ] CHAÎNE D'OCTETS IMPLICITE

Les types de données personnalisés qui ont changé dans SMI v2 par rapport à SMI v1 sont :

Gauge32 et Gauge sont en fait identiques. Gauge32 et Unsigned32 partagent la même balise de type d'application, leur encodage est donc essentiellement identique.

Gauge32 ::= [APPLICATION 2 ] ENTIER IMPLICITE (0.. 4294967295)

Unsigned32 ::= [APPLICATION 2 ] INTEG IMPLICITE ER (0..4294967295)

Counter64 est un compteur à plus grande portée, il y en a 64 : 2^64-1 (0..18446744073709551615). Counter32 est utilisé dans le module MIB standard uniquement lorsque le compteur revient à 0 en moins d'1 heure.

Counter64 ::= [ APPLICATION6 ] IMPLICIT INTEGER (0..18446744073709551615)

Le type IPAddress est toujours conservé dans SMI v2, et ne contient aucune modification. Cependant, cela ne s'applique pas à l'adresse 128 bits d'IPv6. Une explication supplémentaire de Counter32 : La valeur de comptage actuelle n'a une signification claire que lorsqu'il existe une valeur initiale et un changement enregistré.

Du point de vue de MIB, SMI est une charte qui guide directement la définition de MIB, définit le type de données et la syntaxe de MIB et alloue un espace OID pour les objets de gestion dans MIB.

MIB est un ensemble d'informations de gestion basées sur les besoins de l'entreprise ou sur la gestion du réseau. Standard exigences, fichiers texte structurés rédigés conformément aux règles organisationnelles convenues et à la syntaxe de définition.

Chaque objet de gestion dans la base d'informations de gestion (MIB) doit décrire clairement tous ses attributs, y compris le nom, la description, le type de données et d'autres informations. Les parties communicantes peuvent identifier le contenu de ces propriétés grâce à l'identifiant unique (OID) de l'objet. En d'autres termes, MIB est un pont de communication entre NMS et l'agent. Ce n'est que lorsque l'agent implémente la MIB et que NMS connaît la MIB que les deux peuvent fonctionner correctement ensemble pour implémenter les fonctions de gestion correspondantes. Ce n'est qu'après l'importation de la MIB dans NMS que NMS peut connaître tous les détails des objets à gérer. Si l'objet de gestion défini dans la MIB est implémenté dans l'agent, l'agent prend en charge la MIB.

Un agent peut implémenter plusieurs MIB, et chaque MIB peut contenir plus ou moins d'objets de gestion. Il n'y a pas d'exigences claires. MIB est principalement composé de deux parties. Une partie est l'objet de gestion standard défini par l'Organisation internationale de normalisation, comprenant MIB-I (RFC1156) et MIB-II (RFC1213). Tous les appareils connectés au réseau prennent en charge les objets de gestion généraux et de base, qui sont définis dans la norme MIB. L'autre partie est la MIB privée personnalisée par les grands fabricants, organisations ou particuliers. Ces MIB privées sont personnalisées par les fabricants en fonction des besoins de gestion des appareils et des objets à gérer qui ne figurent pas dans la MIB standard. La MIB privée est définie sous les entreprises de nœud (1.3.6.1.4.1).

Le MIB standard divise les objets de gestion en 10 groupes, qui sont 10 branches dans l'arborescence MIB. Ce sont : Système, Interfaces, AT (Traduction d'adresses, le statut est obsolète, indiquant la prochaine version Non. plus utilisé), IP, ICMP, TCP, UDP, EGP, Transmission, SNMP, leur nœud parent est 1.3.6.1.2.1 (mib-2). Les objets de gestion de ces 10 groupes constituent l'une des parties les plus importantes de la gestion du réseau.

Groupe Système : principalement utilisé pour décrire les informations au niveau du système de l'agent. Y compris sysName, sysLocation, sysDescr, sysServices, sysUpTime, sysContact, sysObjectID, etc. Ces OID fournissent des informations telles que le nom, l'emplacement et l'heure de connexion de l'appareil, qui sont très importantes dans la gestion du réseau. Dans les environnements réels, ces informations ne peuvent pas être mises à jour à temps et sont facilement ignorées.
Groupe Interfaces : Ce groupe est utilisé pour fournir toutes les informations d'interface des périphériques réseau. Y compris le type d'interface, la description de l'interface, le débit d'interface, l'état de l'interface, etc.
AT group : Groupe de traduction d'adresse. Ce groupe d'heures est un objet table qui implémente la relation de mappage entre les adresses réseau et les adresses physiques. En parcourant le tableau, la correspondance entre l'adresse IP et l'adresse MAC peut être obtenue.
IP group : définit l'objet de gestion des informations liées à la couche IP. Ces objets incluent les paquets IP, les informations d'erreur, les informations d'adresse, les informations de routage et les informations de mappage d'adresses.
Groupe ICMP : Ce groupe définit 26 objets scalaires qui décrivent l'envoi et la réception de divers messages ICMP, tous de type Compteur. Ces objets peuvent facilement fournir le taux d'envoi et de réception de messages ainsi que le taux de divers types de messages ICMP (demandes, réponses).
Groupe TCP : Ce groupe comprend principalement : la stratégie de retransmission TCP pour la gestion de la configuration, les objets avec le temps de retransmission le plus long et le plus court, et les liens pour la gestion des performances. Les objets tels que le numéro des demandes rejetées, le nombre d'enregistrements de transferts entre les états de communication TCP, le nombre total de retransmissions, le nombre total d'erreurs de réception, les objets techniques d'envoi et de réception de segments de données TCP pouvant être utilisés pour la gestion de la facturation et les objets de table tcpConnTable qui peut être utilisé pour la gestion de la sécurité, en analysant l'adresse IP distante, le numéro de port, l'état et d'autres informations enregistrées dans ce tableau, et en suivant les liens suspects depuis l'extrémité distante.
Groupe UDP : ce groupe comprend le comptage des objets pour la réception et l'envoi de paquets UDP, le rapport d'erreurs comptant les objets, les ports et les adresses IP, etc. qui peuvent être utilisés pour les performances et gestion comptable. Objets d'informations connexes. Groupe
Groupe EGP (Exterior Gateway Protocol) : EGP est un protocole utilisé pour échanger des informations de routage entre systèmes autonomes (entre voisins). Ce groupe comprend l'objet de table egpNeighTable pour diverses informations telles que l'état d'exécution du voisin pour la gestion des pannes des utilisateurs, le numéro de domaine du système autonome local pour la gestion de la configuration des utilisateurs, le taux de messages EGP entrant et sortant de l'entité locale pour la gestion des performances, et le objet de comptage d'erreurs.
Groupe de transmission : Le rôle de ce groupe est de fournir les informations de gestion correspondantes selon les différents supports de transmission. Ce groupe est assez spécial. MIB-II ne définit pas d'objets de gestion clairs sous cette branche, mais le type d'interface correspondant est ajouté à la réorganisation lorsqu'un certain support de transmission doit être géré.
Groupe SNMP : Ce groupe définit en détail les objets liés à SNMP. Par exemple, des statistiques sur le nombre de différents types d'erreurs pouvant être utilisées pour la gestion des erreurs, si les échecs d'authentification par interruption génèrent des objets de message pouvant être utilisés pour la gestion de la configuration, et des statistiques sur le nombre de messages différents envoyés et reçus pouvant être utilisés. pour la gestion des performances.

4 Arbre OID

Dans SNMP, tous les objets de gestion sont organisés dans une structure arborescente, et les objets de gestion sont incarnés sous forme de nœuds d'arbres dans l'arbre, et cet arbre est maintenu et géré par les organisations internationales de normalisation compétentes. Grâce à cette organisation structurée et hiérarchique, il est très pratique de gérer et d’agrandir les objets. Cette gestion et cette expansion se reflètent dans l’allocation des nœuds.

Les entreprises, organisations ou individus ont le droit de postuler pour que les nœuds des organisations internationales deviennent une branche de l'arborescence. Après avoir postulé avec succès pour un nœud, vous pouvez librement allouer d'autres nœuds sous la branche pour répondre à ses besoins commerciaux de surveillance ou de gestion.

Numéro OID, également appelé numéro MIB. MIB est en fait un module ASN.1 composé d'OID, qui est en réalité incarné dans une structure arborescente. Il existe de nombreuses MIB standards sur Internet. SNMP définit MIB-I, MIB-II, etc., et inclut également les MIB définies par les entreprises, les organisations et les particuliers. Comme indiqué ci-dessous.

Dans l'arborescence OID, seul le nœud racine de niveau supérieur n'a pas de numéro spécifique et peut être considéré comme un nœud virtuel. Les autres nœuds ont tous des numéros uniques au même niveau. .

Les nœuds de niveau suivant en haut sont le ccitt (0) géré par le CCITT (l'actuel ITU-T) et l'ISO (1) géré par l'ISO.

Il existe de nombreux sous-nœuds sous le nœud Internet, le répertoire (1) est réservé et pourra être utilisé pour les services d'annuaire OSI à l'avenir. mgmt(2) relève de la responsabilité de l'IAB et est utilisé pour définir les objets de gestion standard dans RFC, qui sont en fait MIB-I et MIB-II. experimental(3) est également géré par l'IAB et est utilisé pour définir des objets de gestion à caractère expérimental d'Internet. Les entreprises de nœuds privées (4) et de niveau inférieur (1) sont allouées et gérées par l'IANA. Le nœud d'entreprises (1) est principalement utilisé pour l'attribution à diverses entreprises ou organisations.

La structure arborescente de l'OID est illustrée dans la figure 13-2 ci-dessous. # à SNMP lors de la surveillance des options d'élément, il est recommandé de configurer les options Type d'information et Valeur de magasin comme indiqué dans le tableau suivant.

Zabbix 3.0监控网络设备有哪些

SNMP

Type

Description Zabbix

Description

Options d'éléments de surveillance recommandées

INTEGER

AVEC LE SYMBOLE 32 est un entier

Numérique non signé, décimal

Valeur de magasin : telle quelle

afficher les mappages de valeurs

STRING
Toutes les données binaires ou texte, vous pouvez le faire multi-ligne

Texte

Valeur de magasin : telle quelle

OID
Identifiant d'objet SNMP, exprimé en notation décimale à points

Personnage

Valeur de magasin : telle quelle

Counter32
La valeur qui croît dans une direction (0.. 4294967295), après avoir atteint le maximum, revient à 0 et recommence à compter

Numérique non signé, décimal

Valeur de magasin : delta (vitesse par seconde)

Gauge32
La valeur peut être augmentée ou diminuée (0.. 4294967295), et reste au valeur maximale lorsqu'elle atteint la valeur maximale jusqu'à ce qu'il atteigne le valeur maximale puis recommence à compter à partir de 0 (0 .. 18446744073709551615)

Numérique Non signé, décimal

Valeur de magasin : delta (vitesse par seconde)

TimeTicks
Entier non signé, modulo 2^32 (4294967296), un centième de seconde entre deux valeurs

Numérique non signé, décimal

Valeur de stockage : telle quelle

2 Découvrez l'OID

Avant d'utiliser l'équipement de surveillance SNMP dans Zabbix, vous devez déterminer la valeur OID et le type de données correspondant à l'élément de surveillance. En plus du MIB et de l'OID standard, vous devez consulter le fabricant de l'équipement grâce aux documents et aux fichiers de bibliothèque MIB fournis par le fabricant, vous pouvez découvrir rapidement et avec précision la valeur OID qui doit être surveillée.

Vous pouvez utiliser certains outils graphiques tels que le navigateur MG-SOFT MIB pour importer le fichier MIB et interroger les informations sur l'appareil dans l'interface graphique, comme le montre la figure 13-3 ci-dessous.

Zabbix 3.0监控网络设备有哪些

Figure 13-3

L'utilisation d'outils graphiques peut nous aider à parcourir, interroger et déterminer rapidement le type d'OID et la valeur des éléments de surveillance

Vous pouvez également utiliser l'outil snmpwalk pour interroger directement depuis l'appareil. Avant d'utiliser snmpwalk, assurez-vous que le système a installé le logiciel. S'il n'est pas installé, vous pouvez l'installer avec la commande suivante :

# yum install net-snmp-utils

Exécutez snmpwalk pour interroger les informations sur l'appareil.

# snmpwalk -v 2c -c public 10.60.0.19 1.3.6.1.2.1.1

SNMPv2-MIB::sysDescr.0 = STRING : logiciel Cisco IOS, logiciel ME380x (ME380x-UNIVERSALK9-M), version 15.4 ( 3) S2, VERSION LOGICIEL (fc1)

Support technique : http://www.cisco.com/techsupport

Compilé le mercredi 28 janvier 2015 11 :43 par prod_rel_team

SNMPv2-MIB ::sysObjectID.0 = OID : SNMPv2-SMI ::enterprises.9.1.1252

DISMAN-EVENT-MIB ::sysUpTimeInstance = Timeticks : (2030697335) 235 jours, 0:49:33.35

SNMPv2-MIB::sysContact.0 = STRING:

SNMPv2-MIB::sysName.0 = STRING: .0 = INTEGER: 6

SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0 : 00:00.00

Vous pouvez également afficher le chemin numérique correspondant à l'OID :

# snmpwalk -v 2c -On -c public 10.60.0.19 1.3.6.1.2.1.1

.1.3.6.1.2.1.1.1. 0 = CHAÎNE : Logiciel Cisco IOS, logiciel ME380x (ME380x-UNIVERSALK9-M), version 15.4(3)S2, VERSION DU LOGICIEL (fc1)

Support technique : http://www.cisco.com/techsupport

Compilé le mercredi 28 janvier 2015 à 11h43 par prod_rel_team

.1.3 .6.1.2.1.1.2.0 = OID : .1.3.6.1.4.1.9.1.1252

.1.3.6.1.2.1.1.3.0 = Timeticks : (2030720756) 235 jours, 0:53:27.56

1.3.6.1.2.1.1.4.0 = CHAÎNE :

.1.3.6.1.2.1. 1.5.0 = CHAÎNE : XZX-3800

.1.3.6.1.2.1.1.6.0 = CHAÎNE :

.1.3. 6.1.2.1.1.7.0 = ENTIER : 6

.1.3.6.1.2.1.1.8 .0 = Timeticks : (0) 0:00:00.00

Comment l'OID est affiché lorsque la commande snmpwalk est exécutée avec différents paramètres Il y aura également des différences dans les résultats. Quelle que soit la façon dont il est présenté, le résultat se compose toujours de trois parties : l'OID, le type de données et la valeur de retour. Par exemple, le nom de l'appareil s'affiche comme suit :

SNMPv2-MIB::sysName.0 = STRING : XZX-3800

.1.3.6.1.2.1.1.5.0= STRING : , les deux sont des valeurs de retour de sysName, mais l'expression de l'OID est différente. Lors de la définition d'éléments dans Zabbix, certains des OID les plus couramment utilisés peuvent utiliser des noms d'OID dans les paramètres de configuration SNMP OID. Zabbix convertira automatiquement certains des OID SNMP les plus couramment utilisés en nombres, tels que. car SNMPv2-MIB::sysName.0 sera converti en 1.3.6.1.2.1.1.5.0. Toutefois, l’OID de la MIB privée d’entreprise ne peut utiliser qu’un chemin entièrement numérique. Les OID qui peuvent être automatiquement convertis dans Zabbix sont présentés dans le tableau 13-1 ci-dessous.

Tableau 13-1

OID spécialifIndex1.3.6.1.2.1.2.2 .1.1Index des ports1.3.6.1.2.1.2.2.1.2Description du port1.3.6.1.2.1 .2.2.1.3Type de port1.3.6.1.2.1.2.2.1.4Octets de paquet de transmission maximum du port 1.3.6.1.2.1.2.2.1.5Vitesse du port1.3.6.1.2.1.2.2.1.6Adresse physique du port 1.3.6.1.2.1.2.2.1.7État de gestion du port1.3.6.1.2.1.2.2 1.8État de fonctionnement du port1.3.6.1.2.1.2.2.1.10Nombre d'octets reçus par le port1 .3.6.1.2.1.2.2.1.11

Identifiant	Description
		ifDescr
		ifType
		ifMtu
		ifSpeed
		ifPhysAddress
		ifAdminStatus
		ifOperStatus
.		ifInOctets
		ifInUcastPkts
	Le nombre de paquets non diffusés reçus par le port
ifInNUcastPkts	1.3.6.1.2.1.2.2.1.12	Le nombre de paquets diffusés reçus par le port
ifInDiscards	1.3 .6.1.2.1.2.2.1.13	Nombre de paquets rejetés du port de réception
ifInErrors	1 .3.6.1.2.1.2.2.1.14	port Nombre d'erreurs de paquets reçues
ifInUnknownProtos	1.3.6.1.2.1.2.2.1.15	Le nombre de paquets de protocole inconnus reçus par le port
ifOutOctets	1.3.6.1.2.1.2.2.1.16	Nombre d'octets envoyés par le port
ifOutUcastPkts	1.3.6.1.2.1.2.2.1.17	Nombre de non-diffusion paquets envoyés par le port
ifOutNUcastPkts	1.3 .6.1.2.1.2.2.1.18	Numéro de port des paquets de diffusion envoyés
if OutDiscards	1.3.6.1. 2.1.2.2.1.19	port Nombre de paquets rejetés envoyés
ifOutErrors	1.3.6.1.2.1.2.2.1.20	Nombre de erreurs de paquet d'envoi de port
ifOutQLen	1. 3.6.1.2.1.2.2.1.21	Longueur de la file d'attente d'envoi du port

3 Configuration de SNMP

Avant de commencer à configurer SNMP dans Zabbix, veuillez vous assurer que le serveur Zabbix a activé la fonction de surveillance SNMP. Lorsque le serveur Zabbix démarre, une liste des fonctions du serveur Zabbix sera répertoriée dans le fichier journal, comme suit :

911:20160218:103649.120 Démarrage du serveur Zabbix Zabbix 3.0.1 (révision58734).

. # 🎜🎜 # 911: 20160218: 103649.160 ****** fonctionnalités activées ****** # 🎜🎜 ## 🎜🎜 # # 🎜🎜 # 911: 20160218: 103649.160 SnmpMonitoring: oui # 🎜🎜 ## 🎜🎜 🎜🎜 #

911:20160218:103649.160 Surveillance IPMI : OUI

911:20160218:103649.160 Surveillance Web : OUI#🎜 🎜# 911:2016021 8:103649.160 Surveillance VMware : OUI#🎜 🎜 #911:20160218:103649.160 Authentification SMTP : OUI OUI

911:20160218:103649.160 Ez Notifications par SMS : OUI# 🎜🎜#

9 11:20160218:103649.160 ODBC : 911 :20160218:103649.160 Prise en charge SSH2 : OUI

911:20160218:103649.160 Prise en charge IPv6 : OUI# 🎜🎜#

911:20160218:103649.160 Prise en charge TLS : OUI

911:20160218:103649.160 ********************* **********

911:20160218:103649.160 en utilisant la configuration file:/etc/zabbix/zabbix_server.conf

Si aucune information sur l'activation de la surveillance SNMP n'est trouvée, alors vous devez installer Zabbixserver. Si vous utilisez le code source pour compiler et installer, vous devez utiliser le. option de configuration de compilation --with-net-snmp.

Seul le protocole UDP est utilisé pour la surveillance SNMP dans Zabbix, et plusieurs valeurs peuvent être interrogées en une seule requête, qu'il s'agisse d'éléments SNMP normaux, d'index dynamiques (index dynamiques), d'éléments SNMP ou de niveau SNMP bas règles de découverte, qui peuvent assurer l'efficacité lors de la gestion de gros volumes de SNMP. Activez ou désactivez les requêtes groupées en définissant l'option Utiliser les requêtes groupées des interfaces SNMP de l'hôte. Comme le montre la figure 13-4 ci-dessous.

Figure 13-4

Tous les éléments de surveillance SNMP avec les mêmes paramètres dans une seule interface seront mis à jour à l'ensemble Intervalle de temps Interrogation simultanée. Pour les éléments SNMP normaux et les éléments SNMP d'index dynamiques, les interrogeurs traiteront 128 éléments de surveillance en même temps, tandis que les règles de découverte SNMP de bas niveau seront traitées séparément. Il existe deux types d'opérations effectuées lors de l'interrogation : la collecte de plusieurs objets spécifiés. . et parcourez l’arborescence OID. Collection signifie qu'un GetRequest-PDU peut être lié à jusqu'à 128 variables. Traversal signifie utiliser GetNextRequest-PDU dans SNMP v1 et utiliser GetBulkRequest avec le champ max-repetitions dans SNMP v2 ou SNMP v3, qui peut lier jusqu'à 128 variables. variable.

Par conséquent, le traitement par lots de chaque élément de surveillance SNMP présente les avantages suivants :

Les performances des éléments de surveillance SNMP réguliers collectant des données sont améliorées.

Zabbix 3.0监控网络设备有哪些 Index dynamiques (index dynamiques) Les performances des éléments de surveillance SNMP dans la collecte et le parcours des données ont été améliorées.

Les performances des règles de découverte SNMP de bas niveau traversant les données ont été améliorées.

Les éléments de requête par lots actuels sont réduits de moitié, c'est-à-dire que 21 variables sont interrogées. Si l'appareil renvoie une valeur normale, dans la plupart des cas, il ne devrait y avoir aucun problème, car nous savons qu'il n'y a aucun problème à interroger 28 variables et que 21 doit être nettement inférieur à 28. Si vous ne parvenez toujours pas à obtenir une valeur de retour normale après avoir réduit de moitié l'élément, vous devez annuler le nombre de variables interrogées une par une jusqu'à ce que vous obteniez une valeur de retour normale.

Zabbix interrogera avec le nombre de variables qui ont été interrogées avec succès la dernière fois (notre exemple est 28) dans les requêtes suivantes, et continuera à augmenter le nombre de variables de requête demandées (augmenter de 1 à chaque fois) jusqu'à ce que la limite supérieure est atteinte. Par exemple, supposons que la réponse maximale soit de 32 variables. Les requêtes suivantes seront interrogées selon 29, 30, 31, 32 et 33, de préférence une requête échouera (33 variables) et Zabbix n'émettra jamais une autre requête liant 33 variables. La requête SNMP de Zabbix peut lier jusqu'à 32 variables sur cet appareil.

Lorsque le serveur Zabbix ou le serveur proxy reçoit une réponse SNMP incorrecte, un contenu similaire au suivant sera ajouté au fichier journal :

La réponse SNMP de l'hôte "passerelle" ne le fait pas contiennent toutes les liaisons de variables demandées

Bien que ces informations ne couvrent pas toutes les situations problématiques, au moins une chose est que l'option Utiliser les requêtes groupées dans l'interface SNMP de l'hôte doit être désactivée.

4 Configurer les éléments de surveillance SNMP réguliers

Lors de l'utilisation d'un équipement de surveillance SNMP, les éléments de surveillance SNMP réguliers peuvent être configurés selon les étapes suivantes :

Créer un hôte et ajoutez-y une interface SNMP. Vous pouvez utiliser le modèle Template SNMP Generic fourni dans Zabbix pour ajouter automatiquement des éléments de surveillance qui collectent des informations de base sur le périphérique.

2. Déterminez l'OID surveillé.

Trouvez et déterminez l'OID qui doit être surveillé via le navigateur MIB ou snmpwalk. Par exemple, si nous voulons surveiller le trafic d'un port Gigabit du commutateur, l'index de l'interface GigabitEthernet0/1. trouvé via snmpwalk est 10101.

# snmpwalk -v 2c -c public 10.60.0.19 IF-MIB::ifDescr

GigabitEthernet0/1 peut être réécrit en IF-MIB::ifDescr.10101 Valeur de chaîne

IF-MIB::ifDescr.10102 = STRING : GigabitEthernet0/2

GigabitEthernet0/3 est identifié comme IF-MIB::ifDescr.10103.#🎜 🎜## 🎜🎜#La chaîne "GigabitEthernet0/4" est la valeur de "ifDescr.10104" dans IF-MIB

IF-MIB::ifDescr.10105 = STRING: GigabitEthernet0/5#🎜🎜 ## 🎜🎜#La chaîne "IF-MIB::ifDescr.10106" correspond à "GigabitEthernet0/6"

IF-MIB::ifDescr.10107 = STRING: GigabitEthernet0/7#🎜🎜 ##🎜 🎜#…

L'OID obtenu pour le trafic de sortie de l'interface GigabitEthernet0/1 est .1.3.6.1.2.1.2.2.1.16.10101.

# snmpwalk -v 2c -On -c qhdpublic 10.60.0.19IF-MIB::ifOutOctets.10101

.1.3.6.1.2.1.2.2.1.16.10101 = Counter32 : 3619738552

3. Créez un élément de surveillance et utilisez la méthode de surveillance de l'agent SNMPv2. L'OID SNMP est .1.3.6.1.2.1.2.2.1.16.10101.

5 Configurer les éléments de surveillance SNMP d'index dynamique

Dans l'arborescence OID de l'appareil, les OID de certains objets de gestion utilisent souvent des index, comme les interfaces réseau, en utilisant le même index association à différents objets sur l’interface réseau. Tout comme la sortie snmpwalk ci-dessous.

# snmpwalk -v 2c -c public 10.60.0.19 .1.3.6.1.2.1.2.2.1

IF-MIB::ifIndex.1 = INTEGER : 1# 🎜🎜#
IF-MIB::ifIndex.5001 = ENTIER : 5001
IF-MIB::ifIndex.5002 = ENTIER : 5002
IF-MIB ::ifIndex.5003 = ENTIER : 5003
IF-MIB::ifIndex.10101 = ENTIER : 10101
IF-MIB::ifIndex.10102 = ENTIER : 10102# 🎜🎜#
...

IF-MIB::ifDescr.1 = CHAÎNE : Vlan1

IF-MIB::ifDescr.5001 = CHAÎNE : Port -channel1

IF-MIB::ifDescr.5002 = CHAÎNE : Port-canal2

IF-MIB::ifDescr.5003 = CHAÎNE : Port-canal3

GigabitEthernet0/1 peut être réécrit en tant que valeur de chaîne de IF-MIB::ifDescr.10101

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2
# 🎜🎜#...
IF-MIB::ifType.1 = ENTIER : propVirtual(53)
IF-MIB::ifType.5001 = ENTIER : propVirtual ( 53)
IF-MIB::ifType.5002 = ENTIER : propVirtual(53)
IF-MIB::ifType.5003 = ENTIER : propVirtual(53)# 🎜 🎜#
IF-MIB::ifType.10101 = ENTIER : ethernetCsmacd(6)

IF-MIB::ifType.10102 = ENTIER : ethernetCsmacd(6)
# 🎜 🎜#...
IF-MIB::ifMtu.1 = ENTIER : 1500
IF-MIB::ifMtu.5001 = ENTIER : 1500
# 🎜🎜#IF-MIB::ifMtu.5002 = ENTIER : 1500 .10101 = ENTIER : 1500

IF-MIB::ifMtu.10102 = ENTIER : 1500

. ..

IF-MIB :: ifspeed 0000#🎜🎜 #
IF-MIB::ifSpeed.5003 = Jauge32 : 1000000000
IF-MIB :: ifSpeed.10101 = Jauge32 : 1000000000
IF-MIB : ifSpeed.10102 = Jauge32 : 1000000000
...
IF-MIB : :ifPhysAddress.1 = CHAINE : b0:7d:47:be:ea:c0#🎜 🎜#
IF-MIB::ifPhysAddress.5001 = CHAÎNE : b0:7d:47:be:ea:c2#🎜 🎜#
IF-MIB::ifPhysAddress.5002 = CHAINE: b0:7d :47:be:ea:c3
IF-MIB::ifPhysAddress.5003 = CHAÎNE: b0:7d :47:be:ea:c4
IF-MIB : :ifPhysAddress.10101 = CHAINE : b0:7d:47:be:ea:c2
IF-MIB : :ifPhysAddress.10102 = STRING : b0:7d:47:be:ea:c3#🎜 🎜#
...

IF-MIB::ifAdminStatus.1 = INTEGER : down( 2)

IF-MIB::ifAdminStatus.5001 = INTEGER : up(1)

IF-MIB::ifAdminStatus.5002 = INTEGER : up(1)#🎜 🎜#
IF-MIB::ifAdminStatus.5003 = ENTIER : up(1)

IF-MIB::ifAdminStatus.10101 = INTEGER : up(1)

IF-MIB::ifAdminStatus.10102 = INTEGER : up(1)

...

À partir des données ci-dessus, vous pouvez voir que chaque réseau Les interfaces ont de nombreux OID, et chaque OID représente différents indicateurs de l'interface réseau, tels que le nom, le type, l'adresse physique, etc. de l'interface. Vous constaterez que différents OID sont liés via le même index. Par exemple, le nom de la première interface Gigabit est GigabitEthernet0/1, l'adresse physique est b0:7d:47:be:ea:c2, l'état est up (1) et son index est 10101.

Afin de surveiller différents indicateurs d'une même interface réseau, vous pouvez créer différents éléments de surveillance et saisir l'OID complété dans le champ SNMP OID. Il n'y a aucun problème avec cette méthode, mais il y aura quelques problèmes lors de l'utilisation de l'index dans l'environnement réel. La raison en est que l'index changera en raison de mises à niveau logicielles ou matérielles, provoquant des incohérences de configuration. Afin de résoudre ce problème, Zabbix propose une méthode d'index dynamique, qui n'affecte pas la surveillance des éléments de surveillance même si la valeur de l'index change.

La syntaxe d'utilisation des index dynamiques SNMP OID est la suivante :

["index","",""]

La signification de chaque partie dans la syntaxe Comme suit :
- OID des données : L'OID défini dans l'élément qui doit être interrogé.
- Index : Méthode de traitement, actuellement seule cette méthode est prise en charge. Index signifie rechercher un index et l'ajouter à l'OID.
- OID de base de l'index : La valeur de l'index correspondante sera trouvée en fonction de cet OID.
- chaîne à rechercher : utilisez cette chaîne pour la correspondance lors de la recherche, en respectant la casse.
Par exemple, si vous souhaitez surveiller les ifInOctets de l'interface GigabitEthernet0/1, selon la syntaxe, il peut être défini comme :

ifInOctets["index","ifDescr","GigabitEthernet0/1"]

Cela peut être compris comme la correspondance et la recherche de GigabitEthernet0 dans l'interface ifDescr/1, et/ou la valeur d'index de cette interface dans ifDescr, puis ajouter la valeur d'index collectée à ifInOctets, collectant ainsi la valeur ifInOctets de l'interface GigabitEthernet0/1. .

Lors de l'utilisation d'index dynamiques, Zabbix recevra et mettra en cache l'intégralité de la table SNMP de l'OID d'index. L'OID d'index peut être rapidement découvert via le cache. Si d'autres éléments de surveillance interrogent le même OID d'index à l'avenir, il sera recherché directement. à partir du cache. Pas besoin d'interroger l'hôte de surveillance.

Ensuite, lors de la réception des données de l'élément de surveillance, il vérifiera si l'index a changé. Si l'index n'envoie pas de modifications, il continuera à utiliser la requête de valeur. Si l'index envoie des modifications, Zabbix reconstruira le cache. et chaque observateur parcourra à nouveau la table SNMP de l'OID d'index.

Dans Zabbix, chaque processus d'interrogation possède son propre cache.

6 Configurer les règles de découverte SNMP de bas niveau

Lors de la création de règles de découverte pour les OID SNMP, contrairement à la définition de règles de découverte pour les systèmes de fichiers ou les interfaces réseau, vous n'utilisez pas la clé snmp.discovery. Vous pouvez utiliser la méthode de surveillance de l'agnet SNMP. Dans SNMPOID Les OID à découvrir sont définis dans le champ, au format de découverte[{#MACRO1}, oid1, {#MACRO2}, oid2, …,].

{#MACRO1}, {#MACRO2}... sont tous des noms de variables de macro valides, oid1, oid2... sont utilisés pour générer les valeurs des variables de macro. Lors de la découverte, le système crée une variable de macro nommée {#SNMPINDEX} par défaut, qui est utilisée pour créer un index pour l'OID de découverte. Les résultats de la découverte sont regroupés par {#SNMPINDEX}.

Les exemples suivants peuvent vous aider à mieux comprendre. Utilisez d’abord snmpwalk pour collecter les données pertinentes du commutateur.

# snmpwalk -v 2c -OT -c public 10.60.0.19 IF-MIB::ifDescr

IF-MIB::ifDescr.1 = STRING : Vlan1

GigabitEthernet0/1 peut être réécrit en IF-MIB :: String valeur de ifDescr.10101

IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2

GigabitEthernet0/3 est identifié comme IF-MIB::ifDescr.10103.

# snmpwalk -v 2c -OT - c public 10.60.0.19 IF-MIB ::ifPhysAddress

IF-MIB ::ifPhysAddress.1 = STRING : b0:7d:47:be:ea:c0

IF-MIB ::ifPhysAddress.10101 = STRING : b0 : 7d : 47:be:ea:c2

IF-MIB::ifPhysAddress.10102 = CHAINE: b0:7d:47:be:ea:c3

IF-MIB::ifPhysAddress.10103 = CHAÎNE: b0:7d: 47: be:ea:c4

Entrez ensuite dans le champ SNMP OID lors de la création de la règle de découverte :

discovery[{#IFDESCR}, ifDescr, {#IFPHYSADDRESS}, ifPhysAddress]

Après avoir exécuté la règle de découverte, vous obtenez ce qui suit résultats :

{

"data": [

"{

"{#SNMPINDEX}":"1", "{#IFDESCR}": " Vlan1",

"{#IFPHYSADDRESS}": " b0 :7d:47:be:ea:c0"

" },

" "{

" "{#SNMPINDEX}": "2",

" "{#IFDESCR}": " GigabitEthernet0/1 ",

"{#IFPHYSADDRESS}": " b0:7d:47:be:ea:c2"

" " },

" "{#SNMPINDEX}": "3",

"{#IFDESCR}": " GigabitEthernet0/2",

"{#IFPHYSADDRESS}": b0:7d:47:be:ea:c3"

" " :"4",

"{#IFDESCR}": " GigabitEthernet0/3 ",

" "{#IFPHYSADDRESS}": b0:7d:47:be:ea:c4"

               ) Il n'y a pas de valeur de retour et la macro correspondante sera ignorée dans les résultats de la découverte, comme dans l'exemple ci-dessous.

Les données supposées sont les suivantes :

ifDescr.1 "Interface #1"

ifDescr.2 "Interface #2"

ifDescr.4 "Interface #4"

ifAlias.1 "eth0"

ifAlias .2 "eth2"

ifAlias.3 "eth3"

ifAlias.5 "eth5"

Renseignez ensuite dans le champ SNMP OID lors de la création de la règle de découverte :

discovery[{#IFDESCR},ifDescr, {#IFALIAS }, ifAlias ]

Après avoir exécuté la règle de découverte, nous obtenons les résultats suivants :

{

"data" : [

"{

"{#SNMPINDEX}" : 1,

"{#IFDESCR} ”: #1" ,

                                                              IFDESCR}": "Interface #2",

            " "{ #IFALIAS}": 2"

                                                            },

                                                                                                        SNMPINDEX}": 4,

"{#IFDESCR}" :"Interface #4"

"{#SNMPINDEX}": 5,

"{#IFALIAS}": "eth5"



Figure 13-5

Créez un prototype d'élément basé sur les règles de découverte définies, comme indiqué dans la figure 13-6 ci-dessous.

Figure 13-6
Vous pouvez créer plusieurs prototypes d'articles, comme le montre la figure 13-7 ci-dessous.

Photo 13-7