SNMP hat sich zum am weitesten verbreiteten Netzwerkverwaltungsprotokoll entwickelt. Die derzeit verwendeten Versionen umfassen hauptsächlich SNMP v1, SNMP v2c und SNMP v3. Die Hauptunterschiede zwischen den Versionen liegen in der Definition von Informationen, der Funktionsweise von Kommunikationsprotokollen und dem Sicherheitsmechanismus. Gleichzeitig sind auch zwei Erweiterungen von SNMP-Anwendungen erschienen, RMON (Remote Network Monitoring) und RMON2.
Aus Sicht der physischen Schicht sollte die Verwendung von SNMP zur Verwaltung des Netzwerks Folgendes umfassen: Netzwerkverwaltungsstation (NMS), Agent (Agent) und Proxyserver (Proxy). Im Netzwerkmanagement ist mindestens ein NMS erforderlich, um Anweisungen zu erteilen und Benachrichtigungsinformationen zu empfangen. Agenten können auf Anfragen von Verwaltungsknoten reagieren und auch proaktiv Benachrichtigungsinformationen generieren. Es können ein oder mehrere Agenten in der Netzwerkverwaltung vorhanden sein. Proxy leitet SNMP-Anfragen und Benachrichtigungsnachrichten zwischen verschiedenen Netzwerken oder verschiedenen Versionen weiter.
Aus Sicht der Protokollschicht umfasst SNMP: SMI (Struktur der Verwaltungsinformationen, Managementinformationsstruktur) und MIB (Managementinformationsbasis, Managementinformationsbasis). SMI ist eine Teilmenge von ASN.1 (Abstract SyntaxNotation One). SMI legt fest, dass Elemente, benutzerdefinierte Datentypen und Makros in SNMP verwendet werden können, um diese Elemente, Datentypen, Makros und andere verwandte Syntaxen zu definieren MIBs in SNMP. MIB ist eine abstrakte Beschreibung verwaltbarer Objekte im Agent. In SNMP wird MIB in einer Baumstruktur organisiert und angezeigt. Jeder Knoten im Baum wird als OID (Object Identifier) bezeichnet. Er ist ähnlich wie ein Website-Domänenname organisiert und jeder Knoten wird durch ein Zertifikat dargestellt wie 1.3. 6.4.
SNMP ist ein Protokoll der Anwendungsschicht, das zum TCP/IP-Protokollstapel gehört, ähnlich den HTTP- und FTP-Protokollen. Es ist nur so, dass die SNMP-Transportschicht das UDP-Protokoll verwendet.
In SNMP v1 wird ein einfacher Authentifizierungsmodus vom NMS zum Agenten bereitgestellt – die Community muss die Community-Zeichenfolge bereitstellen, wenn sie eine Anfrage an den Agenten sendet. Es muss überprüft werden, ob dies der Fall ist im Einklang mit der lokalen. Es bestehen offensichtliche Sicherheitsrisiken aufgrund der Verwendung von Klartext zur Übertragung der Community.
1996 veröffentlichte die IETF SNMP v2c (Community-BasedSNMP v2), das die Kommunikation zwischen Verwaltungsstationen basierend auf v1 definierte. Alle unterstützen die verteilte Netzwerkverwaltung, aber im Sicherheitsmechanismus ist es immer noch derselbe wie v1.
1998 veröffentlichte IETF SNMP v3, das die Sicherheit (benutzerbasiertes Sicherheitsmodell und ansichtsbasiertes Zugriffskontrollmodell) und Verwaltungsmechanismen auf Basis von SNMP v2 erweiterte. Im Hinblick auf die Sicherheit fügt die v3-Version Sicherheitsparameter zu Protokollnachrichten hinzu und ermöglicht so eine verschlüsselte Übertragung und eine obligatorische Überprüfung von Nachrichten. Es handelt sich um ein sicheres Protokoll. SNMP v3 nutzt die modulare Idee, um jedes Komponentenmodul im Protokoll zu definieren, verbessert die Protokollarchitektur und bleibt, was am wichtigsten ist, mit SNMP v1 und SNMP v2 kompatibel.
Der Agent in SNMP ist hauptsächlich für das Hochladen von Informationen verantwortlich. Zusätzlich zu den Ebenenfunktionen des SNMP-Protokolls verfügt NMS auch über die Möglichkeit, gesendete Informationen zu protokollieren Aufzeichnungs-, Verwaltungs- und Konfigurationsfunktionen zur Aufzeichnung und Benachrichtigung von Informationen und können eine grafische Konfigurations- und Verwaltungsoberfläche bereitstellen.
Um diese Funktionen zu realisieren, enthält SNMP eine Reihe von Betriebsbefehlen, darunter hauptsächlich:
Lesebefehle: Serienbefehle abrufen, NMS Stellen Sie Anfragen wie „Agent“, um Verwaltungsinformationen zu sammeln.
Befehl festlegen: Befehl festlegen, NMs schreibt die in der Nachricht enthaltenen Daten in den Agenten.
Alarmfunktion: Trap-Serie, Agent sendet aktiv Alarm-/Ereignismeldungsinformationen an NMS.
Abbildung 13-1
1, Betrieb starten
#🎜 🎜#Get-Vorgang ist ein aktiv von NMS initiierter Vorgang. Zusätzlich zum Get-Request-Flag enthält die gesendete Nachricht auch das anzufordernde OID-Namens- und Wertepaar, und die Verwaltungsobjektinformationen werden in Form einer Bindung dieses Namens- und Wertepaars übertragen. Natürlich ist der der OID in der Get-Operation entsprechende Wert NILL. 2. Get-Next-OperationDie Get-Next-Operation ähnelt der Get-Funktion. Der Unterschied besteht darin, dass die abgefragten Informationen nicht die in der Nachricht gebundenen OID-Informationen sind sondern die Informationen über die nächste OID des Objekts (sofern die nächste OID-Information lesbar ist). Beispielsweise möchte NMS die Informationen von sysLocation, dem nächsten Knoten von sysName auf der Agentenseite, sammeln. In der Anforderungsnachricht ist es sysName.0, und die zurückgegebene Nachricht ist an sysLocation.0 und den Wert gebunden. 3. Die Get-Bulk-Operation ist eigentlich eine Sammlung mehrerer Get-Next-Operationen, eine neu hinzugefügte Operationsmethode in SNMP v2. 4. Set-Operation Set-Operation kann Parameter für OIDs mit beschreibbaren Berechtigungen festlegen, um Parameterverwaltung, Konfiguration und Steuerung des Geräts zu erreichen. Im Gegensatz zu den Bindungsvariablen für den Get-Vorgang muss Set den Wert der entsprechenden OID-Einstellung binden. 5, Get-ResponseGet-Response ist die Antwort auf die Get- und Set-Befehle von NMS, abhängig vom Befehl und den Parametern im Befehl, den entsprechenden Rückgaben Variablenbindungsinformationen und Fehlerstatusinformationen (die den Erfolg oder Misserfolg der Befehlsausführung anzeigen) usw. 6, Trap-Serie Trap ist ein Mechanismus für den Agenten, um wichtige Ereignisse proaktiv an NMS zu melden. Für diese Art von Bericht muss NMS nicht auf den Agenten reagieren. Der Inhalt der Falleninformationen gibt an, was zu welcher Zeit und wo passiert ist. 3 SMI und MIB1, SMI
SMI ist ein Informationsmodul, das in der ASN.1-Syntax in SNMP definiert ist und eine Teilmenge von ASN.1 ist. Diese Module enthalten viele SNMP-spezifische Makros, benutzerdefinierte Datentypen und Regeln usw. Es gibt drei Hauptzwecke beim Definieren dieser Makros, Datentypen und Regeln: Der eine besteht darin, eindeutige Datentypen in SNMP-Anwendungen darzustellen und zu definieren. Der andere besteht darin, die Definitionsmethode von Verwaltungsobjekten zu vereinfachen und Verwaltungsobjekte in der SNMP-Codierungsmethode. SNMP basiert auf diesen in RFC-Dokumenten definierten Informationsmodulen, um das Protokoll zu standardisieren und es verschiedenen Organisationen, Unternehmen und Einzelpersonen zu ermöglichen, bei der Definition von Verwaltungsobjekten Konsistenz zu wahren.
In SNMP sind tatsächlich zwei Versionen von SMI definiert, nämlich SMI v1, definiert in RFC 1151, und SMI v2, definiert in RFC 2578. In SMI v1 werden mehrere Datentypen, Regelbeschreibungen, OBJECT-TYPE-Makros usw. einfach definiert. In SMI v2 sind alle zugehörigen Inhalte vollständig modular definiert.
Die in SMI v1 definierten grundlegenden Datentypen sind:
INTEGER: Es handelt sich tatsächlich um eine 32-Bit-Ganzzahl.
OCTET STRING: 0 oder mehr 8-Bit-Zeichen (einzelnes Byte), die Textzeichen oder physische Adressen darstellen können. Der Wertebereich liegt zwischen 0 und 65535.
OBJEKT-IDENTIFIER: OID, ausgedrückt in Punkt-Dezimal-Schreibweise.
NULL: Es ist nur in SMI v1 definiert und wird in SMI v2 nicht mehr verwendet.
SEQUENCE: Definitionsliste.
FOLGE VON: Tabelle definieren.
In SMI v2 werden die Umfangsbeschränkungen und Aktualisierungen der oben genannten Datentypen weiter verdeutlicht und der BITS-Typ wird ebenfalls eingeführt.
Zu den benutzerdefinierten Datentypen in SMI v1 gehören:
NetworkAddress (Netzwerkadresse), bei der es sich um eine andere Netzwerkadressfamilie als das Internet handeln kann. # 32-Bit-IP-Adresse in Netzwerkbytes Sequentielle Darstellung
IPAddress ::= [ANWENDUNG 0 ] IMPLICIT OCTET STRING (SIZE (4))
#🎜 🎜#Der Wert des Messgerättyps kann bis zum Erreichen des Maximalwerts erhöht oder verringert werden. Der Wert wird auf dem Maximalwert gehalten. Beispielsweise kann die Rate der Schnittstelle im Router durch diesen Typ dargestellt werden.
Gauge::= [ANWENDUNG 2]IMPLICIT INTEGER (0.. 4294967295)
TimeTicks verwendet 0,01 Sekunden als Einheit für die Zeitmessung, die den Zeitabstand zwischen zwei Zeitpunkten angibt. Erfordert die Angabe der Zeitbasis in der Beschreibung.
TimeTicks ::= [ ANWENDUNG 3 ] IMPLICIT INTEGER (0.. 4294967295)
Opa que Die von anderen ASN.1-Typen codierten Werte werden zweimal gekapselt. Aus Gründen der Abwärtskompatibilität ist dieser Typ auch in SMIv2 definiert und wird nicht empfohlen.
Opaque :::= [ANWENDUNG 4] IMPLICIT OCTET STRING
Unsigned32 ::= [APPLICIT 2 ] IMPLICIT INTEG ER (0..4294967295)
Counter64 ist ein Zähler mit größerem Bereich, es gibt 64: 2^64-1 (0..18446744073709551615). Counter32 wird im Standard-MIB-Modul nur verwendet, wenn der Zähler in weniger als 1 Stunde auf 0 zurückkehrt.
Der IPAddress-Typ bleibt in SMI v2 weiterhin erhalten, und enthält keine Änderungen. Dies gilt jedoch nicht für die 128-Bit-Adresse von IPv6. Eine weitere Erklärung zu Counter32: Der aktuelle Zählwert hat nur dann eine eindeutige Bedeutung, wenn ein Anfangswert und eine aufgezeichnete Änderung vorliegen.
MIB ist eine Sammlung von Verwaltungsinformationen basierend auf Geschäftsanforderungen oder Netzwerkmanagementstandards Anforderungen, strukturierte Textdateien, die gemäß vereinbarter Organisationsregeln und Definitionssyntax geschrieben wurden.
Ein Agent kann mehrere MIBs implementieren und jede MIB kann mehr oder weniger Verwaltungsobjekte enthalten. Es gibt keine klaren Anforderungen. MIB besteht hauptsächlich aus zwei Teilen. Ein Teil ist das von der International Organization for Standardization definierte Standardverwaltungsobjekt, einschließlich MIB-I (RFC1156) und MIB-II (RFC1213). Alle mit dem Netzwerk verbundenen Geräte unterstützen allgemeine und grundlegende Verwaltungsobjekte, die in der Standard-MIB definiert sind. Der andere Teil ist die private MIB, die von großen Herstellern, Organisationen oder Einzelpersonen angepasst wird. Diese privaten MIBs werden von Herstellern entsprechend den Anforderungen der Geräteverwaltung und den zu verwaltenden Objekten angepasst, die nicht in der Standard-MIB enthalten sind. Die private MIB ist unter dem Knoten Unternehmen (1.3.6.1.4.1) definiert.
Die Standard-MIB unterteilt die Verwaltungsobjekte in 10 Gruppen, die 10 Zweige im MIB-Baum darstellen. Sie sind: System, Schnittstellen, AT (Adressübersetzung, der Status ist veraltet und gibt die nächste Versionsnummer an (mehr verwendet), IP, ICMP, TCP, UDP, EGP, Übertragung, SNMP, ihr übergeordneter Knoten ist 1.3.6.1.2.1 (mib-2). Die Verwaltungsobjekte in diesen 10 Gruppen sind einer der wichtigsten Teile der Netzwerkverwaltung.
Systemgruppe: Wird hauptsächlich zur Beschreibung von Informationen auf Agentensystemebene verwendet. Einschließlich sysName, sysLocation, sysDescr, sysServices, sysUpTime, sysContact, sysObjectID usw. Diese OIDs stellen Informationen wie den Namen, den Standort und die Online-Zeit des Geräts bereit, die für die Netzwerkverwaltung sehr wichtig sind. In tatsächlichen Umgebungen können diese Informationen nicht rechtzeitig aktualisiert werden und werden leicht ignoriert.
Schnittstellengruppe: Diese Gruppe wird verwendet, um alle Schnittstelleninformationen von Netzwerkgeräten bereitzustellen. Einschließlich Schnittstellentyp, Schnittstellenbeschreibung, Schnittstellenrate, Schnittstellenstatus usw.
AT-Gruppe: Adressübersetzungsgruppe. Diese Zeitgruppe ist ein Tabellenobjekt, das die Zuordnungsbeziehung zwischen Netzwerkadressen und physischen Adressen implementiert. Durch Durchlaufen der Tabelle kann die Entsprechung zwischen der IP-Adresse und der MAC-Adresse ermittelt werden.
IP-Gruppe: Definiert das Verwaltungsobjekt für Informationen zur IP-Schicht. Zu diesen Objekten gehören IP-Pakete, Fehlerinformationen, Adressinformationen, Routing-Informationen und Adresszuordnungsinformationen.
ICMP-Gruppe: Diese Gruppe definiert 26 Skalarobjekte, die das Senden und Empfangen verschiedener ICMP-Nachrichten beschreiben, die alle vom Typ Counter sind. Diese Objekte können problemlos die Sende- und Empfangsrate von Nachrichten sowie die Rate verschiedener ICMP-Nachrichtentypen (Anfragen, Antworten) bereitstellen.
TCP-Gruppe: Diese Gruppe umfasst hauptsächlich: TCP-Neuübertragungsstrategie für das Konfigurationsmanagement, Objekte mit der längsten und kürzesten Neuübertragungszeit und Links für das Leistungsmanagement. Objekte wie die Nummer der abgelehnten Anfragen, die Anzahl der Datensätze von Übertragungen zwischen TCP-Kommunikationszuständen, die Gesamtzahl der erneuten Übertragungen, die Gesamtzahl der Empfangsfehler, technische Objekte zum Senden und Empfangen von TCP-Datensegmenten, die für die Abrechnungsverwaltung verwendet werden können, und tcpConnTable-Tabellenobjekte, die kann zur Sicherheitsverwaltung verwendet werden, indem die Remote-IP, die Portnummer, der Status und andere in dieser Tabelle aufgezeichnete Informationen analysiert und verdächtige Links vom Remote-Ende verfolgt werden.
UDP-Gruppe: Diese Gruppe umfasst Zählobjekte zum Empfangen und Senden von UDP-Paketen, Fehlerbericht-Zählobjekte, Ports und IP-Adressen usw., die für die Leistung verwendet werden können Buchhaltungsmanagement. Objekte verwandter Informationen.
EGP-Gruppe (Exterior Gateway Protocol): EGP ist ein Protokoll, das zum Austausch von Routing-Informationen zwischen autonomen Systemen (zwischen Nachbarn) verwendet wird. Diese Gruppe umfasst das Tabellenobjekt „egpNeighTable“ für verschiedene Informationen, wie z. B. den Nachbarbetriebsstatus für die Verwaltung von Benutzerfehlern, die Domänennummer des lokalen autonomen Systems für die Verwaltung der Benutzerkonfiguration, die Rate der EGP-Nachrichten, die zur Leistungsverwaltung in die lokale Entität ein- und ausgehen, und die Fehlerzählobjekt.
Übertragungsgruppe: Die Rolle dieser Gruppe besteht darin, entsprechende Verwaltungsinformationen für verschiedene Übertragungsmedien bereitzustellen. Diese Gruppe ist etwas ganz Besonderes. In diesem Zweig werden keine eindeutigen Verwaltungsobjekte definiert. Stattdessen wird der entsprechende Schnittstellentyp zur Neuorganisation hinzugefügt, wenn ein bestimmtes Übertragungsmedium verwaltet werden muss.
SNMP-Gruppe: Diese Gruppe definiert Objekte im Zusammenhang mit SNMP im Detail. Zum Beispiel Statistiken über die Anzahl verschiedener Fehlertypen, die für das Fehlermanagement verwendet werden können, ob ein Trap-Authentifizierungsfehler Nachrichtenobjekte generiert, die für das Konfigurationsmanagement verwendet werden können, Statistiken über die Anzahl verschiedener gesendeter und empfangener Nachrichten, die für verwendet werden können Leistungsmanagement.
In SNMP sind alle Verwaltungsobjekte in einer Baumstruktur organisiert und die Verwaltungsobjekte sind als Baumknoten verkörpert der Baum, und dieser Baum wird von relevanten internationalen Standardisierungsorganisationen gepflegt und verwaltet. Durch diese strukturierte und hierarchische Organisation ist es sehr komfortabel, Objekte zu verwalten und zu erweitern. Diese Verwaltung und Erweiterung spiegelt sich in der Zuweisung von Knoten wider.
Unternehmen, Organisationen oder Einzelpersonen haben das Recht, Knoten von internationalen Organisationen zu beantragen, um eine Zweigstelle in der Baumstruktur zu werden. Nachdem Sie sich erfolgreich für einen Knoten beworben haben, können Sie andere Knoten unter der Verzweigung frei zuweisen, um deren Überwachungs- oder Verwaltungsgeschäftsanforderungen zu erfüllen.
OID-Nummer, auch MIB-Nummer genannt. MIB ist eigentlich ein aus OIDs bestehendes ASN.1-Modul, das in Wirklichkeit in einer Baumstruktur verkörpert ist. Es gibt viele Standard-MIBs im Internet, die MIB-I, MIB-II usw. definieren und auch von Unternehmen, Organisationen und Einzelpersonen definierte MIBs umfassen. Wie unten gezeigt.
Im OID-Baum hat nur der Wurzelknoten der obersten Ebene keine bestimmte Nummer und kann als virtueller Knoten betrachtet werden. Die anderen Knoten haben alle eine eindeutige Nummer auf derselben Ebene .
Die Knoten der nächsten Ebene oben sind ccitt (0), verwaltet von CCITT (der aktuellen ITU-T), und ISO (1), verwaltet von ISO.
Es gibt viele Unterknoten unter dem Internetknoten. Verzeichnis (1) ist reserviert und kann in Zukunft für OSI-Verzeichnisdienste verwendet werden. mgmt(2) liegt in der Verantwortung des IAB und wird verwendet, um Standardverwaltungsobjekte in RFC zu definieren, bei denen es sich eigentlich um MIB-I und MIB-II handelt. experimentell(3) wird ebenfalls vom IAB verwaltet und dient zur Definition von Verwaltungsobjekten der experimentellen Natur des Internets. Private (4) und die untergeordneten Knoten Unternehmen (1) werden von der IANA zugewiesen und verwaltet. Der Knoten Unternehmen (1) wird hauptsächlich für die Zuordnung zu verschiedenen Unternehmen oder Organisationen verwendet.
Die OID-Baumstruktur ist in Abbildung 13-2 unten dargestellt.
zu SNMP Bei der Überwachung von Elementoptionen wird empfohlen, die Optionen „Art der Informationen“ und „Wert speichern“ wie in der folgenden Tabelle gezeigt zu konfigurieren.
Typ
Beschreibung Beschreibung |
ZabbixEmpfohlene Überwachungselementoptionen |
INTEGER MIT SYMBOL 32 ist eine ganze Zahl |
||||||||||||||||||||||||||||||||||||||||||||
Text | Speicherwert: wie er ist
|
|||||||||||||||||||||||||||||||||||||||||||||
Charakter | Store -Wert: Wie ist |
|
||||||||||||||||||||||||||||||||||||||||||||
Numerisch, vorzeichenlos, dezimal | Speicherwert: Delta (Geschwindigkeit pro Sekunde) |
|
||||||||||||||||||||||||||||||||||||||||||||
Numerisch, vorzeichenlos, dezimal Richtung, bis es die erreicht Maximalwert und beginnt dann wieder bei 0 zu zählen (0 .. 18446744073709551615) | Numerisch Ohne Vorzeichen, dezimal |
|
||||||||||||||||||||||||||||||||||||||||||||
unsigned Integer, Modulo 2^32 (4294967296), einhundertstel einer Sekunde zwischen zwei Werten, die nicht signiert, dezimaler Wert: wie ist is |
Beschreibung #🎜 🎜# |
1.3.6.1.2 .1 .2.2.1.1 |
|
ifDescr# ?? #🎜 🎜# | ifType | 1.3.6.1.2.1.2.2.1.3 |
ifMtu |
#🎜 🎜 #1.3 .6.1.2.1.2.2.1.4 | |
#🎜 🎜 ## 🎜🎜 ## 🎜🎜#ifspeed#🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜#1.3.6.1.2.1.2.2.1.5#🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜 🎜#Portgeschwindigkeit# 🎜🎜# |
ifPhysAddress | 1.3.6.1.2. 1 .2.2.1. 6# 🎜🎜# |
ifAdminStatus # 🎜🎜 # |
1.3.6.1.2.1.2.1.7 | |
# 🎜🎜#ifOperStatus | 1.3.6.1.2.1.2.2.1.8 | # 🎜 🎜##🏜 🎜#1.3.6 .1 .2.1.2.2.1.10 |
# 🎜🎜# #🎜🎜 #ifInUcastPkts |
1.3.6.1.2.1.2.2.1.11 | Anzahl der vom Port empfangenen Nicht-Broadcast-Pakete |
ifInNUcastPkts #🎜🎜 # |
1.3.6.1.2.1.2.2.1.12 | Anzahl der vom Port empfangenen Broadcast-Pakete # 🎜🎜##🎜🎜 # |
1.3.6.1.2.1.2.2.1.13#🎜 🎜## ?? 🎜 # | #🎜 🎜#1.3.6.1.2.1.2.2.1.14Anzahl der Port-Empfangspaketfehler |
#🎜 🎜# # 🎜🎜# | ifInUnknownProtos
1.3.6.1.2.1.2.2.1.15 #🎜🎜 ##🎜 🎜##🎜 🎜#Port Anzahl der empfangenen unbekannten Protokollpakete |
ifOutOctets | |
Anzahl der vom Port gesendeten Bytes |
#🎜🎜 # #🎜🎜 #ifOutUcastPkts |
1.3.6.1.2.1.2.2.1.17 |
ifOutNUcastPkts | #🎜🎜 #1.3.6.1.2.1.2. 2.1.18# 🎜🎜#Anzahl der vom Port gesendeten Broadcast-Pakete | |
ifOutDiscards # 🎜🎜# |
1.3.6.1.2.1.2.2.1.19 | #🎜 🎜 #Anzahl der vom Port gesendeten verworfenen Pakete
|
1.3 .6.1.2.1.2.2.1.20 | #🎜🎜 # Anzahl der Fehler beim Senden von Portpaketen | |
#🎜🎜 # 1.3.6.1.2.1.2.2.1.21 |
Port-Sendewarteschlangenlänge |
3 SNMP konfigurierenBevor Sie mit der Konfiguration von SNMP in Zabbix beginnen, stellen Sie bitte sicher, dass der Zabbix-Server die SNMP-Überwachungsfunktion aktiviert hat. Wenn der Zabbix-Server startet, wird die Funktionsliste des Zabbix-Servers wie folgt in der Protokolldatei aufgeführt: 911:20160218:103649.120 Zabbix-Server wird gestartet 3.0.1 (Revision58734). 911:20160218:103649.160 *** * ** Aktivierte Funktionen ****** 911:20160218:103649.160 SNMP-Überwachung: JA 911:20160218:103649.160 IPMI-Überwachung: JA . 911:20160218:103649.1 60 Webüberwachung: JA 911:20160218 : 103649.160 VMware-Überwachung: JA 911:20160218:103649.160 SMTP-Authentifizierung: JA 911:20160218:103649.160 Jabber-Benachrichtigungen: JA . 911:20160218:1036 49.160 Ez SMS-Benachrichtigungen: JA 911:20160218:103649.160. ODBC: 911:20160218:103649.160 SSH2-Unterstützung: JA 911:20160218:103649.160 IPv6-Unterstützung: JA 9 11:20160218:103649.160 TLS-Unterstützung: JA 911: 20160218:103649.160 *********** ******************* 911:20160218:103649.160 unter Verwendung der Konfigurationsdatei:/etc/zabbix/zabbix_server.confWenn keine Informationen zum Aktivieren der SNMP-Überwachung gefunden werden, Dann müssen Sie Zabbixserver installieren. Wenn Sie zum Kompilieren und Installieren Quellcode verwenden, müssen Sie die Kompilierungskonfigurationsoption --with-net-snmp verwenden. Für die SNMP-Überwachung in Zabbix wird nur das UDP-Protokoll verwendet. In einer Anforderung können mehrere Werte abgefragt werden, unabhängig davon, ob es sich um reguläre SNMP-Elemente, dynamische Indizes (dynamische Indizes) SNMP-Elemente oder SNMP-Erkennungsregeln auf niedriger Ebene handelt Nützlich bei der Verarbeitung einer großen Anzahl von SNMP-Protokollen, die für Effizienz sorgen können. Aktivieren oder deaktivieren Sie Massenabfragen, indem Sie die Option Massenanfragen der SNMP-Schnittstellen des Hosts verwenden festlegen. Wie in Abbildung 13-4 unten dargestellt. Abbildung 13-4Alle SNMP-Überwachungselemente mit denselben Parametern in einer einzelnen Schnittstelle werden gleichzeitig in einem festgelegten Zeitintervall abgefragt. Bei regulären SNMPitems und dynamischen Index-SNMPitems verarbeiten Poller 128 Überwachungselemente Gleichzeitig werden SNMP-Erkennungsregeln auf niedriger Ebene separat verarbeitet. Während der Abfrage werden zwei Arten von Vorgängen ausgeführt: das Sammeln mehrerer angegebener Objekte und das Durchlaufen des OID-Baums. Sammlung bedeutet, dass eine GetRequest-PDU an bis zu 128 Variablen gebunden werden kann. Traversal bedeutet die Verwendung von GetNextRequest-PDU in SNMP v1 und die Verwendung von GetBulkRequest mit dem Feld „max-repetitions“ in SNMP v2 oder SNMP v3, das bis zu 128 Variablen binden kann. Variable. Daher hat die Stapelverarbeitung jedes SNMP-Überwachungselements die folgenden Vorteile:
Die aktuellen Batch-Abfrageelemente werden halbiert, d. h. es werden 21 Variablen abgefragt. Wenn das Gerät einen normalen Wert zurückgibt, sollte es in den meisten Fällen kein Problem geben, da wir wissen, dass die Abfrage von 28 Variablen kein Problem darstellt und 21 deutlich kleiner als 28 sein muss. Wenn Sie nach der Halbierung des Elements immer noch keinen normalen Rückgabewert erhalten, müssen Sie die Anzahl der abgefragten Variablen nacheinander zurücksetzen, bis Sie einen normalen Rückgabewert erhalten. Zabbix fragt in nachfolgenden Abfragen mit der Anzahl der Variablen ab, die beim letzten Mal erfolgreich abgefragt wurden (in unserem Beispiel 28), und erhöht die Anzahl der angeforderten Abfragevariablen weiter (jedes Mal um 1 erhöhen), bis die Obergrenze erreicht ist . Nehmen Sie beispielsweise an, dass die maximale Antwort 32 Variablen beträgt. Nachfolgende Anfragen werden gemäß 29, 30, 31, 32 und 33 abgefragt, vorzugsweise schlägt eine Anfrage fehl (33 Variablen) und Zabbix wird nie eine weitere Anfrage ausgeben, die 33 Variablen bindet. Die SNMP-Abfrage von Zabbix kann bis zu 32 Variablen auf diesem Gerät binden. Wenn der Zabbix-Server oder Proxyserver eine falsche SNMP-Antwort empfängt, wird der Protokolldatei ein Inhalt ähnlich dem folgenden hinzugefügt: Die SNMP-Antwort vom Host „Gateway“ enthält nicht alle angeforderten Variablenbindungen Diese Informationen sind jedoch vorhanden Nicht alle problematischen Situationen werden abgedeckt, aber mindestens eine besagt, dass die Option „Massenanfragen verwenden“ in der SNMP-Schnittstelle des Hosts deaktiviert werden sollte. 4 Konfigurieren Sie reguläre SNMP-ÜberwachungselementeBei Verwendung von SNMP-Überwachungsgeräten können reguläre SNMP-Überwachungselemente wie folgt konfiguriert werden: Erstellen Sie einen Host und fügen Sie ihm eine SNMP-Schnittstelle hinzu. Sie können die in Zabbix bereitgestellte Vorlage SNMP Generic verwenden, um automatisch Überwachungselemente hinzuzufügen, die grundlegende Informationen über das Gerät sammeln. 2. Bestimmen Sie die überwachte OID. Verwenden Sie den MIB-Browser oder snmpwalk, um die OID zu finden und zu bestimmen, die überwacht werden muss. Wenn wir beispielsweise den Datenverkehr eines geschalteten Gigabit-Ports überwachen möchten, ist der Index der über snmpwalk gefundenen GigabitEthernet0/1-Schnittstelle 10101 . # snmpwalk -v 2c -c public 10.60.0.19 IF-MIB::ifDescr GigabitEthernet0/1 kann in den String-Wert von IF-MIB::ifDescr.10101 IF-MIB::ifDescr. 10102 umgeschrieben werden = STRING: GigabitEthernet0/2 GigabitEthernet0/3 wird als IF-MIB::ifDescr.10103 identifiziert. Die Zeichenfolge „GigabitEthernet0/4“ ist der Wert von „ifDescr.10104“ in IF-MIB IF-MIB ::ifDescr.10105 = STRING: GigabitEthernet0/5 Der String „IF-MIB::ifDescr.10106“ entspricht „GigabitEthernet0/6“ IF-MIB::ifDescr.10107 = STRING: GigabitEthernet0/7 … Die für den Ausgangsverkehr der GigabitEthernet0/1-Schnittstelle erhaltene OID ist .1.3.6.1.2.1.2.2.1.16.10101. # snmpwalk -v 2c -on -c qhdpublic 10.60.0.19if -mib :: ifoutoctets SNMPv2-Agent-Überwachungsmodus, SNMP-OID ist .1.3.6.1.2.1.2.2.1.16.10101. 5 Dynamische Index-SNMP-Überwachungselemente konfigurieren Im OID-Baum des Geräts verwenden die OIDs einiger Verwaltungsobjekte häufig Indizes, z. B. Netzwerkschnittstellen. Derselbe Index wird für die Zuordnung zu verschiedenen Objekten der Netzwerkschnittstelle verwendet. Genau wie die snmpwalk-Ausgabe unten. # snmpwalk -v 2c -c public 10.60.0.19 .1.3.6.1.2.1.2.2.1IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.5001 = INTEGER: 5001 IF-MIB::ifIndex.5002 = INTEGER: 5002 IF-MIB::ifIndex.5003 = INTEGER: 5003 IF-MIB::ifIndex.10101 = INTEGER: 10101 IF-MIB:: ifIndex.10102 = INTEGER: 10102 ... IF-MIB::ifDescr.1 = STRING: Vlan1 IF-MIB::ifDescr.5001 = STRING: Port-channel1 IF-MIB::ifDescr .5002 = STRING: Port-channel2 IF-MIB::ifDescr.5003 = STRING: Port-channel3 GigabitEthernet0/1 kann als String-Wert von IF-MIB::ifDescr.10101 IF-MIB umgeschrieben werden ::ifDescr.10102 = STRING: GigabitEthernet0/2 ... IF-MIB::ifType.1 = INTEGER: propVirtual(53) IF-MIB::ifType.5001 = INTEGER: propVirtual(53) IF-MIB::ifType.5002 = INTEGER: propVirtual(53) IF-MIB::ifType.5003 = INTEGER: propVirtual(53) IF-MIB::ifType.10101 = INTEGER: ethernetCsmacd( 6 ) IF-MIB::ifType.10102 = INTEGER: ethernetCsmacd(6) ... IF-MIB::ifMtu.1 = INTEGER: 1500 IF-MIB::ifMtu.5001 = INTEGER : 1500 IF-MIB::ifMtu.5002 = INTEGER: 1500 IF-MIB::ifMtu.5003 = INTEGER: 1500 IF-MIB::ifMtu.10101 = INTEGER: 1500 IF-MIB: ; 5002 = Gauge32: 2000000000 IF-MIB::ifSpeed.5003 = Gauge32: 1000000000 IF-MIB::ifSpeed.10101 = Gauge32: 1000000000 IF-MIB::ifSpeed.1 0102 = Gauge32: 1000000000 .. IF-MIB::ifPhysAddress.1 = STRING: b0:7d:47:be:ea:c0 IF-MIB::ifPhysAddress.5001 = STRING: b0:7d:47:be: ea:c2 IF-MIB::ifPhysAddress.5002 = STRING: b0:7d:47:be:ea:c3 IF-MIB::ifPhysAddress.5003 = STRING: b0:7d:47:be:ea: c4 IF-MIB::ifPhysAddress.10101 = STRING: 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 = INTEGER: up(1) IF-MIB::ifAdminStatus.10101 = INTEGER: up(1) IF-MIB::ifAdminStatus.10102 = INTEGER: up(1) ... Aus den obigen Daten können Sie erkennen, dass jedes Netzwerk Schnittstellen verfügen über viele OIDs, und jede OID stellt unterschiedliche Indikatoren der Netzwerkschnittstelle dar, z. B. den Namen, den Typ, die physische Adresse usw. der Schnittstelle. Sie werden feststellen, dass verschiedene OIDs über denselben Index verknüpft sind. Beispielsweise lautet der Name der ersten Gigabit-Schnittstelle GigabitEthernet0/1, die physische Adresse ist b0:7d:47:be:ea:c2, der Status ist aktiv (1) und ihr Index ist 10101. Um verschiedene Indikatoren derselben Netzwerkschnittstelle zu überwachen, können Sie verschiedene Überwachungselemente erstellen und die vollständige OID in das SNMP-OID-Feld eingeben. Bei dieser Methode gibt es kein Problem, bei der Verwendung des Index in der tatsächlichen Umgebung treten jedoch einige Probleme auf. Der Grund dafür ist, dass sich der Index aufgrund von Software- oder Hardware-Upgrades ändert, was zu Konfigurationsinkonsistenzen führt. Um dieses Problem zu lösen, stellt Zabbix eine dynamische Indexmethode bereit, die die Überwachung von Überwachungselementen nicht beeinträchtigt, selbst wenn sich der Indexwert ändert. Die Syntax für die Verwendung dynamischer Indizes SNMP OID lautet wie folgt: Die Bedeutung von Jeder Teil in der Syntax lautet wie folgt:
Wenn Sie beispielsweise die ifInOctets der GigabitEthernet0/1-Schnittstelle überwachen möchten, kann diese gemäß der Syntax wie folgt definiert werden: ifInOctets["index", "ifDescr", "GigabitEthernet0/1"] kann als Abgleich und Suche nach GigabitEthernet0 in der ifDescr/1-Schnittstelle und/oder dem Indexwert dieser Schnittstelle in ifDescr verstanden werden und dann den gesammelten Indexwert an ifInOctets anhängen, wodurch der ifInOctets-Wert der GigabitEthernet0/1-Schnittstelle erfasst wird. Bei Verwendung dynamischer Indizes empfängt und speichert Zabbix die gesamte SNMP-Tabelle der Index-OID. Die Index-OID kann schnell über den Cache ermittelt werden. Wenn andere Überwachungselemente in Zukunft dieselbe Index-OID abfragen, wird diese direkt durchsucht Aus dem Cache ist keine Abfrage des Überwachungshosts erforderlich. Beim Empfang der Daten des Überwachungselements wird überprüft, ob sich der Index geändert hat. Wenn der Index keine Änderungen sendet, wird die Wertabfrage weiterhin verwendet. Wenn der Index Änderungen sendet, erstellt Zabbix den Cache neu. und jeder Poller durchläuft die SNMP-Tabelle der Index-OID erneut. In Zabbix hat jeder Poller-Prozess seinen eigenen Cache. 6 SNMP-Erkennungsregeln auf niedriger Ebene konfigurierenBeim Erstellen von Erkennungsregeln für SNMP-OIDs verwenden Sie im Gegensatz zum Definieren von Erkennungsregeln für Dateisysteme oder Netzwerkschnittstellen nicht den snmp.discovery-Schlüssel. Sie können die SNMP-Agnet-Überwachungsmethode verwenden. In SNMPOID werden die zu erkennenden OIDs im Feld im Format „Discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, …,] definiert. {#MACRO1}, {#MACRO2}... sind alle gültige Makrovariablennamen, oid1, oid2... werden zum Generieren der Werte von Makrovariablen verwendet. Bei der Erkennung erstellt das System standardmäßig eine Makrovariable mit dem Namen {#SNMPINDEX}, die zum Erstellen eines Index für die Erkennungs-OID verwendet wird. Die Erkennungsergebnisse werden nach {#SNMPINDEX} gruppiert. Die folgenden Beispiele können Ihnen helfen, es besser zu verstehen. Verwenden Sie zunächst snmpwalk, um relevante Daten vom Switch zu sammeln. # snmpwalk -v 2c -OT -c public 10.60.0.19 IF-MIB::ifDescr IF-MIB::ifDescr.1 = STRING: Vlan1 GigabitEthernet0/1 kann in IF-MIB:: String umgeschrieben werden Wert von ifDescr.10101 IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2 GigabitEthernet0/3 wird als IF-MIB::ifDescr.10103. # snmpwalk -v 2c -OT - c public identifiziert 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 = STRING: b0:7d:47:be:ea:c3 IF-MIB::ifPhysAddress.10103 = STRING: b0:7d: 47: be:ea:c4 Geben Sie dann beim Erstellen der Erkennungsregel in das SNMP-OID-Feld ein: discovery[{#IFDESCR}, ifDescr, {#IFPHYSADDRESS}, ifPhysAddress] Nachdem Sie die Erkennungsregel ausgeführt haben, erhalten Sie Folgendes Ergebnisse: { „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" ) Es gibt keinen Rückgabewert und das entsprechende Makro wird in den Erkennungsergebnissen ignoriert, wie im Beispiel unten. Die angenommenen Daten lauten wie folgt: ifDescr.1 „Interface #1“ ifDescr.2 „Interface #2“ ifDescr.4 „Interface #4“ ifAlias.1 „eth0“ ifAlias .2 „eth2“ ifAlias.3 „eth3“ ifAlias.5 „eth5“ Dann geben Sie beim Erstellen der Erkennungsregel in das SNMP-OID-Feld ein: discovery[{#IFDESCR},ifDescr, {#IFALIAS }, ifAlias ] Nach dem Ausführen der Erkennungsregel erhalten wir die folgenden Ergebnisse: { „data“: [ „{ „{#SNMPINDEX}“: 1, „{#IFDESCR} ”: #1" , IFDESCR}": "Schnittstelle #2", "{ #IFALIAS}" : „eth2“ }, SNMPINDEX}": 4, "{#IFDESCR}" :"Schnittstelle #4" "{#SNMPINDEX}": 5, "{#IFALIAS}": "eth5"
Abbildung 13-5 Erstellen Sie einen Artikelprototyp basierend auf den definierten Erkennungsregeln, wie in Abbildung 13-6 unten dargestellt. Abbildung 13-6Sie können mehrere Artikelprototypen erstellen, wie in Abbildung 13-7 unten dargestellt.Bild 13-7 |
Das obige ist der detaillierte Inhalt vonWelche Netzwerkgeräte überwacht Zabbix 3.0?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!