Zabbix - surveillance des voisins OSPF à l'aide de pièges SNMPv3, douleur et désespoir

Mandat

Il existe un réseau de centres de données géographiquement dispersés avec une voiture VRF et une liste en constante évolution de voisins OSPF. Vous devez les suivre:

1. État, faire l'alarme si l'état voisin n'est pas PLEIN
2. Quantité, c'est-à-dire que si le voisin manque, vous devez également faire une alarme

Un système de surveillance existe déjà - Zabbix 3.4, il est souhaitable de l'utiliser, Linux OS Debian 9.x

Nous essayons en un clin d'œil

Le protocole est répandu, le système de surveillance est connu, je ne suis probablement pas le premier à vouloir résoudre ce problème, et il a probablement déjà été résolu.

Nous entrons dans la recherche de «zabbix ospf» et le premier lien mène au modèle . Le bonheur est quoi - maintenant je l'importe, le peigne selon mes besoins et tout sera OK.
Nous vérifions comment cela fonctionne - tout semble aller bien, les états sont surveillés, mais lorsque le voisin passe à l'état BAS, nous recevons un message «très» informatif de Zabbix

No Such Instance currently exists at this OID 

et info

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

Ce qui s'est passé - le problème est ancien et connu dans les forums - lorsque le voisin OSPF disparaît, alors tous les OID qui lui sont associés sont simplement supprimés sur le matériel réseau.

Oui, il existe une solution - créez un déclencheur nodata, ok créez:

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

On voit dans le tableau de bord:

 OSPF neighbor 192.168.192.168 missing data 

Fondamentalement ... utilisable

Mais prêt à l'emploi, le LLD ne détecte que les voisins du VRF par défaut. Bien sûr, cela peut être résolu en utilisant le contexte SNMP , mais d'une manière ou d'une autre, je ne voulais pas du tout - nous avons dû parcourir toutes les pièces de fer, injecter un contexte dans chaque processus OSPF ou VRF, puis faire des copies de Discovery pour chaque contexte dans notre modèle, en général c'est un peu beaucoup et en ajoutant de nouveaux processus OSPF, vous devez changer quelque chose à plusieurs endroits. Bien sûr, vous pouvez être entouré de scripts et tout cela peut être modifié via l'API Zabbix, mais je ne voulais pas de personnalisation spéciale, mais je voulais utiliser uniquement les fonctionnalités intégrées à Zabbix. Il y a une mention d'un certain CISCO-CONTEXT-MAPPING-MIB, à partir duquel vous pouvez extraire toute la correspondance entre les contextes et OSPF / VRF, mais je n'ai pas compris comment attacher cette conception au LLD. Si quelqu'un sait comment cuisiner Zabbix si cool, alors bienvenue dans les commentaires, et de préférence dans un article séparé à part entière.

Nous essayons de la deuxième attaque

Après quelques heures de recherche sur Internet des indices dans les forums et les bacs de mémoire, un sujet est apparu sur SNMP TRAP - c'est à ce moment-là que nous n'interrogons pas le morceau de fer, mais le morceau de fer envoie des informations sur le changement de quelque chose. Oui, et le support de campagne pour ce genre de choses est dans notre système de surveillance prêt à l' emploi , l'équipement peut également immédiatement et juste pour mon cas.

Dès les premières lignes, la documentation de suivi a été confondue par une longue liste:

 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.) 

Autrement dit, un démon accepte TRAP, le transmet à un autre démon, il l'analyse, le place dans le journal au format souhaité, et le zabix lit déjà le journal et décide quoi faire ensuite. D'une certaine manière, cela ne semble déjà jamais plus facile que de marcher avec les mains et de dessiner un contexte SNMP partout, mais bon, essayons. Nous lisons attentivement le document de surveillance et comprenons que ce n'est qu'avec son aide que rien ne peut être configuré, en général Zabbix a une telle blague - la documentation décrit les capacités et les nuances du système de manière si minimale qu'il est plus déroutant qu'enseigné. Bien qu'ils puissent être compris - le logiciel est gratuit, mais vous devez en quelque sorte gagner de l'argent, mais ils gagnent de l'argent sur le support. Il y a des articles sur Internet avec une description de la façon de configurer cela une ou deux fois , mais je n'ai pas réussi à configurer d'un article à l'autre, j'ai dû collecter des informations de différentes sources petit à petit. Ce sont toutes les paroles, ils ont conduit pour faire du hardcore.

Nous configurons un morceau de fer en réseau

Avant de tordre quelque chose sur l'hôte avec la surveillance, je vous recommande fortement de configurer d'abord le matériel réseau et de vous assurer que TRAP arrive vraiment du matériel au serveur - au début, je n'ai pas vérifié qu'il buvait beaucoup de nerfs, de sang et de temps. J'ai une voiture Cisco Nexus sous la main, je vais donc vous donner des exemples pour cette série. Quiconque a Catalyst, ASR, ASA et ainsi de suite - désolé, je ne suis pas le soleil, je ne chaufferai pas tout le monde, lisez les quais sur la façon de le configurer vous-même, la syntaxe sera similaire, mais avec ses propres nuances.

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

Il est important à l'avenir, lors de la configuration de TRAP dans Zabbix, que l'adresse à partir de laquelle TRAP est envoyée soit égale à l'adresse SNMP de l'interface dans les paramètres de l'hôte dans Zabbix.

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

Utilisez la version 3 du protocole autant que possible, en mode authPriv (cryptage et authentification), ce n'est pas aussi difficile à configurer qu'il n'y paraît. Oubliez la version 1 et la version 2 du protocole - lorsqu'une personne inattendue arrive en raison du manque de chiffrement et essentiellement d'authentification dans ces versions de protocole - ce n'est qu'une question de temps (la chaîne communautaire est transmise sous forme claire, d'ailleurs, je vois régulièrement qu'elle est configurée public / privé). Le paramètre opérateur de réseau vous permet d'accorder à l'utilisateur des autorisations en lecture seule.

 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 

J'ai spécifiquement désactivé tous les TRAP sauf OSPF, de sorte que lors du diagnostic de la raison pour laquelle quelque chose ne fonctionne pas, je n'ai pas eu à lire beaucoup d'informations inutiles du débogage.

Comment vérifier si TRAP fonctionne est très simple - vous devez casser quelque chose. Nous démarrons le renifleur sur l'hôte avec surveillance:

 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 

On retrouve sur un morceau de fer des voisins vivants:

 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 

Et laisse tomber quelqu'un

 interface vlan 1643 shutdown 

On voit dans le renifleur:

 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 

Si vous n'avez rien vu dans le renifleur, diagnostiquez-le, car sinon il n'y a aucune raison de continuer, vous ne comprendrez simplement pas à quel stade quelque chose ne fonctionne pas pour vous.
S'il n'y a aucun morceau de fer à portée de main ou si la production ne peut pas être touchée, alors TRAP peut être généré à partir de n'importe quelle autre voiture, par exemple, comme ceci:

 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 

Configurer SNMPd, SNMPTRAPd, SNMPTT

Nous aurons besoin de packages dans le système:

 apt install snmp snmp-mibs-downloader snmpd snmptrapd snmptt 

Je ne me suis pas concentré sur le récepteur de piège Perl, mais j'ai choisi SNMPTT pour des raisons personnelles et subjectives. Ainsi, le dock dit:

 1. snmptrapd receives a trap 

Il faut commencer par sa configuration, et ne pas grimper immédiatement pour créer Item dans la face Zabbix. Pourquoi? Vous devez gravir les mêmes marches que celles utilisées pour TRAP. Dans la section précédente, nous nous sommes assurés que TRAP arrive essentiellement à partir d'un morceau de fer, nous allons maintenant nous assurer qu'il est au moins accepté par le premier démon - snmptrapd. <lyric> Je me souviens d'avoir installé postfix + pigeonnier + quelque chose d'autre il y a longtemps. Et j'ai boudé pendant deux semaines - là aussi, un démon accepte la connexion, l'autre analyse la lettre, le troisième la met dans la file d'attente, le quatrième dans le dossier de l'utilisateur, et ainsi de suite, et je n'ai pas réussi. Et tout cela parce que je me suis connecté depuis le milieu, depuis la fin, depuis le début, mais j'ai dû commencer avec telnet sur le port 25 et afficher le débogueur du foxer </ lyric>

Nous montons dans /etc/snmp/snmptrapd.conf et le supprimons, mais plutôt nous commentons tout ce que nous ne comprenons pas et ne sommes pas intéressés, nous laissons une ligne

 disableAuthorization yes 

Arrêtez le service

 systemctl stop snmptrapd.service 

Exécuter en mode manuel

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

Encore une fois, essayez de casser OSPF comme dans l'exemple ci-dessus et voyez:

 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) 

Si nous ne voyons pas, alors nous cherchons la raison. Si vous voulez avoir les mêmes beaux enregistrements, et non un ensemble d'OID de la forme 1.3.6.1.2.1.14.10.1.6, ajoutez ce qui suit à /etc/snmp/snmp.conf:

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

Et déformer SNMPd

 systemctl restart snmpd.service 

Plus en détail comment télécharger les fichiers MIB avec le moins de douleur et les alimenter sur votre SNMPd peut être lu [ici] (https://wiki.debian.org/SNMP).

Maintenant, nous attachons l'authentification, nous montons à nouveau dans /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 est l'ID du moteur, il peut être affiché sur le matériel réseau:

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

Nous répétons à nouveau l'expérience, mais maintenant nous continuons à attraper un débogage sur USM:

 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) 

Si à ce stade vous voyez des erreurs d'autorisation dans le débogage, vérifiez soigneusement l'ID moteur et que les utilisateurs créés sur le matériel correspondent à ceux que nous avons dessinés dans la configuration /etc/snmp/snmptrapd.conf. Soit dit en passant, oui, pour chaque morceau de fer, vous devrez créer votre propre utilisateur avec son ID moteur, ou le faire de la même manière sur tous les morceaux de fer avec les mains, si les morceaux de fer le permettent.

Je peux voir la ligne dans le débogage:

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

Pourquoi n'ai-je pas compris, bien qu'avec tout cela, TRAP soit accepté et obtienne un traitement ultérieur. Si vous savez ce que j'ai fait de mal, veuillez commenter.

Maintenant, nous prenons SNMPTT - il a deux config ini et conf. Dans le premier, nous déterminons les paramètres du démon lui-même, dans le second, nous déterminons les paramètres de réception et de traitement de chaque échelle spécifique.

Nous montons dans le fichier /etc/snmp/snmptt.ini et dessinons les choses suivantes:

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

Le format de la date et de l'heure est une question commerciale, surtout utilisez-le partout.

 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 

Pourquoi le journal n'est-il pas le même que dans de nombreux articles sur Internet? Parce que le dock a dit: "Si le paramètre systemd PrivateTmp est utilisé, ce fichier ne fonctionnera probablement pas dans / tmp.", Je ne veux pas entrer de nouveau dans le râteau s'il est averti à l'avance, donc je vais immédiatement changer pour le chemin normal du fichier.

Ensuite, allez dans /etc/snmp/snmptt.conf, supprimez tout ce dont nous n'avons pas besoin et / ou ne comprenons pas, nous ne laissons que ceci:

 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 

Sous cette forme, car Zabbix attendra exactement un tel format dans le journal. D'où viennent 2 $ et 5 $, vous pouvez savoir si vous regardez le format de message TRAP , regardez:

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

Ces composants d'interruption sont les paramètres qui peuvent être insérés dans le format de journal dans l'ordre de $ 1, $ 2 ...

Pendant l'épreuve de force avec toutes ces choses, j'ai remarqué qu'après avoir changé les paramètres SNMPTT, c'est comme si les changements n'étaient pas appliqués. Il s'est avéré qu'après leur changement, il était nécessaire de redémarrer non pas snmptt.serivce, mais snmpd.service - cette nuance a décemment bu mon sang et bu mes nerfs pendant le débogage.

Vérifiez que tous les démons sont en cours d'exécution:

 systemctl status snmpd snmptrapd snmptt 

Si tout va bien, essayez à nouveau de casser OSPF et accédez au journal /var/log/snmptt/snmptt.log, il ressemblera à ceci:

 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 

Les TRAP que nous n'avons pas configurés dans la configuration /etc/snmp/snmptt.conf iront dans le journal /var/log/snmptt/snmpttunknown.log, mais uniquement à partir du matériel pour lequel l'utilisateur et l'ID moteur correct sont configurés dans la même configuration. C'est, à partir de glandes gauche TRAP sera silencieusement éliminés, si vous voulez Mata et débriefing, vous ici - Station d' accueil extrêmement IMPUTÉE pour net-snmp, il y a encore une bonne idée de décrire les différences entre les TRAP et INFORM, l' avenir, il est préférable d'utiliser INFORMER, t. k. il y a une sorte de contrôle de livraison là-bas, mais cela fonctionne via UDP sur UDP.

Et seulement maintenant, nous montons pour configurer notre moniteur.

Configuration de Zabbix

Tout d'abord, assurez-vous que dans la configuration /etc/zabbix/zabbix_server.conf, la surveillance est définie sur le bon journal SNMPTT et que Zabbix lui-même démarre au moins un trappeur SNMP:

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

Pour commencer, j'ai créé Item directement sur l'hôte, afin qu'il soit plus rapide et plus facile d'attraper des effets spéciaux, ici j'écrirai tout de suite comment créer un modèle, car ce sont les modèles qui doivent être utilisés chaque fois que possible. Je vais vous montrer les photos, le cadeau de copier-coller est terminé, mais je vais peindre les endroits auxquels vous devez faire attention.

Créez un modèle:



Ici, nous donnons juste un nom sain

Créer un élément



Important - la clé devrait être comme ça, ce qui est indiqué entre crochets est ce que Zabbix recherchera dans le journal, nous avons configuré le format du journal dans /etc/snmp/snmptt.conf et y avons écrit:

 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 

En fait dans le journal, c'est le mot magique "OSPF" et apparaît:

 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 

Le format de date que nous avons défini dans la configuration /etc/snmp/snmptt.ini:

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

Ce que j'ai écrit ci-dessus - utilisez n'importe quel format qui vous convient, l'essentiel est qu'il corresponde aux bons endroits.

Créer un déclencheur



Un voisin peut avoir plusieurs états :

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

Peu importe le type d'état dans lequel se trouve le voisin, si cet état n'est pas PLEIN, car pour diagnostiquer cela, vous devez toujours aller sur le morceau de fer, lire les journaux, entrer certaines commandes. Le déclencheur sera donc un et ne sera excité que lorsque dans TRAP l'état du voisin n'est pas PLEIN.

Avant de suspendre le modèle sur un hôte spécifique, assurez-vous que l'hôte est configuré avec la bonne interface SNMP avec la bonne adresse IP, sinon les échelles seront dans le journal /var/log/snmptt/snmptt.log, mais Zabbix ne les liera pas à l'hôte. Dans ce cas, dans le journal Zabbix du serveur /var/log/zabbix/zabbix_server.log, il y aura un message de la forme:

 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 

Allez à Dernières données, voir



Trigger a également fonctionné



Maintenant, mettez deux voisins



Dans le tableau de bord, nous voyons que deux problèmes se sont produits, c'est bien, et même deux lettres arriveront sur ce sujet avec la notification configurée.

Tout est super, tout fonctionne, et voici la cerise sur le gâteau à la fin.



UPD: nos collègues nous ont conseillé de faire le tri et d'essayer de mettre en œuvre nos plans en utilisant des contextes SNMP . Il y a une demande, il y aura une offre. Pour l'avenir, je peux dire - le diable n'est pas si terrible, allons-y.
Sur un morceau de fer en réseau, nous dessinons une commande magique:

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

Les noms des paramètres doivent être clarifiés
{nom du contexte snmp} - le nom du contexte SNMP qui sera utilisé dans les requêtes.
{instance de protocole} et {nom vrf} nous prenons de la configuration du processus OSPF configuré:

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

On craignait qu'après de tels paramètres, nous cassions l'élément déjà configuré via SNMP avec un contexte vide, mais j'ai vérifié que le paramètre affecte uniquement la sortie des données via OSPF-MIB, tandis que, par exemple, à partir de la section IF-MIB, tout continue d'être renvoyé comme auparavant avec un contexte vide. Si vous n'avez pas Nexus, je vous recommande de vérifier à nouveau ce point - il est probable que le comportement sera différent.

Maintenant, tordez le modèle dans Zabbix.
Vous devez créer une nouvelle règle de découverte avec le contexte:



Nouveau prototype d'article également avec contexte



Et deux déclencheurs - le premier - pour l'alarme si le voisin est dans n'importe quel état sauf FULL:



et le second - si le voisin manque: