Como solucionar problemas em que o destino SNMP não recebe alertas SNMP enviados do Unisphere.

Abaixo estão os quatro locais para verificar se um destino SNMP não recebe alertas SNMP enviados do Unisphere.
 

• A palavra de comunidade do destino SNMP do cliente deve corresponder à palavra de comunidade padrão (SNMP_trap) do Unisphere.  
• O cliente deve garantir uma boa conectividade de rede entre o servidor Unisphere e o destino do SNMP. Podemos usar comandos openssl e tracepath no unisphere server para verificar a conectividade e usar o comando tcpdump no unisphere server para capturar o pacote SNMP durante os testes de alerta. Uma maneira simples de provar que o Unisphere pode enviar alertas SNMP com sucesso é ter um destino SNMP conectado diretamente ao servidor unisphere. Se o destino do SNMP diretamente conectado puder receber alertas SNMP enquanto o conectado indiretamente não puder, isso significa que o problema está na rede do cliente.  
• As configurações de alerta do Unisphere SNMP devem ser todas definidas corretamente, o que inclui:    
• Configuração de notificação SNMP, configuração de política de alerta, nível de notificação.

 
Se os itens acima não tiverem problemas, o suporte deverá prosseguir com o teste de alertas com o registro de depuração do SE storevntd ativado, o conjunto de registro smas INFO e o tcpdump capturado. Colete emcgrab e teste os resultados se não for possível ver evidências de que os alertas SNMP foram enviados com sucesso.
Observe que é melhor gerar alertas reais além de usar a função "TEST SNMP" durante o teste, pois, em comparação com alertas reais, o pacote "TEST SNMP" é pequeno e mais não confiável para transmitir para o pacote UDP.

 

Etapas detalhadas para a solução de problemas: 

1. Palavra da comunidade SNMP.

A palavra de comunidade padrão é "SNMP_trap". Se ele não corresponder à palavra de comunidade do destino do SNMP, podemos alterá-la adicionando a seguinte linha no arquivo daemon_options SE:
 

storevntd: snmp_trap_community=        
(example: storevntd: snmp_trap_community=public)

Salve o arquivo e reinicie o daemon storevntd para permitir que a alteração entre em vigor. (Não use o comando reload, pois ele não é confiável)

stordaemon shutdown storevntd
stordaemon start storevntd

Depois que storenvtd é reiniciado, as políticas de alerta carregadas anteriormente na página de configuração de alerta do Unisphere também são perdidas. Para permitir que as políticas de alertas seja recarregadas e registradas em storevntd, também devemos reiniciar o serviço SMAS .
(O comando abaixo é para reiniciar o serviço SMAS no servidor Linux. Você pode seguir eventos SNMP que não estão sendo enviados para o servidor U4V incorporado ou SNMP para reiniciar o serviço SMAS para o Unisphere incorporado).

No Unisphere Server, cd para o caminho /etc/init.d e, em seguida, execute os seguintes comandos:

./smas stop
./smas start

Em seguida, podemos usar o comando abaixo para verificar o status do registro de eventos storevntd . (Leva algum tempo para os eventos registrados no storevntd após a reinicialização de smas)

stordaemon action storevntd -cmd list -regs –v

 

2. Conectividade de rede.

Podemos usar o comando openssl e tracepath no unisphere server para verificar se o Unisphere pode se comunicar bem com o destino do SNMP.
 

openssl s_client  -connect :

tracepath : 
(in some version of tracepath, the format is “tracepath /” )

Examples:

openssl s_client  -connect xx.xxx.0.xx:162
Connected

tracepath xx.xxx.0.xx -p 162

1?: [LOCALHOST]                                        pmtu 1500
1:  xxx.1x.xxx.xx0                                        0.854ms
1:  xxx.x8.xxx.xx0                                        0.540ms
2:  xx.xx1.xx.x                                             18.572ms
3:  xx.xxx.0.xx                                             0.988ms reached

 

3. Configurações de alerta do Unisphere SNMP:

 

1. Configuração de notificação de alerta SNMP.  

Settings - Alerts - Notifications, clique na palavra "Configure" no block SNMP e certifique-se de que o IP e a porta corretos de destino do SNMP estejam configurados.

(Nota: Teste com um único destino SNMP para evitar a complexidade do teste.)



Para verificar se essas configurações foram carregadas com sucesso no daemon storevntd, podemos usar o seguinte comando para verificar:

stordaemon getvar storevntd -name smas_log_event_targets

storevntd                     smas_log_event_targets=snmp

stordaemon getvar storevntd -name snmp_host

storevntd                     snmp_host=O:xx.xx.xxx.xx:162:v1

stordaemon action storevntd -cmd list -log_targets

(para alerta syslog , os dois primeiros comandos correspondentes são:

stordaemon getvar storevntd -name log_event_syslog_host
stordaemon getvar storevntd -name log_event_syslog_port

 

2. Configuração da política de alerta

Mais tarde, vamos gerar um alerta real de alteração de configuração de dispositivo para o teste de alerta. Aqui, usamos a política "device config change" como exemplo. Certifique-se de que "Alteração de configuração do dispositivo" esteja marcada para o array usado para o teste de alerta e se o tipo de notificação é especificado com SNMP.



 

3. Nível de notificação

Ao criar um novo dispositivo para o teste de alerta, o alerta gerado é "Device configuration has changed". O alerta está no nível das informações, portanto, devemos garantir que o ícone azul esteja selecionado para um teste de alerta pelo menos.


 

4. Habilite o log de depuração storevntd e o registro INFO do Unisphere

 Altere os seguintes parâmetros no arquivo de daemon_options SE:

storevntd:LOG_LEVEL = debug
storevntd:LOGFILE_TYPE = dated
storevntd:LOGFILE_RETENTION = 7

Salve o arquivo, de acordo com a etapa 1; devemos reiniciar o daemon storevntd e, em seguida, reiniciar o serviço smas .
Depois que o serviço smas for reiniciado, altere o nível de registro do Unisphere para INFO. (Nota: Reiniciar o serviço smas altera o nível de registro de volta para o padrão, que é WARN. )
 

5. Teste de alerta

Gere um alerta real, use tcpdump para capturar o pacote SNMP e marque storevntd debug log. 

1. Execute o comando tcpdump no unisphere server para se preparar para a captura de pacotes SNMP:

tcpdump -i any udp port 162 

2. Execute o seguinte comando para verificar o contador de eventos SNMP existente:

stordaemon action storevntd -cmd list -log_stats

storevntd                     Event Loggers
file             : 0 events delivered
system           : 0 events delivered
syslog           : 17 events delivered
snmp             : 4 events delivered

3. Crie uma LUN de 100 milhões no Unisphere. Verifique o painel de alertas do Unisphere e você verá que o alerta "Device configuration has changed" foi gerado. Se você não conseguir ver o pop-out do alerta, clique no botão Atualizar na barra superior da página do Unisphere.

 (Se você também ativou a política de "status do dispositivo", também poderá ver o alerta "Device state has changed to Online" (Estado do dispositivo alterado para On-line) é gerado).


 

4. Verifique o resultado do tcpdump.

O seguinte mostra que o alerta SNMP foi capturado com sucesso:
 

tcpdump -i any udp port 162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
11:05:59.246606 IP MGMT-0.emc-gateway > xx.xxx.xx.xxx.snmptrap:  C="SNMP_trap" Trap(448)  E:1139.3 xx.xxx.xx.xxx enterpriseSpecific s=4 0 X:xx.1.xx.1.8.xx.6.4.xxx.xxx.8x.xxx.6x.0.0.0.0.0.0.0.0.7=7 X:xx.1.11.1.7.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0.7=2 X:xx.1.xx.1.8.xx.6.4.xxx.xxx.8x.xxx.6x.0.0.0.0.0.0.0.0.7=.0.0 X:xx.1.11.1.9.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0.7="Symmetrix 000xxxx0xxxx : Device configuration has changed. - Object is: 000xxxx0xxxx:00867" X:xx.1.xx.1.6.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0.7=8 X:xx.1.6.1.20.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0="000xxxx0xxxx" X:xx.1.6.1.3.xx.6.4.xxx.xxx.xx.xxx.xx.0.0.0.0.0.0.0.0=11 E:1139.3.8888.1.0=2 E:1139.3.8888.2.0=5000 E:1139.3.8888.3.0=0 E:1139.3.8888.4.0="" 

5. Verifique o contador de eventos novamente. Podemos ver mais um evento snmp entregue.

stordaemon action storevntd -cmd list -log_stats

storevntd                     Event Loggers
file             : 0 events delivered
system           : 0 events delivered
syslog           : 17 events delivered
snmp             : 5 events delivered

6. Verifique o registro de depuração storenvtd :

Se você conseguir encontrar as seguintes entradas no registro, ele mostrará que storevntd forneceu com sucesso o alerta SNMP:

 [4964             EvtLogger] Feb-15 11:05:59.246 : [sendTrapForEach()] Trap sent to xx.xxx.xx.xxx, port 162

 [4964             EvtLogger] Feb-15 11:05:59.246 : [processOneSymmEvent()] Symmetrix 000xxxxxxx1 : Device configuration has changed. - Object is: 000xxxxxxxx1:00024
 [4964             EvtLogger] Feb-15 11:05:59.246 : [processAsyncEvent()] Function Exit, rc= 470
 [4964             EvtLogger] Feb-15 11:05:59.246 : [evtd_logLoggerThrd] Event Delivery complete

A evidência acima mostra que o alerta SNMP foi enviado com sucesso do lado do Unisphere. Se não capturarmos o pacote SNMP usando tcpdump e storevntd , também não teremos evidências para a entrega bem-sucedida do evento, colete o emcgrab e entre em contato com o suporte técnico.