Anleitung zum Troubleshooting, wenn ein SNMP-Ziel keine SNMP-Warnmeldungen empfängt, die von Unisphere gesendet werden.

Im Folgenden finden Sie die vier Orte, an denen Sie prüfen können, ob ein SNMP-Ziel keine SNMP-Warnmeldungen empfängt, die von Unisphere gesendet werden.
 

• Das Communitywort des SNMP-Ziels des Kunden sollte mit dem Standardcommunitywort (SNMP_trap) von Unisphere übereinstimmen.  
• Der Kunde muss eine gute Netzwerkverbindung zwischen dem Unisphere-Server und dem SNMP-Ziel sicherstellen. Wir können opensl - und tracepath-Befehle auf dem Unisphere-Server verwenden, um die Konnektivität zu überprüfen und den Tcpdump-Befehl auf dem Unisphere-Server zu verwenden, um das SNMP-Paket während Warnungstests zu erfassen. Eine einfache Möglichkeit, zu beweisen, dass Unisphere SNMP-Warnmeldungen erfolgreich senden kann, besteht darin, dass ein SNMP-Ziel direkt mit dem Unisphere-Server verbunden ist. Wenn das direkt verbundene SNMP-Ziel SNMP-Warnmeldungen empfangen kann, während die nicht indirekt verbundene nicht, bedeutet dies, dass das Problem mit dem Netzwerk des Kunden zusammenliegt.  
• Unisphere-SNMP-Warnungseinstellungen sollten alle korrekt eingestellt sein, einschließlich:    
• SNMP-Benachrichtigungskonfiguration, Warnungsrichtlinieneinstellung, Benachrichtigungsebene.

 
Wenn die oben genannten Probleme nicht auftreten, muss der Support mit dem Warnungstest mit aktivierten SE storevntd-Debug-Protokollen, smas INFO-Protokollierungssatz und erfassten tcpdump fortfahren. Sammeln Sie emcgrab - und Testergebnisse, wenn wir keine Nachweise dafür sehen können, dass SNMP-Warnmeldungen erfolgreich gesendet wurden.
Beachten Sie, dass es besser ist, während des Tests echte Warnmeldungen zu erzeugen, als die Funktion "TEST SNMP", da das Paket "TEST SNMP" im Vergleich zu echten Warnmeldungen klein und unzuverlässiger für das UDP-Paket ist.

 

Detaillierte Schritte für das Troubleshooting: 

1. SNMP-Communitywort.

Das Standard-Communitywort lautet "SNMP_trap". Wenn es nicht mit dem Communitywort des SNMP-Ziels übereinstimmt, können sie geändert werden, indem Sie die folgende Zeile in der SE-daemon_options-Datei hinzufügen:
 

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

Speichern Sie die Datei und starten Sie dann den storevntd-Daemon neu, damit die Änderung wirksam wird. (Verwenden Sie den Befehl "reload" nicht, da er nicht zuverlässig ist.)

stordaemon shutdown storevntd
stordaemon start storevntd

Sobald storenvtd neu gestartet wurde, gehen auch die Zuvor von der Unisphere-Warnungskonfigurationsseite geladenen Warnungsrichtlinien verloren. Damit die Warnungsrichtlinien neu geladen und in storevntd registriert werden können, müssen wir auch den smas-Service neu starten.
(Der folgende Befehl dient zum Neustarten des smas-Dienstes auf dem Linux-Server. Sie können folgen , dass SNMP-Ereignisse nicht an den integrierten U4V- oder SNMP-Server gesendet werden , um den smas-Service für embedded Unisphere neu zu starten.

Führen Sie auf dem Unisphere-Server cd zum Pfad /etc/init.d aus und führen Sie dann die folgenden Befehle aus:

./smas stop
./smas start

Dann können wir den folgenden Befehl verwenden, um den Registrierungsstatus des storevntd-Ereignisses zu überprüfen. (Es dauert etwas Zeit für Ereignisse, die nach dem Neustart von smas in storevntd registriert sind.)

stordaemon action storevntd -cmd list -regs –v

 

2. Netzwerkkonnektivität.

Wir können den Befehl openssl und tracepath auf dem Unisphere-Server verwenden, um zu überprüfen, ob Unisphere gut mit dem SNMP-Ziel kommunizieren kann.
 

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-Warnungseinstellungen:

 

1. Konfiguration der SNMP-Warnmeldungsbenachrichtigung.  

Einstellungen – Warnungen – Benachrichtigungen, klicken Sie auf das Wort "Configure" auf dem SNMP-Block und stellen Sie sicher, dass die richtige SNMP-Ziel-IP und der richtige Port konfiguriert sind.

(Hinweis: Testen Sie mit einem einzigen SNMP-Ziel, um die Komplexität des Tests zu vermeiden.)



Um zu überprüfen, ob diese Konfigurationen erfolgreich in den Storevntd-Daemon geladen wurden, können wir den folgenden Befehl verwenden, um zu überprüfen:

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

(Für syslog-Warnmeldungen sind die ersten beiden entsprechenden Befehle:

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

 

2. Warnungsrichtlinieneinstellung

Später erzeugen wir eine echte Warnung zur Änderung der Gerätekonfiguration für den Warnungstest. Hier verwenden wir die Richtlinie "Gerätekonfigurationsänderung" als Beispiel. Stellen Sie sicher, dass "Device Config Change" für das Array aktiviert ist, das für den Warnungstest verwendet wird, und dass der Benachrichtigungstyp mit SNMP angegeben ist.



 

3. Benachrichtigungsebene

Durch die Erstellung eines neuen Geräts für den Warnungstest lautet die warnmeldung, die wir erzeugen, "Device configuration has changed". Die Warnmeldung befindet sich auf Der Informationsebene, daher müssen wir sicherstellen, dass das blaue Symbol mindestens für einen Warnungstest ausgewählt ist.


 

4. Aktivieren des storevntd-Debug-Protokolls und des Unisphere INFO-Protokolls

 Ändern Sie die folgenden Parameter in der SE-daemon_options datei:

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

Speichern Sie die Datei gemäß Schritt 1. müssen wir storevntd daemon neu starten und dann den smas-Service neu starten.
Nachdem der smas-Service neu gestartet wurde, ändern Sie die Protokollierungsebene von Unisphere in INFO. (Hinweis: Durch den Neustart des smas-Services wird die Protokollierungsstufe wieder auf die Standardeinstellung zurückgesetzt, was WARN ist. )
 

5. Warnungstest

Erzeugen Sie eine echte Warnmeldung, verwenden Sie tcpdump , um das SNMP-Paket zu erfassen und das storevntd-Debug-Protokoll zu überprüfen. 

1. Führen Sie den Befehl tcpdump auf dem Unisphere-Server aus, um sich für die SNMP-Paketerfassung vorzubereiten:

tcpdump -i any udp port 162 

2. Führen Sie den folgenden Befehl aus, um den vorhandenen SNMP-Ereigniszähler zu überprüfen:

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. Erstellen Sie eine 100-M-LUN in Unisphere. Überprüfen Sie den Unisphere-Warnungsbereich und Sie sehen, dass die Warnung "Device configuration has changed" (Gerätekonfiguration wurde geändert) erzeugt wird. Wenn das Pop-out-Fenster der Warnmeldung nicht angezeigt wird, klicken Sie auf die Schaltfläche "Aktualisieren" in der oberen Leiste der Unisphere-Seite.

 (Wenn Sie auch die Richtlinie "Gerätestatus" aktiviert haben, können Sie auch sehen, dass die Warnmeldung "Device state has changed to Online" generiert wird.)


 

4. Überprüfen Sie die Ausgabe von tcpdump.

Im Folgenden wird angezeigt, dass die SNMP-Warnmeldung erfolgreich erfasst wurde:
 

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. Überprüfen Sie den Ereigniszähler erneut. Wir können ein weiteres snmp-Ereignis sehen.

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. Überprüfen Sie das storenvtd-Debug-Protokoll :

Wenn Sie die folgenden Einträge im Protokoll finden, wird angezeigt, dass storevntd die SNMP-Warnmeldung erfolgreich bereitgestellt hat:

 [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

Die obigen Nachweise zeigen, dass die SNMP-Warnmeldung erfolgreich von der Unisphere-Seite gesendet wurde. Wenn wir das SNMP-Paket nicht mit tcpdump erfassen können und storevntd ebenfalls keine Nachweise für eine erfolgreiche Ereignisbereitstellung hat, erfassen Sie die emcgrab und wenden Sie sich an den technischen Support.