Zabbix - Überwachung von OSPF-Nachbarn mithilfe von SNMPv3-TRAPs, Schmerz und Verzweiflung

Technische Aufgabe

Es gibt ein Netzwerk von geografisch verteilten Rechenzentren mit einem VRF-Auto und einer sich ständig ändernden Liste von OSPF-Nachbarn. Sie müssen sie verfolgen:

1. Status, Alarm auslösen, wenn der Nachbarstatus nicht VOLL ist
2. Menge, dh wenn der Nachbar fehlt, müssen Sie auch einen Alarm auslösen

Ein Überwachungssystem existiert bereits - Zabbix 3.4, es ist wünschenswert, es zu verwenden, Linux OS Debian 9.x.

Wir versuchen es mit einem Schnappschuss

Das Protokoll ist weit verbreitet, das Überwachungssystem ist bekannt, ich bin wahrscheinlich nicht der erste, der dieses Problem lösen möchte, und höchstwahrscheinlich wurde es bereits gelöst.

Wir machen uns auf die Suche nach "zabbix ospf" und der erste Link führt zur Vorlage . Glück ist was - jetzt importiere ich es, kämme es nach meinen Bedürfnissen und alles wird in Ordnung sein.
Wir überprüfen, wie es funktioniert - alles scheint in Ordnung zu sein, die Zustände werden überwacht, aber wenn der Nachbar in den Zustand AB geht, erhalten wir eine „sehr“ informative Nachricht von Zabbix

No Such Instance currently exists at this OID 

und info

 The item is not discovered anymore and will be deleted in 29d 23h 57m (on 2018-08-19 at 08:52) 

Was passiert ist - das Problem ist alt und in den Foren bekannt -, wenn der OSPF-Nachbar verschwindet, werden alle damit verbundenen OIDs einfach auf der Netzwerkhardware gelöscht.

Ja, es gibt eine Lösung - erstellen Sie einen Nodata-Trigger, ok, erstellen Sie:

 {Template - SNMPv3 - OSPF Discovery:ospfNbrState[{#SNMPVALUE}].nodata(120)}=0 

Wir sehen im Dashboard:

 OSPF neighbor 192.168.192.168 missing data 

Grundsätzlich ... verwendbar

Standardmäßig erkennt LLD jedoch nur Nachbarn von der Standard-VRF. Natürlich kann dies mithilfe des SNMP-Kontexts behoben werden, aber irgendwie wollte ich diesen Weg überhaupt nicht gehen - wir mussten alle Eisenstücke durchgehen, einen Kontext in jeden OSPF-Prozess oder VRF einfügen und dann Kopien von Discovery für jeden Kontext in unserer Vorlage erstellen. Im Allgemeinen ist es ein bisschen viel Aufhebens und wenn Sie neue OSPF-Prozesse hinzufügen, müssen Sie an mehreren Stellen etwas ändern. Sie können natürlich von Skripten umgeben sein und über die Zabbix-API kann dies alles geändert werden, aber ich wollte keine spezielle Benutzerdefinierung, sondern nur die in Zabbix integrierte Funktionalität maximal nutzen. Es wird eine bestimmte CISCO-CONTEXT-MAPPING-MIB erwähnt, aus der Sie die gesamte Korrespondenz zwischen Kontexten und OSPF / VRF abrufen können, aber ich habe nicht herausgefunden, wie dieses Design an LLD befestigt werden kann. Wenn jemand weiß, wie man Zabbix so cool kocht, dann willkommen zu den Kommentaren und vorzugsweise zu einem vollständigen Artikel.

Wir versuchen es ab dem zweiten Angriff

Nach ein paar Stunden Durchsuchen des Internets nach Hinweisen in Foren und außerhalb des Speicherbereichs wurde ein Thema zu SNMP TRAP angesprochen. In diesem Fall wird das Eisenstück nicht abgefragt, aber das Eisenstück sendet Informationen über Änderungen. Ja, und die Kampagnenunterstützung für dieses Zeug ist in unserem Überwachungssystem sofort einsatzbereit . Die Ausrüstung kann auch sofort und nur für meinen Fall verwendet werden.

In den ersten Zeilen war die Überwachungsdokumentation durch eine lange Liste verwirrt:

 The workflow of receiving a trap: 1. snmptrapd receives a trap 2. snmptrapd passes the trap to SNMPTT or calls Perl trap receiver 3. SNMPTT or Perl trap receiver parses, formats and writes the trap to a file 4. Zabbix SNMP trapper reads and parses the trap file 5. For each trap Zabbix finds all “SNMP trapper” items with host interfaces matching the received trap address. Note that only the selected “IP” or “DNS” in host interface is used during the matching. 6. For each found item, the trap is compared to regexp in “snmptrap[regexp]”. The trap is set as the value of all matched items. If no matching item is found and there is an “snmptrap.fallback” item, the trap is set as the value of that. 7. If the trap was not set as the value of any item, Zabbix by default logs the unmatched trap. (This is configured by “Log unmatched SNMP traps” in Administration → General → Other.) 

Das heißt, ein Daemon akzeptiert TRAP, übergibt es an einen anderen Daemon, analysiert es, legt es im gewünschten Format im Protokoll ab, und der Zabix liest das Protokoll bereits und entscheidet, was als nächstes zu tun ist. Irgendwie sieht es schon nie einfacher aus, als mit den Händen zu gehen und überall einen SNMP-Kontext zu zeichnen, aber na ja, versuchen wir es. Wir lesen das Überwachungsdokument sorgfältig durch und verstehen, dass nur mit seiner Hilfe nichts konfiguriert werden kann. Im Allgemeinen hat Zabbix einen solchen Witz - die Dokumentation beschreibt die Fähigkeiten und Nuancen des Systems so minimal, dass es verwirrender ist als gelehrt. Sie können zwar verstanden werden - die Software ist kostenlos, aber irgendwie muss man Geld verdienen, aber sie verdienen Geld für Support. Es gibt Artikel im Internet mit einer Beschreibung, wie man dies ein- oder zweimal einrichtet, aber ich konnte es nicht schaffen, von einem Artikel zum nächsten zu wechseln. Ich musste nach und nach Informationen aus verschiedenen Quellen sammeln. Das sind alle Texte, die sie gefahren sind, um Hardcore zu machen.

Wir konfigurieren ein Netzwerkstück Eisen

Bevor Sie mit der Überwachung etwas auf dem Host verdrehen, empfehle ich dringend, zuerst die Netzwerkhardware zu konfigurieren und sicherzustellen, dass TRAP wirklich von der Hardware zum Server gelangt. Zuerst habe ich nicht überprüft, ob es viel Nerven, Blut und Zeit getrunken hat. Ich habe ein Cisco Nexus-Auto zur Hand, daher gebe ich Beispiele für diese Serie. Wer auch immer Catalyst, ASR, ASA usw. hat - Entschuldigung, ich bin nicht die Sonne, ich werde nicht alle heizen, lesen Sie die Docks, wie Sie dies selbst konfigurieren können, die Syntax wird ähnlich sein, aber mit ihren eigenen Nuancen.

 snmp-server contact noc@example.com snmp-server location Room1 snmp-server source-interface traps loopback1 

Bei der Konfiguration von TRAP in Zabbix ist es in Zukunft wichtig, dass die Adresse, von der TRAP gesendet wird, der SNMP-Adresse der Schnittstelle in den Hosteinstellungen in Zabbix entspricht.

 snmp-server user Zabbix network-operator auth sha string priv aes-128 string 

Verwenden Sie nach Möglichkeit Version 3 des Protokolls. Im authPriv-Modus (Verschlüsselung und Authentifizierung) ist die Konfiguration nicht so schwierig, wie es scheint. Vergessen Sie Version 1 und Version 2 des Protokolls - wenn eine unerwartete Person aufgrund fehlender Verschlüsselung und im Wesentlichen Authentifizierung in diesen Protokollversionen eintrifft - ist dies nur eine Frage der Zeit (die Community-Zeichenfolge wird in klarer Form übertragen, außerdem sehe ich regelmäßig, dass sie öffentlich / privat konfiguriert ist). Mit dem Netzwerkbetreiberparameter können Sie dem Benutzer schreibgeschützte Berechtigungen erteilen.

 snmp-server host 192.168.192.168 traps version 3 priv Zabbix snmp-server host 192.168.192.168 use-vrf default snmp-server host 192.168.192.168 source-interface loopback1 no snmp-server enable traps ospf lsa snmp-server enable traps ospf no snmp-server enable traps entity entity_mib_change no snmp-server enable traps entity entity_module_status_change no snmp-server enable traps entity entity_power_status_change no snmp-server enable traps entity entity_module_inserted no snmp-server enable traps entity entity_module_removed no snmp-server enable traps entity entity_unrecognised_module no snmp-server enable traps entity entity_fan_status_change no snmp-server enable traps entity entity_power_out_change no snmp-server enable traps link linkDown no snmp-server enable traps link linkUp no snmp-server enable traps link extended-linkDown no snmp-server enable traps link extended-linkUp no snmp-server enable traps link cieLinkDown no snmp-server enable traps link cieLinkUp no snmp-server enable traps link connUnitPortStatusChange no snmp-server enable traps bfd session-up no snmp-server enable traps link delayed-link-state-change no snmp-server enable traps bfd session-down no snmp-server enable traps rf redundancy_framework no snmp-server enable traps license notify-license-expiry no snmp-server enable traps license notify-no-license-for-feature no snmp-server enable traps license notify-licensefile-missing no snmp-server enable traps license notify-license-expiry-warning no snmp-server enable traps upgrade UpgradeOpNotifyOnCompletion no snmp-server enable traps upgrade UpgradeJobStatusNotify no snmp-server enable traps rmon risingAlarm no snmp-server enable traps rmon fallingAlarm no snmp-server enable traps rmon hcRisingAlarm no snmp-server enable traps rmon hcFallingAlarm no snmp-server enable traps entity entity_sensor no snmp-server enable traps generic coldStart no snmp-server enable traps generic warmStart 

Ich habe alle TRAP-Dateien außer OSPF deaktiviert, sodass ich bei der Diagnose, warum etwas nicht funktioniert, nicht viele unnötige Informationen aus dem Debug lesen musste.

Es ist sehr einfach zu überprüfen, ob TRAP funktioniert - Sie müssen etwas kaputt machen. Wir starten den Sniffer auf dem Host mit Überwachung:

 root@dc-zbx:~# tcpdump -i bond0 udp port 162 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes 

Wir finden auf einem Stück Eisen lebende Nachbarn:

 SW# show ip ospf neighbors vrf all OSPF Process ID 10 VRF default Total number of neighbors: 4 Neighbor ID Pri State Up Time Address Interface 192.168.0.242 1 FULL/ - 01:47:17 172.17.0.10 Vlan1427 192.168.0.222 1 FULL/ - 18w1d 172.17.0.6 Vlan1426 192.168.1.149 1 FULL/ - 5w0d 172.17.0.30 Vlan1473 192.168.1.146 1 FULL/ - 3d00h 172.17.0.58 Vlan1404 OSPF Process ID 100 VRF OSPF100 Total number of neighbors: 4 Neighbor ID Pri State Up Time Address Interface 192.168.1.149 1 FULL/ - 5w0d 172.17.0.34 Vlan1474 192.168.0.220 1 FULL/ - 13w3d 172.17.0.54 Vlan1479 192.168.0.240 1 FULL/ - 13w3d 172.17.0.46 Vlan1477 192.168.1.146 1 FULL/ - 3d00h 172.17.0.62 Vlan1405 OSPF Process ID 200 VRF Dia Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 10.65.0.252 1 FULL/ - 17w2d 172.17.0.18 Vlan1450 172.17.0.26 1 FULL/ - 17w0d 172.17.0.26 Vlan1452 OSPF Process ID 216 VRF Dev Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 10.255.255.94 1 FULL/ - 18:59:59 10.216.0.73 Vlan1641 10.216.0.82 1 FULL/ - 18:59:54 10.216.0.82 Vlan1643 

Und jemanden fallen lassen

 interface vlan 1643 shutdown 

Wir sehen im Schnüffler:

 11:08:20.001942 IP 192.168.192.169.22095 > dc-zbx.example.com.snmp-trap: F=ap U="Zabbix" [!scoped PDU]39_d1_7c_19_b3_d9_f8_31_32_8e_c9_39_c2_3a_db_d8_28_26_c6_0b_01_55_b6_fa_5e_f5_38_66_f9_6f_3f_c0_98_cb_57_93_5a_50_8e_50_90_79_f3_9b_ec_ec_d7_9f_e8_ac_f6_fd_79_ac_95_ff_71_73_32_70_52_66_a5_7d_b3_c4_39_d0_1c_7f_a6_38_ea_d7_61_c0_2f_12_ee_db_d9_07_40_8c_a8_48_57_e9_e5_56_12_3f_ec_f9_34_65_09_96_86_f6_d2_93_06_45_fa_95_ea_36_5a_82_2f_30_8f_02_03_59_07_5f_d8_a6_1c_f2_5a_be_7d_09_15_ef_05_00_83_fd_ea_ac_2a_3b_86_0f_86_e5_3b_93_3a_68_6d_33_99_e2_46_2b_9d_6a_1e_5d_9e_d9_93_56_51_5e_ff_9e_77_4c_cb 

Wenn Sie im Sniffer nichts gesehen haben, diagnostizieren Sie es, da es sonst keinen Grund gibt, weiterzumachen. Sie werden einfach nicht verstehen, in welchem ​​Stadium etwas für Sie nicht funktioniert.
Wenn kein Stück Eisen zur Hand ist oder die Produktion nicht berührt werden kann, kann TRAP beispielsweise aus einem anderen Auto wie folgt generiert werden:

 snmptrap -v 1 -c neveruseme 127.0.0.1 '.1.3.6.1.6.3.1.1.5.3' '0.0.0.0' 6 33 '55' .1.3.6.1.6.3.1.1.5.3 s "teststring000" snmptrap -v3 -l authPriv -u Zabbix -a SHA -A abyrvalg -x AES -X pechka -e 0x8000000001020305 192.168.192.168 0 linkUp.0 

Konfigurieren Sie SNMPd, SNMPTRAPd, SNMPTT

Wir benötigen Pakete im System:

 apt install snmp snmp-mibs-downloader snmpd snmptrapd snmptt 

Ich habe mich nicht auf den Perl-Trap-Empfänger konzentriert, sondern mich aus persönlichen und subjektiven Gründen für SNMPTT entschieden. Das Dock sagt also:

 1. snmptrapd receives a trap 

Es ist notwendig, mit der Konfiguration zu beginnen und nicht sofort zu klettern, um ein Objekt im Zabbix-Gesicht zu erstellen. Warum so - Sie müssen die gleichen Stufen erklimmen, die TRAP gehen. Im vorherigen Abschnitt haben wir sichergestellt, dass TRAP im Wesentlichen von einem Stück Eisen stammt. Jetzt werden wir sicherstellen, dass es zumindest vom ersten Dämon akzeptiert wird - snmptrapd. <lyric> Ich erinnere mich, dass ich dort vor langer Zeit Postfix + Dovecot + etwas anderes eingerichtet habe. Und ich schmollte ungefähr zwei Wochen lang - auch dort akzeptiert ein Dämon die Verbindung, der andere analysiert den Brief, der dritte stellt ihn in die Warteschlange, der vierte in den Ordner für den Benutzer und so weiter, und es gelang mir nicht. Und das alles, weil ich mich von der Mitte, vom Ende, von Anfang an eingestellt habe, aber ich musste mit Telnet zu Port 25 beginnen und den Debugger des Foxers </ lyric> anzeigen

Wir klettern in /etc/snmp/snmptrapd.conf und löschen es. Stattdessen kommentieren wir alles, was wir nicht verstehen und nicht interessiert sind. Wir hinterlassen eine Zeile

 disableAuthorization yes 

Beenden Sie den Dienst

 systemctl stop snmptrapd.service 

Im manuellen Modus ausführen

 root@dc-zbx:~# snmptrapd -f -Lo NET-SNMP version 5.7.3 AgentX subagent connected NET-SNMP version 5.7.3 

Versuchen Sie erneut, OSPF wie im obigen Beispiel zu brechen, und sehen Sie:

 2018-07-20 11:38:38 UNKNOWN [UDP: [192.168.192.169]:22095->[192.168.192.168]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1355817272) 156 days, 22:09:32.72 SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfNbrStateChange OSPF-MIB::ospfRouterId = IpAddress: 10.216.0.74 OSPF-MIB::ospfNbrIpAddr = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrAddressLessIndex = INTEGER: 0 OSPF-MIB::ospfNbrRtrId = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrState = INTEGER: down(1) 

Wenn wir nicht sehen, suchen wir nach dem Grund dafür. Wenn Sie dieselben schönen Datensätze und keine OIDs der Form 1.3.6.1.2.1.14.10.1.6 haben möchten, fügen Sie Folgendes zu /etc/snmp/snmp.conf hinzu:

 mibs +OSPF-MIB mibs +OSPF-TRAP-MIB mibs +OSPFV3-MIB mibdirs +/usr/share/snmp/mibs/ietf/ 

Und SNMPd verzerren

 systemctl restart snmpd.service 

Weitere Informationen zum Herunterladen von MIB-Dateien mit den geringsten Schmerzen und zum Einspeisen in Ihr SNMPd finden Sie [hier] (https://wiki.debian.org/SNMP).

Jetzt befestigen wir die Authentifizierung und klettern erneut in /etc/snmp/snmptrapd.conf

 traphandle default snmptthandler #disableAuthorization yes # 192.168.192.169 createUser -e 0x80000009038d604a6a82a3 Zabbix SHA string AES authuser log,execute,net Zabbix 

-e 0x80000009038d604a6a82a3 ist die Engine-ID, die auf der Netzwerkhardware angezeigt werden kann:

 SW# sh snmp engineID Local SNMP engineID: [Hex] 80000009038F604D6A82A1 [Dec] 128:040:000:109:003:140:096:079:106:131:160 

Wir wiederholen das Experiment erneut, aber jetzt wird immer noch ein Debug über USM durchgeführt:

 root@dc-zbx:~# snmptrapd -f -Lo -Dusm registered debug token usm, 1 usmUser: created a new user Zabbix at 80 00 00 09 03 8F 60 4F 6B 82 A5 NET-SNMP version 5.7.3 AgentX subagent connected NET-SNMP version 5.7.3 usm: USM processing begun... usm: match on user Zabbix usm: no match on engineID (80 00 00 09 03 8F 60 4F 6B 82 A5 ) usm: match on user Zabbix usm: Verification succeeded. usm: USM processing completed. 2018-07-20 11:50:07 UNKNOWN [UDP: [192.168.192.169]:22095->[192.168.192.168]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1355886163) 156 days, 22:21:01.63 SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfNbrStateChange OSPF-MIB::ospfRouterId = IpAddress: 10.216.0.74 OSPF-MIB::ospfNbrIpAddr = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrAddressLessIndex = INTEGER: 0 OSPF-MIB::ospfNbrRtrId = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrState = INTEGER: down(1) 

Wenn zu diesem Zeitpunkt Autorisierungsfehler im Debug angezeigt werden, überprüfen Sie sorgfältig die engineID und stellen Sie sicher, dass die auf der Hardware erstellten Benutzer mit denen übereinstimmen, die wir in der Konfiguration /etc/snmp/snmptrapd.conf gezeichnet haben. Übrigens, ja, für jedes Stück Eisen müssen Sie Ihren eigenen Benutzer mit seiner engineID erstellen oder es mit Ihren Händen auf allen Eisenstücken gleich machen, wenn die Eisenstücke dies zulassen.

Ich kann die Zeile im Debug sehen:

 usm: no match on engineID (80 00 00 09 03 8F 60 4F 6B 82 A5 ) 

Warum habe ich nicht verstanden, obwohl mit all dem TRAP akzeptiert wird und zur weiteren Verarbeitung kommt. Wenn Sie wissen, was ich falsch gemacht habe, kommentieren Sie bitte.

Jetzt nehmen wir SNMPTT auf - es hat zwei ini und conf config. Im ersten bestimmen wir die Parameter des Dämons selbst, im zweiten bestimmen wir die Parameter für den Empfang und die Verarbeitung jeder bestimmten Leiter.

Wir klettern in die Datei /etc/snmp/snmptt.ini und zeichnen die folgenden Dinge:

 mode = daemon net_snmp_perl_enable = 1 date_time_format = %Y %m %d %H:%M:%S 

Das Format von Datum und Uhrzeit ist eine Frage des Geschäfts, vor allem überall gleich.

 log_file = /var/log/snmptt/snmptt.log log_system_file = /var/log/snmptt/snmpttsystem.log unknown_trap_log_enable = 1 unknown_trap_log_file = /var/log/snmptt/snmpttunknown.log 

Warum ist das Protokoll nicht dasselbe wie in vielen Artikeln im Internet? Da das Dock sagte: "Wenn der systemd-Parameter PrivateTmp verwendet wird, funktioniert diese Datei wahrscheinlich nicht in / tmp." Ich möchte nicht erneut in den Rake einsteigen, wenn ich vorher gewarnt werde. Daher wechsle ich sofort zum normalen Pfad zur Datei.

Gehen Sie als Nächstes zu /etc/snmp/snmptt.conf, entfernen Sie alles, was wir nicht benötigen und / oder nicht verstehen. Wir lassen nur Folgendes:

 EVENT ospfNbrStateChange .1.3.6.1.2.1.14.16.2.2 "OSPF" Normal FORMAT ZBXTRAP $aA OSPF neighbor with IP addr $2 changed state to $5 

In dieser Form, weil Zabbix genau ein solches Format im Protokoll erwartet. Woher $ 2 und $ 5 kommen, können Sie herausfinden, ob Sie sich das TRAP-Nachrichtenformat ansehen:

 Object ospfNbrStateChange OID 1.3.6.1.2.1.14.16.2.2 MIB OSPF-TRAP-MIB ; Trap Components ospfRouterId ospfNbrIpAddr ospfNbrAddressLessIndex ospfNbrRtrId ospfNbrState 

Diese Trap-Komponenten sind die Parameter, die in der Reihenfolge $ 1, $ 2 ... in das Protokollformat verschoben werden können.

Während des Showdowns mit all diesen Dingen habe ich festgestellt, dass es nach dem Ändern der SNMPTT-Einstellungen so ist, als würden die Änderungen nicht übernommen. Es stellte sich heraus, dass nach ihrer Änderung nicht snmptt.serivce, sondern snmpd.service neu gestartet werden musste - diese Nuance trank anständig mein Blut und trank meine Nerven während des Debuggens.

Überprüfen Sie, ob alle Dämonen ausgeführt werden:

 systemctl status snmpd snmptrapd snmptt 

Wenn alles in Ordnung ist, versuchen Sie erneut, OSPF zu brechen, und rufen Sie das Protokoll /var/log/snmptt/snmptt.log auf. Es sieht folgendermaßen aus:

 2018 07 19 15:10:52 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to down 2018 07 19 15:12:28 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart 2018 07 19 15:12:34 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to full 2018 07 19 15:22:41 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to down 2018 07 19 15:25:38 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart 

Die TRAPs, die wir nicht in der Konfiguration /etc/snmp/snmptt.conf konfiguriert haben, werden in das Protokoll /var/log/snmptt/snmpttunknown.log verschoben, jedoch nur von der Hardware, für die der richtige Benutzer und die richtige Engine-ID in derselben Konfiguration konfiguriert sind. Das heißt, von den linken Drüsen werden die TRAPs nur lautlos fallen gelassen. Wenn Sie Matan und Nachbesprechung wünschen, dann haben Sie hier ein ungewöhnlich vernünftiges Dock auf net-snmp. Der Unterschied zwischen TRAP und INFORM ist dort immer noch gut beschrieben. Mit Blick auf die Zukunft ist es besser, INFORM usw. zu verwenden. k. Es gibt dort eine Art Zustellungskontrolle, die jedoch über UDP über UDP funktioniert.

Und erst jetzt klettern wir, um unseren Monitor zu konfigurieren.

Zabbix-Setup

Stellen Sie zunächst sicher, dass in der Konfiguration /etc/zabbix/zabbix_server.conf die Überwachung auf das richtige SNMPTT-Protokoll eingestellt ist und Zabbix selbst mindestens einen SNMP-Trapper startet:

SNMPTrapperFile=/var/log/snmptt/snmptt.log
StartSNMPTrapper=1

Für den Anfang habe ich Item direkt auf dem Host erstellt, damit Spezialeffekte schneller und einfacher erfasst werden können. Hier schreibe ich sofort, wie eine Vorlage erstellt wird, da diese Vorlagen nach Möglichkeit verwendet werden sollten. Ich zeige Ihnen die Bilder, das Werbegeschenk zum Kopieren und Einfügen ist vorbei, aber ich male die Stellen, auf die Sie achten müssen.

Erstellen Sie eine Vorlage:



Hier geben wir nur einen vernünftigen Namen

Element erstellen



Wichtig - der Schlüssel sollte so sein. In eckigen Klammern wird angegeben, wonach Zabbix im Protokoll suchen wird. Wir haben das Protokollformat in /etc/snmp/snmptt.conf konfiguriert und dort geschrieben:

 EVENT ospfNbrStateChange .1.3.6.1.2.1.14.16.2.2 "OSPF" Normal FORMAT ZBXTRAP $aA OSPF neighbor with IP addr $2 changed state to $5 

Tatsächlich ist dies im Protokoll das Zauberwort "OSPF" und erscheint:

 2018 07 19 15:25:38 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart 

Das Datumsformat, das wir in der Konfiguration /etc/snmp/snmptt.ini definiert haben:

 date_time_format = %Y %m %d %H:%M:%S 

Was ich oben geschrieben habe - verwenden Sie jedes Format, das für Sie am besten geeignet ist. Hauptsache, es passt an den richtigen Stellen.

Erstellen Sie einen Trigger



Ein Nachbar kann mehrere Zustände haben :

 1 : down 2 : attempt 3 : init 4 : twoWay 5 : exchangeStart 6 : exchange 7 : loading 8 : full 

Es spielt überhaupt keine Rolle, in welchem ​​Zustand sich der Nachbar befindet, wenn dieser Zustand nicht VOLL ist, denn um dies zu diagnostizieren, müssen Sie immer noch zum Stück Eisen gehen, die Protokolle lesen und einige Befehle eingeben. Der Trigger ist also eins und wird nur dann angeregt, wenn in TRAP der Status des Nachbarn nicht VOLL ist.

Stellen Sie vor dem Aufhängen der Vorlage an einen bestimmten Host sicher, dass der Host mit der richtigen SNMP-Schnittstelle mit der richtigen IP-Adresse konfiguriert ist. Andernfalls befinden sich die Leitern im Protokoll /var/log/snmptt/snmptt.log, aber Zabbix bindet sie nicht an den Host. In diesem Fall wird im Zabbix-Protokoll des Servers /var/log/zabbix/zabbix_server.log die folgende Meldung angezeigt:

 19972:20180720:091722.896 unmatched trap received from "192.168.192.169": 2018 07 20 09:17:21 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - OSPF neighbor with IP addr 10.64.0.10 changed state to exchangeStart 

Gehen Sie zu Neueste Daten, siehe



Trigger hat auch funktioniert



Setzen Sie jetzt zwei Nachbarn



Im Dashboard sehen wir, dass zwei Probleme aufgetreten sind. Dies ist gut, und sogar zwei Buchstaben werden zu diesem Thema mit der konfigurierten Benachrichtigung eingehen.

Alles ist großartig, alles funktioniert und hier ist die Kirsche auf dem Kuchen am Ende.



UPD: Unsere Kollegen haben uns geraten, dies zu klären und zu versuchen, unsere Pläne mithilfe von SNMP-Kontexten umzusetzen. Es gibt Nachfrage, es wird Angebot geben. Mit Blick auf die Zukunft kann ich sagen - der Teufel ist nicht so schrecklich, lass uns gehen.
Auf ein Netzwerkstück Eisen zeichnen wir einen magischen Befehl:

snmp-server context {snmp context name} instance {protocol instance} vrf {vrf name}

Parameternamen müssen geklärt werden
{snmp context name} - Der Name des SNMP-Kontexts, der in Anforderungen verwendet wird.
{Protokollinstanz} und {vrf-Name} entnehmen wir der Konfiguration des konfigurierten OSPF-Prozesses:

router ospf {protocol instance}
..
vrf {vrf name}
..

Es bestand die Befürchtung, dass wir nach solchen Einstellungen das bereits konfigurierte Element über SNMP mit einem leeren Kontext beschädigen würden, aber ich habe überprüft, dass die Einstellung nur die Ausgabe von Daten über OSPF-MIB betrifft, während beispielsweise aus dem Abschnitt IF-MIB weiterhin alles wie zuvor mit einem leeren Kontext zurückgegeben wird. Wenn Sie kein Nexus haben, empfehle ich, diesen Punkt noch einmal zu überprüfen - es ist wahrscheinlich, dass das Verhalten anders sein wird.

Drehen Sie nun die Vorlage in Zabbix.
Sie müssen eine neue Erkennungsregel mit dem folgenden Kontext erstellen:



Neuer Artikel Prototyp auch mit Kontext



Und zwei Auslöser - der erste - für den Alarm, wenn sich der Nachbar in einem anderen Zustand als FULL befindet:



und die zweite - wenn der Nachbar fehlt: