Как устранить неполадки, связанные с тем, что целевой ресурс SNMP не получает SNMP-оповещения, отправляемые из Unisphere.

Ниже приведены четыре места для проверки того, не получает ли целевой ресурс SNMP оповещения SNMP, отправляемые из Unisphere.
 

• Слово сообщества целевого адреса SNMP заказчика должно совпадать со словом сообщества по умолчанию (SNMP_trap) Unisphere.  
• Заказчик должен обеспечить хорошее сетевое подключение между сервером Unisphere и целевым объектом SNMP. Мы можем использовать команды openssl и tracepath на сервере Unisphere для проверки подключения и использовать команду tcpdump на сервере Unisphere для сбора пакета SNMP во время тестов оповещений. Проще всего доказать, что Unisphere может успешно отправлять оповещения SNMP, так как целевой объект SNMP должен быть напрямую подключен к серверу Unisphere. Если целевой ресурс SNMP, подключенный напрямую, может получать оповещения SNMP, в то время как нетпосредовое подключение невозможно, это означает, что проблема связана с сетью заказчика.  
• Все настройки оповещений SNMP Unisphere должны быть настроены правильно, в том числе:    
• Конфигурация уведомлений SNMP, настройка политики оповещений, уровень уведомлений.

 
Если описанные выше проблемы отсутствуют, служба поддержки должна продолжить проверку оповещений с включенным журналом отладки SE storevntd , набором ведения журнала smas INFO и сбором tcpdump . Соберите результаты emcgrab и тестов, если не видим доказательства успешной отправки оповещений SNMP.
Обратите внимание, что во время тестирования лучше создавать реальные оповещения, кроме использования функции TEST SNMP, поскольку по сравнению с реальными оповещениями пакет TEST SNMP небольшой и более ненадежный для передачи для пакета UDP.

 

Подробные инструкции по поиску и устранению неисправностей: 

1. Слово сообщества SNMP.

Слово сообщества по умолчанию : «SNMP_trap». Если оно не соответствует слову сообщества целевого адреса SNMP, мы можем изменить его, добавив следующую строку в se daemon_options файле:
 

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

Сохраните файл, а затем перезапустите демон storevntd , чтобы изменения вступили в силу. (Не используйте команду перезагрузки, так как она не является надежной.)

stordaemon shutdown storevntd
stordaemon start storevntd

После перезапуска storenvtd политики оповещений, ранее загруженные со страницы конфигурации оповещений Unisphere, также будут потеряны. Чтобы политики оповещений были перезагружены и зарегистрированы в storevntd, необходимо перезапустить сервис smas .
(Приведенная ниже команда предназначена для перезапуска службы smas на сервере Linux. Можно отслеживать, что события SNMP не отправляются на встроенный сервер U4V или SNMP для перезапуска службы smas для встроенной системы Unisphere.

На сервере Unisphere перейдите к пути /etc/init.d и выполните следующие команды:

./smas stop
./smas start

Затем можно использовать следующую команду для проверки статуса регистрации события storevntd . (События, зарегистрированные в storevntd после перезапуска smas, занимает некоторое время.)

stordaemon action storevntd -cmd list -regs –v

 

2. Возможности сетевого подключения.

Мы можем использовать команду openssl и tracepath на сервере Unisphere, чтобы проверить, правильно ли 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. Параметры оповещений SNMP Unisphere:

 

1. Конфигурация оповещений SNMP.  

Settings - Alerts - Notifications, нажмите на слово Configure (Настроить) на блоке SNMP и убедитесь, что настроен правильный IP-адрес и порт целевого адреса SNMP.

(Примечание. Тестируйте с помощью одного целевого устройства 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». Убедитесь, что установлен флажок «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. Выполните команду tcpdump на сервере Unisphere, чтобы подготовиться к сбору пакета 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. Создайте LUN 100 Мбайт в Unisphere. Проверьте панель оповещений Unisphere и убедитесь, что создается оповещение «Device configuration has changed». Если вы не видите всплывающее оповещение, нажмите кнопку «Обновить» на верхней панели страницы Unisphere.

 (Если также включена политика «состояние устройства», также может отобразится оповещение «Device state has changed to Online».


 

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. Если не удается зафиксировать пакет SNMP с помощью tcpdump и storevntd , также нет признаков успешной доставки события, соберите emcgrab и обратитесь в службу технической поддержки.