如何对未接收从 Unisphere 发送的 SNMP 警报的 SNMP 目标进行故障排除。

下面是检查 SNMP 目标是否无法接收从 Unisphere 发送的 SNMP 警报的四个位置。
 

• 客户 SNMP 目标的社区单词应与 Unisphere 的默认社区单词 （SNMP_trap）匹配。  
• 客户必须确保 Unisphere 服务器与 SNMP 目标之间良好的网络连接。我们可以在 Unisphere 服务器上使用 openssl 和 tracepath 命令来验证连接性，并在警报测试期间使用 Unisphere 服务器上的 tcpdump 命令捕获 SNMP 软件包。证明 Unisphere 可以成功发送 SNMP 警报的一种简单方法是将 SNMP 目标直接连接到 Unisphere 服务器。如果直接连接的 SNMP 目标可以接收 SNMP 警报，而非直接连接无法接收，则表示问题出在客户的网络上。  
• Unisphere SNMP 警报设置应全部正确设置，其中包括：    
• SNMP 通知配置、警报策略设置、通知级别。

 
如果以上没有问题，支持人员必须继续进行警报测试，启用 SE storevntd 调试日志、 Smas INFO 日志记录集和 捕获的 tcpdump 。如果无法看到 SNMP 警报已成功发送的证据，则收集 emcgrab 并测试结果。
请注意，除了在测试期间使用“TEST SNMP”功能之外，最好生成真实警报，因为与真实警报相比，“TEST SNMP”软件包较小，并且更不可靠地传输 UDP 软件包。

 

故障排除的详细步骤： 

1. SNMP 社区单词。

默认社区单词为“SNMP_trap”。如果它与 SNMP 目标的社区单词不匹配，我们可以通过在 SE daemon_options文件中添加以下行来更改它：
 

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

保存文件，然后重新启动 storevntd 守护程序以使更改生效。（请勿使用 reload 命令，因为它不可靠）

stordaemon shutdown storevntd
stordaemon start storevntd

重新启动 storenvtd 后，以前从 Unisphere 警报配置页面加载的警报策略也会丢失。为了让警报策略在 storevntd 中重新加载和注册，我们还必须重新启动 smas 服务。
（以下命令用于在 Linux 服务器中重新启动 smas 服务。您可以按照 SNMP 事件未发送到嵌入式 U4V 或 SNMP 服务器 来重新启动嵌入式 Unisphere 的 smas 服务。

在 Unisphere 服务器上， cd 转到路径 /etc/init.d ，然后运行以下命令：

./smas stop
./smas start

然后，我们可以使用下面的命令检查 storevntd 事件注册状态。（在 smas 重新启动后注册到 storevntd 的事件需要一些时间）

stordaemon action storevntd -cmd list -regs –v

 

2. 网络连接。

我们可以在 Unisphere 服务器上使用 openssl 和 tracepath 命令来检查 Unisphere 是否可以很好地与 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. Unisphere SNMP 警报设置：

 

1. SNMP 警报通知配置。  

设置 - 警报 - 通知，单击 SNMP 数据块上的“Configure”字，并确保配置正确的 SNMP 目标 IP 和端口。

（注意：使用单个 SNMP 目标进行测试，以避免测试复杂性。）



要验证这些配置是否已成功加载到 storevntd 守护程序中，我们可以使用以下命令进行检查：

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

（对于 系统日志 警报，前两个对应的命令是：

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

 

2. 警报策略设置

稍后，我们将为警报测试生成真实的设备配置更改警报，在这里，我们使用“设备配置更改”策略作为示例。确保检查用于警报测试的阵列的“Device Config Change”，并使用 SNMP 指定通知类型。



 

3. 通知级别

通过为警报测试创建新设备，我们生成的警报是“Device configuration has changed”。警报位于信息级别，因此我们必须确保至少为警报测试选择了蓝色图标。


 

4. 启用 storevntd 调试日志和 Unisphere INFO 日志

 在 SE daemon_options 文件中更改以下参数：

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

按照步骤 1 保存文件;我们必须重新启动 storevntd 守护程序，然后重新启动 smas 服务。
重新启动 smas 服务后，将 Unisphere 的日志记录级别更改为 INFO。（提醒：重新启动 smas 服务会将日志记录级别更改回默认值，即 WARN。）
 

5. 警报测试

生成真实警报，使用 tcpdump 捕获 SNMP 软件包并检查 storevntd 调试日志。 

1. 在 Unisphere 服务器上运行 tcpdump 命令，为 SNMP 软件包捕获做好准备：

tcpdump -i any udp port 162 

2. 运行以下命令以检查现有的 SNMP 事件计数器：

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. 在 Unisphere 中创建一个 1 亿 LUN。检查 Unisphere 警报面板，您会看到生成“Device configuration has changed”警报。如果您看不到警报弹出窗口，请单击 Unisphere 页面顶部栏上的刷新按钮。

 （如果还启用了“设备状态”策略，您还可以看到生成“设备状态已更改为联机”警报）。


 

4. 检查 tcpdump 的输出。

以下显示已成功捕获 SNMP 警报：
 

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. 再次检查事件计数器。我们可以看到又交付了一个 snmp 事件。

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. 检查 storenvtd 调试日志：

如果您可以在日志中找到以下条目，则会显示 storevntd 已成功交付 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

以上证据表明，SNMP 警报已从 Unisphere 端成功发送。如果我们无法使用 tcpdump 和 storevntd 捕获 SNMP 软件包，也没有成功交付事件的证据，请收集 emcgrab 并联系技术支持。