Rozwiązywanie problemów z celem SNMP, który nie odbiera alertów SNMP wysyłanych z Unisphere.

Poniżej przedstawiono cztery miejsca, w których można sprawdzić, czy cel SNMP nie odbiera alertów SNMP wysłanych z Unisphere.
 

• Słowo społeczności celu SNMP klienta powinno być zgodne z domyślnym słowem społeczności (SNMP_trap) Unisphere.  
• Klient musi zapewnić prawidłową łączność sieciową między serwerem Unisphere a docelowym protokołem SNMP. Za pomocą poleceń opensl i tracepath na serwerze Unisphere można zweryfikować łączność i użyć polecenia tcpdump na serwerze Unisphere w celu przechwycenia pakietu SNMP podczas testów alertów. Prostym sposobem na potwierdzenie, że Unisphere może pomyślnie wysyłać alerty SNMP, jest bezpośrednie połączenie celu SNMP z serwerem Unisphere. Jeśli bezpośrednio podłączony cel SNMP może odbierać alerty SNMP, podczas gdy połączenie nie pośrednio nie może, oznacza to, że problem dotyczy sieci klienta.  
• Należy poprawnie skonfigurować wszystkie ustawienia alertów SNMP Unisphere, które obejmują:    
• Konfiguracja powiadomień SNMP, ustawienie zasad alertów, poziom powiadomień.

 
Jeśli powyższe problemy nie występują, pomoc techniczna musi kontynuować test alertów z włączonym dziennikiem debugowania sE storevntd , ustawieniem rejestrowania smas INFO i przechwyconą tcpdump . Zbierz emcgrab i wyniki testów, jeśli nie widzimy dowodów na to, że alerty SNMP zostały pomyślnie wysłane.
Uwaga: lepiej jest generować prawdziwe alerty inne niż użycie funkcji "TEST SNMP" podczas testu, ponieważ w porównaniu z rzeczywistymi alertami pakiet "TEST SNMP" jest mały i bardziej niestabilny w przesyłaniu pakietu UDP.

 

Szczegółowe kroki rozwiązywania problemów: 

1. Słowo społeczności SNMP.

Domyślne słowo społeczności to "SNMP_trap". Jeśli nie pasuje do słowa społeczności docelowego SNMP, można go zmienić, dodając następujący wiersz w pliku daemon_options SE:
 

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

Zapisz plik, a następnie uruchom ponownie demona przechowywania , aby zmiany zostały wprowadzone. (Nie należy używać polecenia ponownego ładowania, ponieważ nie jest ono niezawodne)

stordaemon shutdown storevntd
stordaemon start storevntd

Po ponownym uruchomieniu storenvtd zasady alertów załadowane wcześniej ze strony konfiguracji alertów Unisphere również się gubią. Aby zasady alertów zostały ponownie załadowane i zarejestrowane w magazynie, należy również ponownie uruchomić usługę smas .
(Poniższe polecenie dotyczy ponownego uruchomienia usługi smas na serwerze Linux. Zdarzenia SNMP nie są wysyłane do wbudowanego serwera U4V lub SNMP , aby ponownie uruchomić usługę smas dla wbudowanej unisphere).

Na serwerze Unisphere przejdź do ścieżki /etc/init.d, a następnie uruchom następujące polecenia:

./smas stop
./smas start

Następnie można użyć poniższego polecenia, aby sprawdzić stan rejestracji zdarzenia zapisanego w pamięci. (Zdarzenie zarejestrowane w pamięci masowej po ponownym uruchomieniu smas zajmuje trochę czasu)

stordaemon action storevntd -cmd list -regs –v

 

2. Łączność sieciowa.

Można użyć polecenia opensl i tracepath na serwerze Unisphere, aby sprawdzić, czy Unisphere może prawidłowo komunikować się z celem 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. Ustawienia alertów SNMP Unisphere:

 

1. Konfiguracja powiadomień o alertach SNMP.  

Ustawienia — alerty — powiadomienia, kliknij słowo "Configure" w bloku SNMP i upewnij się, że skonfigurowano prawidłowy docelowy adres IP i port SNMP.

(Uwaga: Przetestuj za pomocą jednego celu SNMP, aby uniknąć złożoności testu).



Aby sprawdzić, czy te konfiguracje zostały pomyślnie załadowane do demona magazynu, można użyć następującego polecenia, aby sprawdzić:

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

(w przypadku alertu syslog pierwsze dwa odpowiednie polecenia to:

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

 

2. Ustawienie zasad alertów

Później wygenerujemy alert o zmianie konfiguracji urządzenia dla testu alertu, dlatego w tym przykładzie używamy zasady "device config change". Upewnij się, że opcja Device Config Change (Zmiana konfiguracji urządzenia) jest zaznaczona dla macierzy używanej do testowania alertów, a typ powiadomień jest określony w SNMP.



 

3. Poziom powiadomień

Tworząc nowe urządzenie dla testu alertu, generowany alert to "Device configuration has changed" (Konfiguracja urządzenia uległa zmianie). Alert znajduje się na poziomie informacyjnym, dlatego należy upewnić się, że wybrano niebieską ikonę dla testu alertu.


 

4. Włącz dziennik debugowania storevntd i dziennik INFORMACJI Unisphere

 Zmień następujące parametry w pliku daemon_options SE:

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

Zapisz plik zgodnie z krokiem 1; należy ponownie uruchomić demona magazynu , a następnie ponownie uruchomić usługę smas .
Po ponownym uruchomieniu usługi smas zmień poziom rejestrowania Unisphere na INFO. (Uwaga: Ponowne uruchomienie usługi smas zmienia poziom rejestrowania z powrotem na domyślny, czyli WARN. ).
 

5. Test alertu

Wygenerowanie rzeczywistego alertu, użycie polecenia tcpdump do przechwycenia pakietu SNMP i sprawdzenie dziennika debugowania storevntd . 

1. Uruchom polecenie tcpdump na serwerze Unisphere, aby przygotować się do przechwytywania pakietu SNMP:

tcpdump -i any udp port 162 

2. Uruchom następujące polecenie, aby sprawdzić istniejący licznik zdarzeń 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. Utwórz lunę 100M w Unisphere. Sprawdź panel alertów Unisphere i sprawdź, czy wygenerowany jest alert "Device configuration has changed" (Konfiguracja urządzenia uległa zmianie). Jeśli nie widzisz wyskakującego okna alertu, kliknij przycisk odświeżania na górnym pasku strony Unisphere.

 (Jeśli włączono również zasady "device status", wyświetlany jest również alert "Device state has changed to Online").


 

4. Sprawdź dane wyjściowe protokołu tcpdump.

Poniżej przedstawiono, że alert SNMP został pomyślnie przechwycony:
 

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. Sprawdź ponownie licznik zdarzeń. Możemy zobaczyć jeszcze jedno zdarzenie 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. Sprawdź dziennik debugowania storenvtd :

Jeśli w dzienniku można znaleźć następujące wpisy, widać, że plik storevntd pomyślnie dostarczył alert 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

Powyższe dowody wskazują, że alert SNMP został pomyślnie wysłany z strony Unisphere. Jeśli nie uda nam się przechwycić pakietu SNMP za pomocą polecenia tcpdump i storevntd , nie ma dowodów na pomyślne dostarczenie zdarzenia, należy zebrać emcgrab i zaangażować pomoc techniczną.