Zabbix - monitorando vizinhos OSPF usando armadilhas SNMPv3, dor e desespero

Termos de Referência

Existe uma rede de data centers geograficamente dispersos com um carro VRF e uma lista em constante mudança de vizinhos OSPF. Você precisa rastreá-los:

1. Estado, alarme se o estado vizinho não estiver CHEIO
2. Quantidade, isto é, se o vizinho estiver ausente, você também deve fazer um alarme

Já existe um sistema de monitoramento - Zabbix 3.4, é desejável usá-lo, Linux OS Debian 9.x

Tentamos com um piscar de olhos

O protocolo é amplo, o sistema de monitoramento é conhecido, provavelmente não sou o primeiro a resolver esse problema e, provavelmente, ele já foi resolvido.

Entramos na pesquisa por “zabbix ospf” e o primeiro link leva ao modelo . Felicidade é o que - agora estou importando, combinando com as minhas necessidades e tudo ficará bem nas docas.
Verificamos como funciona - tudo parece estar bem, os estados são monitorados, mas quando o vizinho entra no estado DOWN, recebemos uma mensagem informativa “muito” do Zabbix

No Such Instance currently exists at this OID 

e informação

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

O que aconteceu - o problema é antigo e conhecido nos fóruns - quando o vizinho OSPF desaparece, todos os OIDs associados a ele são simplesmente excluídos no hardware da rede.

Sim, existe uma solução - crie um gatilho nodata, ok crie:

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

Vemos no painel:

 OSPF neighbor 192.168.192.168 missing data 

Basicamente ... utilizável

Mas pronto para uso, o LLD detecta apenas vizinhos do VRF padrão. Obviamente, isso pode ser resolvido usando o contexto SNMP , mas de alguma forma eu não queria seguir esse caminho - precisamos passar por todas as glândulas, injetar um processo OSPF ou VRF no contexto e, em seguida, fazer cópias do Discovery para cada contexto do modelo, em geral é um pouco demais confusão e ao adicionar novos processos OSPF, você precisa alterar algo em vários lugares. É claro que você pode estar rodeado de scripts e, através da API do Zabbix, tudo isso pode ser alterado, mas eu não queria um costume especial, mas queria usar apenas a funcionalidade incorporada ao Zabbix ao máximo. Há uma menção a um certo CISCO-CONTEXT-MAPPING-MIB, do qual você pode obter toda a correspondência entre contextos e OSPF / VRF, mas não descobri como fixar esse design no LLD. Se alguém souber cozinhar o Zabbix de maneira tão legal, bem-vindo aos comentários e, de preferência, a um artigo separado completo.

Tentamos a partir do segundo ataque

Depois de algumas horas pesquisando na Internet por dicas em fóruns e caixas de memória, surgiu um tópico sobre o SNMP TRAP - é quando não interrogamos o pedaço de ferro, mas o pedaço de ferro envia informações sobre a alteração de algo. Sim, e o suporte da campanha para esse material está em nosso sistema de monitoramento pronto para uso, o equipamento também pode ser imediato e apenas para o meu caso.

Desde as primeiras linhas, a documentação de monitoramento foi confundida por uma longa lista:

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

Ou seja, um daemon aceita TRAP, o passa para outro daemon, o analisa, o coloca no log com o formato desejado e o zabix já lê o log e decide o que fazer em seguida. De alguma forma, já parece nunca mais fácil do que andar com as mãos e desenhar um contexto SNMP em qualquer lugar, mas tudo bem, vamos tentar. Lemos com atenção o documento de monitoramento e entendemos que somente com a ajuda dele nada pode ser configurado, em geral o Zabbix tem uma piada - a documentação descreve os recursos e as nuances do sistema tão minimamente que é mais confuso do que ensinado. Embora eles possam ser entendidos - o software é gratuito, mas de alguma forma você precisa ganhar dinheiro, mas eles ganham dinheiro com suporte. Existem artigos na Internet com uma descrição de como configurar isso uma ou duas vezes , mas não consegui configurar de um artigo para o outro, tive que coletar informações de várias fontes pouco a pouco. Esta é toda a letra, eles dirigiram para fazer hardcore.

Configuramos um pedaço de ferro da rede

Antes de girar algo no host com o monitoramento, recomendo que você primeiro configure o hardware da rede e verifique se o TRAP realmente chega do hardware para o servidor - no início, não verifiquei se ele consumia muitos nervos, sangue e tempo. Eu tenho um carro Cisco Nexus disponível, então darei exemplos para esta série. Quem tem Catalyst, ASR, ASA e assim por diante - desculpe, não sou o sol, não esquento todos, leia as docas sobre como configurar isso sozinho, a sintaxe será semelhante, mas com suas próprias nuances.

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

É importante no futuro, ao configurar o TRAP no Zabbix, que o endereço do qual o TRAP é enviado seja igual ao endereço SNMP da interface nas configurações do host no Zabbix.

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

Use a versão 3 do protocolo sempre que possível, no modo authPriv (criptografia e autenticação), não é tão difícil de configurar quanto parece. Esqueça as versões 1 e 2 do protocolo - quando uma pessoa inesperada chega devido à falta de criptografia e autenticação nessas versões do protocolo - é apenas uma questão de tempo (a cadeia da comunidade é transmitida nelas de forma clara, além disso, vejo regularmente que ela está configurada como pública / privada). O parâmetro operador de rede permite que você conceda ao usuário permissões somente leitura.

 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 

Desativei especificamente todo o TRAP, exceto o OSPF, para que, ao diagnosticar por que algo não está funcionando, não precisei ler muitas informações desnecessárias da depuração.

Como verificar se o TRAP funciona é muito simples - você precisa quebrar alguma coisa. Iniciamos o sniffer no host com o monitoramento:

 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 

Encontramos em um pedaço de ferro vizinhos vizinhos:

 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 

E largar alguém

 interface vlan 1643 shutdown 

Vemos no sniffer:

 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 

Se você não viu nada no farejador, diagnostique-o, porque, caso contrário, não há motivo para continuar, simplesmente não entenderá em que estágio algo não funciona para você.
Se não houver ferro na mão ou a produção não puder ser tocada, o TRAP poderá ser gerado a partir de qualquer outro carro, por exemplo, como este:

 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 

Configurar SNMPd, SNMPTRAPd, SNMPTT

Vamos precisar de pacotes no sistema:

 apt install snmp snmp-mibs-downloader snmpd snmptrapd snmptt 

Não foquei no receptor de armadilha Perl, mas escolhi o SNMPTT por razões pessoais e subjetivas. Então, a doca diz:

 1. snmptrapd receives a trap 

É necessário começar com sua configuração e não subir imediatamente para criar Item na face do Zabbix. Por que isso - você precisa subir os mesmos passos que o TRAP. Na seção anterior, asseguramos que o TRAP chegue basicamente a partir de um pedaço de ferro, agora garantiremos que ele seja pelo menos aceito pelo primeiro daemon - snmptrapd. <lyric> Lembro-me de configurar o postfix + dovecot + outra coisa lá há muito tempo. E fiquei emburrado por cerca de duas semanas - lá também um demônio aceita a conexão, o outro analisa a carta, o terceiro a coloca na fila, o quarto na pasta do usuário e assim por diante, e eu não obtive sucesso. E tudo porque eu me sintonizei do meio, do fim, do começo, mas tive que começar com o telnet até a porta 25 e ver o depurador do foxer </ lyric>

Entramos no /etc/snmp/snmptrapd.conf e o excluímos, mas comentamos tudo o que não entendemos e não estamos interessados, deixamos uma linha

 disableAuthorization yes 

Interrompa o serviço

 systemctl stop snmptrapd.service 

Executar no modo manual

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

Mais uma vez, tente quebrar o OSPF como no exemplo acima e veja:

 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) 

Se não vemos, então estamos procurando o motivo. Se você deseja ter os mesmos registros bonitos e não um conjunto de OIDs do formulário 1.3.6.1.2.1.14.10.1.6, adicione o seguinte ao /etc/snmp/snmp.conf:

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

E distorcer o SNMPd

 systemctl restart snmpd.service 

Mais detalhadamente, como baixar arquivos MIB com o mínimo de esforço e alimentá-los com o SNMPd pode ser lido aqui (https://wiki.debian.org/SNMP).

Agora, apertamos a autenticação, subimos novamente no /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 é o engineID, pode ser visualizado no hardware de rede:

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

Estamos repetindo a experiência novamente, mas agora ainda estamos capturando uma depuração sobre o 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) 

Se, nesse estágio, você encontrar erros de autorização na depuração, verifique cuidadosamente o engineID e se os usuários criados no hardware correspondem aos que desenhamos na configuração do /etc/snmp/snmptrapd.conf. A propósito, sim, para cada pedaço de ferro, você terá que criar seu próprio usuário com seu engineID ou torná-lo igual em todos os pedaços de ferro com as mãos, se os pedaços de ferro permitirem que isso seja feito.

Eu posso ver a linha no debug:

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

Por que eu não entendi, embora com tudo isso a TRAP seja aceita e receba processamento adicional. Se você sabe o que fiz de errado, comente.

Agora adotamos o SNMPTT - ele tem duas configurações ini e conf. No primeiro, determinamos os parâmetros do próprio daemon, no segundo, determinamos os parâmetros para receber e processar cada escada específica.

Subimos para o arquivo /etc/snmp/snmptt.ini e desenhamos o seguinte:

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

O formato da data e hora é uma questão de negócios; o mais importante é usar o mesmo em qualquer lugar.

 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 

Por que o log não é o mesmo de muitos artigos na Internet? Como o dock disse: "Se o parâmetro systemd PrivateTmp for usado, é improvável que este arquivo funcione em / tmp.", Não quero entrar no rake novamente, se avisado com antecedência, então mudarei imediatamente para o caminho normal do arquivo.

Em seguida, vá para /etc/snmp/snmptt.conf, remova tudo o que não precisamos e / ou não entendemos, deixamos apenas isso:

 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 

Nesta forma, porque o Zabbix espera exatamente esse formato no log. De onde vêm $ 2 e $ 5, você pode descobrir se você vê o formato da mensagem TRAP , veja:

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

Esses componentes de interceptação são os parâmetros que podem ser empurrados para o formato de log na ordem de $ 1, $ 2 ...

Durante o confronto com tudo isso, notei que, depois de alterar as configurações do SNMPTT, é como se as alterações não fossem aplicadas. Aconteceu que, após a alteração, foi necessário reiniciar não o snmptt.serivce, mas o snmpd.service - essa nuance decentemente bebeu meu sangue e nervos durante a depuração.

Verifique se você tem todos os daemons em execução:

 systemctl status snmpd snmptrapd snmptt 

Se estiver tudo bem, tente novamente quebrar o OSPF e vá para o log /var/log/snmptt/snmptt.log, será semelhante a:

 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 

Os TRAPs que não configuramos na configuração do /etc/snmp/snmptt.conf irão para o arquivo /var/log/snmptt/snmpttunknown.log, mas apenas do hardware para o qual o usuário e o engineID corretos estão configurados na mesma configuração. Ou seja, das glândulas esquerdas, as TRAPs serão descartadas silenciosamente; se você quiser matan e debriefing, aqui você tem uma doca invulgarmente sã no net-snmp; a diferença entre TRAP e INFORM ainda é bem descrita lá, olhando para o futuro, é melhor usar INFORM etc. k. existe algum tipo de controle de entrega lá, mas funciona via UDP sobre UDP.

E só agora subimos para configurar nosso monitor.

Configuração do Zabbix

Primeiro, verifique se, na configuração do /etc/zabbix/zabbix_server.conf, o monitoramento está definido no log SNMPTT correto e o próprio Zabbix inicia pelo menos um SNMP Trapper:

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

Para iniciantes, criei o Item diretamente no host, para que seja mais rápido e fácil capturar efeitos especiais. Aqui, escreverei imediatamente como criar um Modelo, porque são os modelos que devem ser usados ​​sempre que possível. Vou mostrar as fotos, o brinde de copiar e colar acabou, mas vou pintar os lugares em que você precisa prestar atenção.

Crie um modelo:



Aqui apenas damos um nome são

Criar Item



Importante - a chave deve ser assim, o que é indicado entre colchetes é o que o Zabbix procurará no log, configuramos o formato do log em /etc/snmp/snmptt.conf e escrevemos lá:

 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 

Na verdade, no log, esta é a palavra mágica "OSPF" e aparece:

 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 

O formato da data que definimos na configuração /etc/snmp/snmptt.ini:

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

O que eu escrevi acima - use qualquer formato que seja conveniente para você, o principal é que ele corresponda nos lugares certos.

Criar um gatilho



Um vizinho pode ter vários estados :

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

Não importa em que tipo de estado o vizinho se encontra, se esse estado não estiver CHEIO, porque para diagnosticar isso, você ainda precisa ir ao pedaço de ferro, ler os logs e inserir alguns comandos. Portanto, o gatilho será um e será excitado apenas quando em TRAP o estado do vizinho não estiver CHEIO.

Antes de pendurar o modelo em um host específico, verifique se o host está configurado com a interface SNMP correta com o endereço IP correto; caso contrário, os ladders estarão no log /var/log/snmptt/snmptt.log, mas o Zabbix não os vinculará ao host. Nesse caso, no log do Zabbix do servidor /var/log/zabbix/zabbix_server.log, haverá uma mensagem no formato:

 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 

Vá para Dados mais recentes, consulte



Trigger também trabalhou



Agora coloque dois vizinhos



No painel, vemos que dois problemas ocorreram, isso é bom e até duas cartas chegarão sobre esse tópico com a notificação configurada.

Tudo está ótimo, tudo funciona, e aqui está a cereja no bolo no final.



UPD: nossos colegas nos aconselharam a resolver o problema e tentar implementar nossos planos usando contextos SNMP . Há demanda, haverá oferta. Olhando para o futuro, posso dizer - o diabo não é tão terrível, vamos lá.
Em um pedaço de ferro da rede, desenhamos um comando mágico:

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

Os nomes dos parâmetros precisam de esclarecimentos
{nome do contexto snmp} - o nome do contexto SNMP que será usado nas solicitações.
{protocol instance} e {vrf name} extraímos da configuração do processo OSPF configurado:

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

Havia um medo de que, após essas configurações, quebrássemos o Item já configurado via SNMP com um contexto vazio, mas verifiquei que a configuração afeta apenas a saída de dados via OSPF-MIB, enquanto, por exemplo, na seção IF-MIB, tudo continua sendo retornado como antes com um contexto vazio. Se você não possui o Nexus, recomendo verificar esse ponto mais uma vez - é provável que o comportamento seja diferente.

Agora torça o modelo no Zabbix.
Você deve criar uma nova regra de descoberta com o contexto:



Novo protótipo de item também com contexto



E dois gatilhos - o primeiro - para o alarme se o vizinho estiver em qualquer estado, exceto CHEIO:



e o segundo - se o vizinho estiver ausente: