Ereigniskatalog

Die folgenden Tabellen beschreiben die Ereignisse, die Alarme auslösen, einschließlich Alarmmeldungen und empfohlenen Aktionen, um sie zu beheben. Jedes Ereignis mit einem Schweregrad, der größer als NIEDRIG ist, löst einen Alarm aus.

Alarmmanagement-Ereignisse

Alarmmanagement-Ereignisse stammen aus den NSX Manager- und Global Manager-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Alarmdienst überlastet	Kritisch	Der Alarmdienst ist überlastet. Bei Erkennung des Ereignisses: „Aufgrund einer hohen Anzahl an gemeldeten Alarmen ist der Alarmdienst vorübergehend überlastet. Die NSX-Benutzeroberfläche und GET /api/v1/alarms NSX API melden keine neuen Alarme mehr. Syslog-Einträge und SNMP-Traps (sofern aktiviert) werden jedoch weiterhin ausgegeben und melden die zugrunde liegenden Ereignisdetails. Wenn die Ursachen für die hohe Anzahl an Alarmen behoben sind, meldet der Alarmdienst wieder neue Alarme.“ Bei Auflösung des Ereignisses: „Die hohe Anzahl von Alarmen hat sich verringert und es werden wieder neue Alarme gemeldet.“	Überprüfen Sie alle aktiven Alarme auf der Seite „Alarme“ auf der NSX-Benutzeroberfläche oder mit der GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED-NSX API. Untersuchen Sie für jeden aktiven Alarm die Hauptursache, indem Sie die empfohlene Aktion für den Alarm befolgen. Wenn ausreichend Alarme behoben sind, beginnt der Alarmdienst erneut, neue Alarme zu melden.
Hohe Anzahl von Alarmen	Kritisch	Eine hohe Anzahl von Alarmen eines bestimmten Typs wurde erkannt. Bei Erkennung des Ereignisses: Aufgrund einer hohen Anzahl an {event_id}-Alarmen zeigt der Alarmdienst vorübergehend keine Alarme dieses Typs mehr an. Die grafische Benutzeroberfläche (GUI) von NSX und die NSX API GET /api/v1/alarms melden keine neuen Instanzen dieser Alarme. Syslog-Einträge und SNMP-Traps (sofern aktiviert) werden jedoch weiterhin ausgegeben und melden die zugrunde liegenden Ereignisdetails. Wenn die Ursachen für die hohe Anzahl von {event_id}-Alarmen behoben sind, meldet der Alarmdienst bei Problemen wieder neue {event_id}-Alarme.“ Bei Auflösung des Ereignisses: „Die hohe Anzahl von {event_id}-Alarmen hat sich verringert und es werden wieder neue Alarme dieses Typs gemeldet.“	Überprüfen Sie alle aktiven Alarme auf der Seite „Alarme“ auf der NSX-Benutzeroberfläche oder mit der GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED-NSX API. Untersuchen Sie für jeden aktiven Alarm die Hauptursache, indem Sie die empfohlene Maßnahme für den Alarm befolgen. Wenn ausreichend Alarme behoben sind, beginnt der Alarmdienst erneut, neue {event_id}-Alarme zu melden.

Ereignisse in Bezug auf den Überwachungsprotokollzustand

Ereignisse in Bezug auf den Überwachungsprotokollzustand ergeben sich aus den NSX Manager- und den globalen Manager-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Überwachungsprotokollzustand	Kritisch	In mindestens eine der überwachten Protokolldateien kann nicht geschrieben werden. Bei Erkennung des Ereignisses: „Mindestens eine der überwachten Protokolldateien hat Nur-Lesen-Berechtigungen oder hat falsche Benutzer-/Gruppen-Eigentümerschaft, oder rsyslog.log fehlt auf Manager-, globalen Manager-, Edge- oder Public Cloud Gateway-Knoten.“ Bei Auflösung des Ereignisses: „Alle überwachten Protokolldateien verfügen über die korrekten Dateiberechtigungen und die richtige Eigentümerschaft, und rsyslog.log ist auf Manager-, globalen Manager-, Edge- oder Public Cloud Gateway-Knoten vorhanden.“	Stellen Sie auf allen NSX-Appliances, z. B. Manager-Knoten und Edge-Knoten, sicher, dass die Berechtigung für das Verzeichnis /var/log 775 lautet und dass als Eigentümerschaft root:syslog angegeben ist. Auf Manager- und globalen Manager-Knoten: Stellen Sie sicher, dass die Dateiberechtigungen für auth.log, nsx-audit.log, nsx-audit-write.log, rsyslog.log und syslog.log unter /var/log 640 lauten und dass als Eigentümerschaft syslog:admin angegeben ist. Stellen Sie auf Edge- und Public Cloud Gateway-Knoten sicher, dass die Dateiberechtigungen für rsyslog.log und syslog.log unter /var/log 640 lauten und dass als Eigentümerschaft syslog:admin angegeben ist. Stellen Sie auf ESXi-Hostknoten sicher, dass die Dateiberechtigungen von auth.log, nsx-syslog.log und syslog.log unter /var/log 755 lauten und dass als Eigentümerschaft root:root angegeben ist. Stellen Sie auf KVM-Hostknoten sicher, dass die Dateiberechtigungen von auth.log und syslog.log unter /var/log 775 lauten und dass als Eigentümerschaft root:syslog angegeben ist. 6. Wenn eine dieser Dateien über falsche Berechtigungen oder eine falsche Eigentümerschaft verfügt, rufen Sie die Befehle chmod <mode> <path> und chown <user>:<group> <path> auf. 7. Wenn rsyslog.log auf Manager-, globalen Manager-, Edge- oder Public Cloud Gateway-Knoten fehlt, rufen Sie in der NSX-CLI den Befehl restart service syslog auf. Dieser Befehl startet Protokollierungsdienst neu und generiert /var/log/rsyslog.log neu.
Fehler beim Remote-Protokollierungsserver	Kritisch	Protokollmeldungen können aufgrund einer fehlerhaften Konfiguration des Remote-Protokollierungsservers nicht zugestellt werden. Bei Erkennung des Ereignisses: „Protokollmeldungen an Protokollserver {hostname_or_ip_address_with_port} ({entity_id}) können aufgrund eines nicht auflösbaren FQDN, eines ungültigen TLS-Zertifikats oder einer fehlenden iptables-Regel der NSX-Appliance möglicherweise nicht zugestellt werden.“ Bei Auflösung des Ereignisses: „Konfiguration für Protokollierungsserver {hostname_or_ip_address_with_port} ({entity_id}) wird korrekt angezeigt.“	Stellen Sie sicher, dass {hostname_or_ip_address_with_port} der richtige Hostname bzw. die richtige IP-Adresse und der richtige Port ist. Wenn der Protokollierungsserver mithilfe eines FQDN angegeben wird, stellen Sie sicher, dass der FQDN mithilfe des NSX-CLI-Befehls nslookup <fqdn> über die NSX-Appliance aufgelöst werden kann. Wenn er nicht aufgelöst werden kann, überprüfen Sie, ob der richtige FQDN angegeben ist und ob der Netzwerk-DNS-Server über den erforderlichen Eintrag für den FQDN verfügt. Wenn der Protokollierungsserver für die Verwendung von TLS konfiguriert ist, achten Sie darauf, dass das angegebene Zertifikat gültig ist. Achten Sie beispielsweise darauf, dass der Protokollierungsserver tatsächlich das Zertifikat verwendet, oder überprüfen Sie mit dem OpenSSL-Befehl openssl x509 -in <cert-file-path> -noout -dates, dass das Zertifikat nicht abgelaufen ist. NSX-Appliances verwenden iptables-Regeln, um ausgehenden Datenverkehr explizit zuzulassen. Stellen Sie sicher, dass die iptables-Regel für den Protokollierungsserver ordnungsgemäß konfiguriert ist. Rufen Sie dazu den NSX-CLI-Befehl verify logging-servers auf, der die Iptables-Regeln des Protokollierungsservers nach Bedarf neu konfiguriert. Wenn der Protokollierungsserver aus irgendeinem Grund falsch konfiguriert ist, sollte er mithilfe des NSX-CLI-Befehls del logging-server <hostname-or-ip-address[:port]> proto <proto> level <level> gelöscht und mit der korrekten Konfiguration erneut hinzugefügt werden. Weitere Informationen zum Konfigurieren von NSX-T Data Center-Appliances und -Hypervisoren zum Senden von Protokollmeldungen an einen Remoteprotokollierungsserver finden Sie unter Konfigurieren der Remote-Protokollierung. Wenn der Remote-Protokollserver keine Protokolle empfängt, siehe Fehlerbehebung für Probleme mit Syslog.

Kapazitätsereignisse

Die folgenden Ereignisse können Alarme auslösen, wenn der aktuelle Bestand bestimmter Objektkategorien eine bestimmte Stufe erreicht. Weitere Informationen finden Sie unter Nutzung und Kapazität von Objektkategorien anzeigen.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Maximale Kapazität	Kritisch	Eine maximale Kapazität wurde überschritten. Bei Erkennung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, was mindestens der maximal unterstützten Anzahl von {max_supported_capacity_count} entspricht.“ Bei Auflösung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht und liegt unter der maximal unterstützten Anzahl von {max_supported_capacity_count}.“	Stellen Sie sicher, dass die Anzahl der erstellten NSX-Objekte innerhalb der von NSX unterstützten Grenzwerte liegt. Wenn nicht verwendete Objekte vorhanden sind, löschen Sie sie jeweils über die NSX-Benutzeroberfläche oder die NSX API aus dem System. Ziehen Sie eine Erhöhung des Formfaktors aller Manager-Knoten und/oder Edge-Knoten in Betracht. Beachten Sie, dass der Formfaktor der einzelnen Knotentypen identisch sein muss. Andernfalls werden die Kapazitätsgrenzwerte für den kleinsten bereitgestellten Formfaktor verwendet.
Schwellenwert für Maximalkapazität	Hoch	Ein Grenzwert für die maximale Kapazität wurde überschritten. Bei Erkennung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, was mindestens dem Schwellenwert für Maximalkapazität von {max_capacity_threshold}% entspricht.“ Bei Auflösung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht und liegt unter dem Schwellenwert für Maximalkapazität von {max_supported_capacity_count}%.“	Navigieren Sie auf der NSX-Benutzeroberfläche zur Seite „Kapazität“ und prüfen Sie die aktuelle Nutzung mit den Schwellenwerten. Wenn die aktuelle Nutzung erwartungsgemäß ist, können Sie die maximalen Schwellenwerte erhöhen. Wenn die aktuelle Nutzung unerwartet ist, überprüfen Sie die konfigurierten Netzwerkrichtlinien, mit denen die Nutzung unter den maximalen Schwellenwert gesenkt werden soll.
Schwellenwert für Mindestkapazität	Mittel	Ein Grenzwert für die minimale Kapazität wurde unterschritten. Bei Erkennung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht, was mindestens dem Schwellenwert für Mindestkapazität von {min_capacity_threshold}% entspricht.“ Bei Auflösung des Ereignisses: „Die Anzahl der im System für {capacity_display_name} definierten Objekte hat {capacity_usage_count} erreicht und liegt unter der Schwellenwert für Mindestkapazität von {min_capacity_threshold}%.“	Navigieren Sie auf der NSX-Benutzeroberfläche zur Seite „Kapazität“ und prüfen Sie die aktuelle Nutzung mit den Schwellenwerten. Wenn die aktuelle Nutzung erwartungsgemäß ist, können Sie die minimalen Schwellenwertwerte erhöhen. Wenn die aktuelle Nutzung unerwartet ist, überprüfen Sie die konfigurierten Netzwerkrichtlinien, mit denen die Nutzung unter den minimalen Schwellenwert gesenkt werden soll.

Zertifikatsereignisse

Zertifikatsereignisse stammen vom NSX Manager-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Zertifikat abgelaufen	Kritisch	Ein Zertifikat ist abgelaufen. Bei Erkennung des Ereignisses: „Das Zertifikat {entity-id} ist abgelaufen.“ Bei Auflösung des Ereignisses: „Das abgelaufene Zertifikat {entity-id} wurde entfernt oder ist nicht mehr abgelaufen.	Stellen Sie sicher, dass Dienste, die das Zertifikat aktuell verwenden, aktualisiert werden, um ein neues, nicht abgelaufenes Zertifikat zu verwenden. Wenn Sie beispielsweise ein neues Zertifikat auf den HTTP-Dienst anwenden möchten, rufen Sie den folgenden API-Aufruf auf: POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<cert-id> Dabei ist <cert-id> die ID eines gültigen Zertifikats, das vom API-Aufruf GET /api/v1/trust-management/certificates gemeldet wird. Nachdem das abgelaufene Zertifikat nicht mehr verwendet wird, sollte es mit folgendem API-Aufruf gelöscht werden: DELETE /api/v1/trust-management/certificates/{entity_id}
Zertifikat läuft in Kürze ab	Hoch	Zertifikat läuft in Kürze ab. Bei Erkennung des Ereignisses: „Das Zertifikat {entity-id} läuft demnächst ab.“ Bei Auflösung des Ereignisses: „Das ablaufende Zertifikat {entity-id} läuft nicht mehr ab.“	Stellen Sie sicher, dass Dienste, die das Zertifikat aktuell verwenden, aktualisiert werden, um ein neues, nicht ablaufendes Zertifikat zu verwenden. Wenn Sie beispielsweise ein neues Zertifikat auf den HTTP-Dienst anwenden möchten, rufen Sie den folgenden API-Aufruf auf: POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<cert-id> Dabei ist <cert-id> die ID eines gültigen Zertifikats, das vom API-Aufruf GET /api/v1/trust-management/certificates gemeldet wird. Nachdem das ablaufende Zertifikat nicht mehr verwendet wird, sollte es mit dem API-Aufruf gelöscht werden: DELETE /api/v1/trust-management/certificates/{entity_id}
Zertifikatsablauf steht bevor	Mittel	Ein Zertifikat läuft in Kürze ab. Bei Erkennung des Ereignisses: „Das Zertifikat {entity-id} läuft in Kürze ab.“ Bei Auflösung des Ereignisses: „Das ablaufende Zertifikat {entity-id} läuft nicht mehr in Küre ab.“	Stellen Sie sicher, dass Dienste, die das Zertifikat aktuell verwenden, aktualisiert werden, um ein neues, nicht ablaufendes Zertifikat zu verwenden. Wenn Sie beispielsweise ein neues Zertifikat auf den HTTP-Dienst anwenden möchten, rufen Sie den folgenden API-Aufruf auf: POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<cert-id> Dabei ist <cert-id> die ID eines gültigen Zertifikats, das vom API-Aufruf GET /api/v1/trust-management/certificates gemeldet wird. Nachdem das ablaufende Zertifikat nicht mehr verwendet wird, sollte es mit dem API-Aufruf gelöscht werden: DELETE /api/v1/trust-management/certificates/{entity_id}

CNI-Integritätsereignisse

CNI-Integritätsereignisse stammen aus den ESXi- und KVM-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Hyperbus Manager-Verbindung ausgefallen	Mittel	Hyperbus kann nicht mit dem Manager-Knoten kommunizieren. Bei Erkennung des Ereignisses: „Hyperbus kann nicht mit dem Manager-Knoten kommunizieren.“. Bei Auflösung des Ereignisses: „Hyperbus kann mit dem Manager-Knoten kommunizieren.“	Möglicherweise fehlt die Hyperbus-VMkernel-Schnittstelle (vmk50). Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel 67432.

DHCP-Ereignisse

DHCP-Ereignisse stammen von den NSX Edge- und öffentlichen Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Pool-Lease-Zuteilung fehlgeschlagen	Hoch	Die IP-Adressen in einem IP-Pool wurden ausgeschöpft. Bei Erkennung des Ereignisses: „Die IP-Adressen im IP-Pool {entity_id} des DHCP-Servers {dhcp_server_id} sind verbraucht. Die letzte DHCP-Anforderung schlug fehl, zukünftige Anforderungen schlagen ebenfalls fehl.“ Bei Auflösung des Ereignisses: „IP-Pool {entity_id} des DHCP-Servers {dhcp_server_id} ist nicht mehr verbraucht. Ein Lease wird erfolgreich der letzten DHCP-Anforderung zugeteilt.“	Überprüfen Sie die Konfiguration des DHCP-Pools in der NSX-Benutzeroberfläche oder auf dem Edge-Knoten, auf dem der DHCP-Server ausgeführt wird, indem Sie den NSX-CLI-Befehl get dhcp ip-pool ausführen. Überprüfen Sie auch die aktuellen aktiven Leases auf dem Edge-Knoten, indem Sie den NSX-CLI-Befehl get dhcp lease aufrufen. Vergleichen Sie die Leases mit der Anzahl aktiver VMs. Sie sollten die Leasedauer in der DHCP-Serverkonfiguration verringern, wenn die Anzahl von VMs im Vergleich zur Anzahl aktiver Leases niedrig ist. Sie sollten auch den Poolbereich für den DHCP-Server erweitern, indem Sie die Seite Netzwerk > Segmente > Segment auf der NSX-Benutzeroberfläche aufrufen.
Pool überladen	Mittel	Ein IP-Pool ist überladen. Bei Erkennung des Ereignisses: „Die Nutzung des IP-Pools {entity_id} des DHCP-Servers {dhcp_server_id} ist in Kürze ausgeschöpft. Es sind {dhcp_pool_usage} % IPs zugeteilt.“ Bei Auflösung des Ereignisses: „Der IP-Pool {entity_id} des DHCP-Servers {dhcp_server_id} ist unter den hohen Nutzungsschwellenwert gefallen.“	Überprüfen Sie die Konfiguration des DHCP-Pools in der NSX-Benutzeroberfläche oder auf dem Edge-Knoten, auf dem der DHCP-Server ausgeführt wird, indem Sie den NSX-CLI-Befehl get dhcp ip-pool ausführen. Überprüfen Sie auch die aktuellen aktiven Leases auf dem Edge-Knoten, indem Sie den NSX-CLI-Befehl get dhcp lease aufrufen. Vergleichen Sie die Leases mit der Anzahl aktiver VMs. Sie sollten die Leasedauer in der DHCP-Serverkonfiguration verringern, wenn die Anzahl von VMs im Vergleich zur Anzahl aktiver Leases niedrig ist. Sie sollten auch den Poolbereich für den DHCP-Server erweitern, indem Sie die Seite Netzwerk > Segmente > Segment auf der NSX-Benutzeroberfläche aufrufen.

Ereignisse der verteilten Firewall

Ereignisse der verteilten Firewall stammen von den NSX Manager- oder ESXi-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
DFW-CPU-Auslastung sehr hoch	Kritisch	Die DFW-CPU-Nutzung ist sehr hoch. Bei Erkennung des Ereignisses: „Die DFW-CPU-Auslastung auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die DFW-CPU-Nutzung auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen. Überprüfen Sie das Sicherheitsdesign für die Optimierung. Verwenden Sie beispielsweise die Konfiguration „Anwenden auf“, wenn die Regeln nicht auf das gesamte Datencenter zutreffen.
DFW-Arbeitsspeichernutzung sehr hoch	Kritisch	Die DFW-Arbeitsspeichernutzung ist sehr hoch. Bei Erkennung des Ereignisses: „Die DFW-Arbeitsspeicherauslastung {heap_type} auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die DFW-Arbeitsspeicherauslastung {heap_type} auf dem Transportknoten {entity_id} hat {system_resource_usage} % erreicht und ist geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Zeigen Sie die aktuelle DFW-Arbeitsspeicherauslastung an, indem Sie den NSX-CLI-Befehl get firewall thresholds auf dem Host aufrufen. Erwägen Sie, die Arbeitslasten auf diesem Host erneut auf andere Hosts auszugleichen.

Verteilte IDS/IPS-Ereignisse

Verteilte IDS/IPS-Ereignisse ergeben sich aus den NSX Manager- oder ESXi-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
CPU-Auslastung der NSX-IDPS-Engine ist sehr hoch	Kritisch	Die CPU-Nutzung der NSX-IDPS-Engine hat 95 % oder höher überschritten. Bei Erkennung des Ereignisses: „Die CPU-Nutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer oder gleich dem Schwellenwert für die sehr hohe Nutzung von 95 %.“ Bei Auflösung des Ereignisses: „Die CPU-Nutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und liegt damit unter dem Schwellenwert für die sehr hohe Nutzung von 95 %.“	Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.
NSX-IDPS-Engine ist inaktiv	Kritisch	NSX-IDPS wurde über eine NSX-Richtlinie aktiviert und IDPS-Regeln sind konfiguriert, die NSX-IDPS-Engine ist aber inaktiv. Bei Erkennung des Ereignisses: „NSX-IDPS wurde über eine NSX-Richtlinie aktiviert und IDPS-Regeln sind konfiguriert, die NSX-IDPS-Engine ist aber inaktiv.“ Bei Auflösung des Ereignisses: „Auf NSX-IDPS trifft einer der folgenden Fälle zu: 1. NSX IDPS ist über NSX Richtlinie deaktiviert. 2. Die NSX-IDPS-Engine ist aktiviert, die NSX-IDPS-Engine und vdpi sind aktiv und NSX IDPS wurde aktiviert, und IDPS-Regeln wurden über die NSX-Richtlinie konfiguriert.“	Überprüfen Sie in /var/log/nsx-idps/nsx-idps.log und /var/log/nsx-syslog.log, ob Fehler gemeldet wurden. Überprüfen Sie mithilfe des folgenden Befehls in der NSX-CLI, ob NSX Distributed IDPS den Status „Deaktiviert“ aufweist. get ids engine status Falls ja, starten Sie den Dienst über den folgenden Befehl in der NSX-CLI. /etc/init.d/nsx-idps start Überprüfen Sie mithilfe des folgenden Befehls in der NSX-CLI, ob nsx-vdpi ausgeführt wird. /etc/init.d/nsx-vdpi status Falls nicht, starten Sie den Dienst über den folgenden Befehl in der NSX-CLI. /etc/init.d/nsx-vdpi start
Die Arbeitsspeichernutzung der NSX-IDPS-Engine ist sehr hoch	Kritisch	Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat 95 % oder höher erreicht. Bei Erkennung des Ereignisses: „Die Arbeitsspeicher-Auslastung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und ist damit größer oder gleich dem Schwellenwert für die sehr hohe Auslastung von 95 %.“ Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung der NSX-IDPS-Engine hat {system_resource_usage} % erreicht und liegt unter dem Schwellenwert für die sehr hohe Nutzung von 95 %.“	Erwägen Sie, die Arbeitslasten der VM auf diesem Host erneut auf andere Hosts auszugleichen.

DNS-Ereignisse

DNS-Ereignisse stammen von den NSX Edge- und öffentlichen Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Weiterleitung inaktiv	Hoch	Eine DNS-Weiterleitung ist ausgefallen. Bei Erkennung des Ereignisses: „DNS-Weiterleitung {entity_id} wird nicht ausgeführt. Dies wirkt sich auf die angegebene DNS-Weiterleitung aus, die derzeit aktiviert ist.“ Bei Auflösung des Ereignisses: „Die DNS-Weiterleitung {entity_id} wird erneut ausgeführt.“	Rufen Sie den NSX-CLI-Befehl get dns-forwarders status auf, um zu überprüfen, ob die DNS-Weiterleitung den Status „inaktiv“ aufweist. Überprüfen Sie /var/log/syslog, um festzustellen, ob Fehler gemeldet wurden. Erfassen Sie ein Support-Paket und wenden Sie sich an das NSX-Supportteam.
Weiterleitung deaktiviert Hinweis: Alarm ist ab NSX-T Data Center 3.2 veraltet.	Niedrig	Eine DNS-Weiterleitung ist deaktiviert. Bei Erkennung des Ereignisses: „DNS-Weiterleitung {entity_id} ist deaktiviert. Bei Auflösung des Ereignisses: „Die DNS-Weiterleitung {entity_id} ist aktiviert.“	Rufen Sie den NSX-CLI-Befehl get dns-forwarders status auf, um zu überprüfen, ob die DNS-Weiterleitung den Status „deaktiviert“ aufweist. Verwenden Sie NSX-Richtlinien-API oder Manager-API, um die DNS-Weiterleitung zu aktivieren, die sich nicht im deaktivierten Zustand befinden sollte.

Edge-Ereignisse

Edge-Ereignisse treten auf, wenn für einige Konfigurationswerte des Edge-Transportknotens eine Nichtübereinstimmung zwischen NSX und der Edge-Appliance vorliegt.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Edge-Knoteneinstellungen stimmen nicht überein	Kritisch	Edge-Knoten-Einstellungen stimmen nicht überein. Bei Erkennung des Ereignisses: „Die Konfiguration der Einstellungen für den Edge-Knoten {entity_id} stimmt nicht mit der Konfiguration der Richtlinienabsicht überein. Die Edge-Knotenkonfiguration, die dem Benutzer in der Benutzeroberfläche oder der API angezeigt wird, ist nicht mit der realisierten Konfiguration identisch. Die realisierten Edge-Knotenänderungen, die vom Benutzer außerhalb von NSX Manager vorgenommen wurden, werden in den Details dieses Alarms angezeigt, und alle Bearbeitungen in der Benutzeroberfläche oder API überschreiben die realisierte Konfiguration. Felder, die sich für den Edge-Knoten unterscheiden, werden in den Laufzeitdaten aufgelistet.“ Bei Auflösung des Ereignisses: „Die Knoteneinstellungen von Edge-Knoten {entity_id} stimmen jetzt mit der Richtlinienabsicht überein.“	Überprüfen Sie die Knoteneinstellungen dieses Edge-Transportknotens {entity_id}. Führen Sie zum Auflösen des Alarms eine der folgenden Aktionen aus. Aktualisieren Sie die Richtlinienabsicht für die Edge-Transportknoteneinstellung manuell mithilfe der API PUT https://<manager-ip>/api/v1/transport-nodes/<tn-id>. Akzeptieren Sie absichtsbasierte oder realisierte Edge-Knoteneinstellungen für diesen Edge-Transportknoten über den Edge-Transportknoten-Resolver. Akzeptieren Sie die Konfiguration der Edge-Knoteneinstellungen mithilfe von refresh API POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=refresh_node_configuration&resource_type=EdgeNode.
vSphere-Einstellungen der Edge-VM stimmen nicht überein	Kritisch	vSphere-Einstellungen der Edge-VM stimmen nicht überein. Bei Erkennung des Ereignisses: „Die Konfiguration des Edge-Knotens {entity_id} auf vSphere stimmt nicht mit der Konfiguration der Richtlinienabsicht überein. Die Edge-Knotenkonfiguration, die dem Benutzer in der Benutzeroberfläche oder der API angezeigt wird, ist nicht mit der realisierten Konfiguration identisch. Die realisierten Edge-Knotenänderungen, die vom Benutzer außerhalb von NSX Manager vorgenommen wurden, werden in den Details dieses Alarms angezeigt, und alle Bearbeitungen in der Benutzeroberfläche oder API überschreiben die realisierte Konfiguration. Felder, die sich für den Edge-Knoten unterscheiden, werden in den Laufzeitdaten aufgelistet.“ Bei Auflösung des Ereignisses: „Die vSphere-Einstellungen der VM von Edge-Knoten {entity_id} stimmen jetzt mit der Richtlinienabsicht überein.“	Überprüfen Sie die vSphere-Konfiguration dieses Edge-Transportknotens {entity_id}. Führen Sie zum Auflösen des Alarms eine der folgenden Aktionen aus. Akzeptieren Sie die absichtsbasierte oder vSphere-realisierte Edge-Knotenkonfiguration für diesen Edge-Transportknoten über den Edge-Transportknoten-Resolver. Lösen Sie den Alarm auf, indem Sie die vSphere-realisierte Konfiguration des Edge-Knotens mithilfe von refresh API POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=refresh_node_configuration&resource_type=EdgeNode akzeptieren.
Edge-Knoteneinstellungen und vSphere-Einstellungen werden geändert	Kritisch	Edge-Knoten- und vSphere-Einstellungen werden geändert. Bei Erkennung des Ereignisses: „Die Einstellungen und die vSphere-Konfiguration für den Edge-Knoten {entity_id} werden geändert und stimmen nicht mit der Konfiguration der Richtlinienabsicht überein. Die Edge-Knotenkonfiguration, die dem Benutzer in der Benutzeroberfläche oder der API angezeigt wird, ist nicht mit der realisierten Konfiguration identisch. Die realisierten Edge-Knotenänderungen, die vom Benutzer außerhalb von NSX Manager vorgenommen wurden, werden in den Details dieses Alarms angezeigt, und alle Bearbeitungen in der Benutzeroberfläche oder API überschreiben die realisierte Konfiguration. Felder, die sich für Edge-Knoteneinstellungen und vSphere-Konfiguration unterscheiden, werden in den Laufzeitdaten aufgeführt.“ Bei Auflösung des Ereignisses: „Die Knoteneinstellungen und die vSphere-Einstellungen von Edge-Knoten {entity_id} stimmen jetzt mit der Richtlinienabsicht überein.“	Überprüfen Sie die Knoteneinstellungen und die vSphere-Konfiguration dieses Edge-Transportknotens {entity_id}. Führen Sie zum Auflösen des Alarms eine der folgenden Aktionen aus. Aktualisieren Sie die Richtlinienabsicht für die Edge-Transportknoteneinstellung manuell mithilfe der API PUT https://<manager-ip>/api/v1/transport-nodes/<tn-id>. Akzeptieren Sie die absichtsbasierte oder vSphere-realisierte Edge-Knotenkonfiguration oder die realisierten Edge-Knoteneinstellungen für diesen Edge-Transportknoten über den Edge-Transportknoten-Resolver. Akzeptieren Sie die Edge-Knoteneinstellungen und die vSphere-realisierte Konfiguration mithilfe von refresh API POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=refresh_node_configuration&resource_type=EdgeNode.
Nichtübereinstimmung bei Edge-vSphere-Speicherort	Hoch	Nichtübereinstimmung bei Edge-vSphere-Speicherort. Bei Erkennung des Ereignisses: „Der Edge-Knoten {entity_id} wurde mithilfe von vMotion verschoben. Die Konfiguration des Edge-Knotens {entity_id} auf vSphere stimmt nicht mit der Konfiguration der Richtlinienabsicht überein. Die Edge-Knotenkonfiguration, die dem Benutzer in der Benutzeroberfläche oder der API angezeigt wird, ist nicht mit der realisierten Konfiguration identisch. Die realisierten Änderungen am Edge-Knoten, die vom Benutzer außerhalb von NSX Manager vorgenommen wurden, werden in den Details dieses Alarms angezeigt. Felder, die sich für den Edge-Knoten unterscheiden, werden in den Laufzeitdaten aufgelistet.“ Bei Auflösung des Ereignisses: „Die vSphere-Knoteneinstellungen von Edge-Knoten {entity_id} stimmen jetzt mit der Richtlinienabsicht überein.“	Überprüfen Sie die vSphere-Konfiguration dieses Edge-Transportknotens {entity_id}. Führen Sie zum Auflösen des Alarms eine der folgenden Aktionen aus. Akzeptieren Sie die vSphere-realisierte Konfiguration des Edge-Knotens mithilfe von refresh API POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=refresh_node_configuration&resource_type=EdgeNode. Wenn Sie zum vorherigen Speicherort zurückkehren möchten, verwenden Sie die NSX Redeploy API POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=redeploy. vMotion zurück zum ursprünglichen Host wird nicht unterstützt.

Edge-Integritätsereignisse

Edge-Integritätsereignisse stammen von den NSX Edge- und öffentlichen Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Edge-CPU-Auslastung sehr hoch	Kritisch	Die CPU-Auslastung durch den Edge-Knoten ist sehr hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Überprüfen Sie die Konfiguration, die Ausführung von Diensten und die Dimensionierung dieses Edge-Knotens. Sie sollten für die jeweilige Arbeitslast eine Anpassung der Formfaktorgröße der Edge-Appliance oder die Neuverteilung von Diensten auf andere Edge-Knoten in Erwägung ziehen.
Edge-CPU-Nutzung hoch	Mittel	Die CPU-Auslastung durch den Edge-Knoten ist hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Überprüfen Sie die Konfiguration, die Ausführung von Diensten und die Dimensionierung dieses Edge-Knotens. Sie sollten für die jeweilige Arbeitslast eine Anpassung der Formfaktorgröße der Edge-Appliance oder die Neuverteilung von Diensten auf andere Edge-Knoten in Erwägung ziehen.
Konfigurationsfehler bei Edge-Datenpfad	Hoch	Die Konfiguration des Edge-Knoten-Datenpfads ist fehlgeschlagen. Bei Erkennung des Ereignisses: „Aktivieren des Datenpfads auf dem Edge-Knoten nach drei Versuchen fehlgeschlagen.“ Bei Auflösung des Ereignisses: „Datenpfad auf dem Edge-Knoten wurde erfolgreich aktiviert.“	Stellen Sie sicher, dass die Edge-Knoten-Verbindung zum Manager-Knoten fehlerfrei ist. Rufen Sie über die NSX-CLI des Edge-Knotens den Befehl get services auf, um die Integrität der Dienste zu überprüfen. Wenn der Dienst für die Datenebene angehalten wurde, rufen Sie den Befehl start service dataplane auf, um ihn neu zu starten.
CPU-Nutzung des Edge-Datenpfads ist sehr hoch	Kritisch	Die CPU-Auslastung durch den Edge-Knoten-Datenpfad ist sehr hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Datenpfads auf dem Edge-Knoten {entity-id} hat mindestens zwei Minuten lang {datapath_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Datenpfads auf dem Edge-Knoten {entity-id} wurde verringert und befindet sich nun unter dem maximalen Schwellenwert.“	Überprüfen Sie die CPU-Statistiken auf dem Edge-Knoten, indem Sie den NSX-CLI-Befehl get dataplane cpu stats aufrufen, um Paketsätze pro CPU-Kern anzuzeigen. Bei höheren Paketraten wird eine höhere CPU-Auslastung erwartet. Ziehen Sie eine Erhöhung der Formfaktorgröße der Edge-Appliance und eine Neuverteilung der Dienste auf diesem Edge-Knoten auf andere Edge-Knoten im selben Cluster oder auf andere Edge-Cluster in Erwägung.
Edge-Datenpfad-CPU-Auslastung hoch	Mittel	Die CPU-Auslastung durch den Edge-Knoten-Datenpfad ist hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung des Datenpfads auf dem Edge-Knoten {entity-id} hat mindestens zwei Minuten lang {datapath_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Edge-Knoten {entity-id} liegt nun unter dem hohen Schwellenwert.“	Überprüfen Sie die CPU-Statistiken auf dem Edge-Knoten, indem Sie den NSX-CLI-Befehl get dataplane cpu stats aufrufen, um Paketsätze pro CPU-Kern anzuzeigen. Bei höheren Paketraten wird eine höhere CPU-Auslastung erwartet. Ziehen Sie eine Erhöhung der Formfaktorgröße der Edge-Appliance und eine Neuverteilung der Dienste auf diesem Edge-Knoten auf andere Edge-Knoten im selben Cluster oder auf andere Edge-Cluster in Erwägung.
Edge-Datenpfad-Cryptodrv inaktiv	Kritisch	Crypto-Treiber des Edge-Knotens ist inaktiv Bei Erkennung des Ereignisses: „Der Crypto-Treiber {edge_crypto_drv_name} des Edge-Knotens ist inaktiv.“ Bei Auflösung des Ereignisses: „Der Crypto-Treiber des Edge-Knotens {edge_crypto_drv_name} ist aktiv.“	Aktualisieren Sie den Edge-Knoten nach Bedarf.
Edge-Datenpfad-Mempool hoch	Mittel	Der Mempool des Edge-Knoten-Datenpfads ist hoch. Bei Erkennung des Ereignisses: „Die Datenpfad-Mempool-Nutzung für {mempool_name} auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Datenpfad-Mempool-Nutzung für {mempool_name} auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Melden Sie sich als Root-Benutzer an und rufen Sie die Befehle edge-appctl -t /var/run/vmware/edge/dpd.ctl mempool/show und edge-appctl -t /var/run/vmware/edge/dpd.ctl memory/show malloc_heap auf, um die DPDK-Arbeitsspeicherauslastung zu prüfen.
Edge-Festplattennutzung sehr hoch	Kritisch	Die Festplattennutzung des Edge-Knotens ist sehr hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Edge-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Edge-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Untersuchen Sie die Partition mit hoher Auslastung und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
Edge-Festplattennutzung hoch	Mittel	Die Festplattennutzung des Edge-Knotens ist hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Edge-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Edge-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Untersuchen Sie die Partition mit hoher Auslastung und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
Globale Edge-ARP-Tabellennutzung hoch	Mittel	Die globale ARP-Tabellennutzung des Edge-Knotens ist hoch. Bei Erkennung des Ereignisses: „Die globale ARP-Tabellennutzung auf dem Edge-Knoten {entity-id} hat mehr als zwei Minuten lang {datapath_resource_usage} % erreicht und liegt damit über dem Schwellenwert für eine hohe Nutzung.“ Bei Auflösung des Ereignisses: „Die globale ARP-Tabellennutzung auf dem Edge-Knoten {entity-id} liegt jetzt unter dem Schwellenwert für eine hohe Nutzung.“	Melden Sie sich als Root-Benutzer an und rufen Sie den folgenden Befehl auf, um zu überprüfen, ob die Nutzung des Nachbar-Caches normal ist. edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show Wenn sie normal ist, rufen Sie den folgenden Befehl auf, um die ARP-Tabelle zu vergrößern. edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries
Edge-Arbeitsspeichernutzung sehr hoch	Kritisch	Die Arbeitsspeichernutzung des Edge-Knotens ist sehr hoch. Bei Erkennung des Ereignisses: „Die Arbeitsspeicherauslastung auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Arbeitsspeicherauslastung auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Überprüfen Sie die Konfiguration, die Ausführung von Diensten und die Dimensionierung dieses Edge-Knotens. Sie sollten für die jeweilige Arbeitslast eine Anpassung der Formfaktorgröße der Edge-Appliance oder die Neuverteilung von Diensten auf andere Edge-Knoten in Erwägung ziehen.
Edge-Arbeitsspeichernutzung hoch	Mittel	Die Arbeitsspeichernutzung des Edge-Knotens ist hoch. Bei Erkennung des Ereignisses: „Die Arbeitsspeicherauslastung auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Arbeitsspeicherauslastung auf dem Edge-Knoten {entity-id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Überprüfen Sie die Konfiguration, die Ausführung von Diensten und die Dimensionierung dieses Edge-Knotens. Sie sollten für die jeweilige Arbeitslast eine Anpassung der Formfaktorgröße der Edge-Appliance oder die Neuverteilung von Diensten auf andere Edge-Knoten in Erwägung ziehen.
Verbindungsstatus der Edge-Netzwerkkarte ist inaktiv	Kritisch	Verbindung der Netzwerkkarte des Edge-Knotens ist ausgefallen. Bei Erkennung des Ereignisses: „Verbindung der Edge-Knoten-Netzwerkkarte {edge_nic_name} ist inaktiv.“ Bei Erkennung des Ereignisses: „Verbindung der Edge-Knoten-Netzwerkkarte {edge_nic_name} ist aktiv.“	Bestätigen Sie auf dem Edge-Knoten, dass die Verbindung der Netzwerkkarte physisch inaktiv ist, indem Sie den NSX-CLI-Befehl get interfaces aufrufen. Wenn Sie inaktiv ist, überprüfen Sie die Kabelverbindung.
Empfangspuffer der Edge-Netzwerkkarte überschritten	Mittel	Die Netzwerkkarte des Edge-Knotens hat vorübergehend keine RX-Ringpuffer mehr. Bei Erkennung des Ereignisses: „Der Empfangs-Ringpuffer der Edge-Netzwerkkarte {edge_nic_name} wurde auf dem Edge-Knoten {entity_id} um {rx_ring_buffer_overflow_percentage} % überschritten. Die Anzahl der verpassten Pakete ist {rx_misses} und die Anzahl der verarbeiteten Pakete ist {rx_processed}.“ Bei Auflösung des Ereignisses: „Die Empfangs-Ringpuffernutzung der Edge-NIC {edge_nic_name} auf dem Edge-Knoten {entity_id} wird nicht mehr überschritten.“	Führen Sie den NSX-CLI-Befehl get dataplane cpu stats auf dem Edge-Knoten aus und überprüfen Sie Folgendes: Wenn die CPU-Nutzung hoch (> 90 %) ist, führen Sie eine Paketerfassung auf der Schnittstelle mithilfe des Befehls start capture interface <interface-name> direction input oder start capture interface <interface-name> direction input core <core-id> durch (um Pakete zu erfassen, die auf einem bestimmten Kern eingehen, dessen Nutzung hoch ist). Analysieren Sie dann die Erfassung, um zu überprüfen, ob die meisten fragmentierten Pakete oder IPSec-Pakete vorhanden sind. Wenn ja, handelt es sich um das erwartete Verhalten. Andernfalls ist der Datenpfad wahrscheinlich mit anderen Vorgängen beschäftigt. Wenn dieser Alarm länger als 2–3 Minuten dauert, wenden Sie sich an VMware Support. 2. Wenn die CPU-Nutzung nicht hoch (< 90 %) ist, überprüfen Sie mithilfe des Befehls get dataplane cpu stats, ob RX PPS hoch ist (um sicherzustellen, dass die Datenverkehrsrate zunimmt). Erhöhen Sie dann die Ringgröße mithilfe des Befehls set dataplane ring-size rx <ring-size> um 1024. Hinweis: Die kontinuierliche Erhöhung der Ringgröße um den Faktor 1024 kann zu einigen Leistungsproblemen führen. Wenn das Problem auch nach der Erhöhung der Ringgröße weiterhin besteht, ist dies ein Hinweis darauf, dass Edge für den Datenverkehr eine größere Formfaktorbereitstellung benötigt. Wenn der Alarm weiterhin schwankt, d. h. ausgelöst und schnell wieder aufgelöst wird, dann liegt dies an stoßartigem Datenverkehr. Überprüfen Sie in diesem Fall RX PPS, wie oben beschrieben. Wenn RX PPS während des aktiven Alarms nicht hoch ist, wenden Sie sich an den VMware Support. Wenn PPS hoch ist, bestätigt dies den stoßartigen Datenverkehr. Ziehen Sie in Betracht, den Alarm zu unterdrücken. Hinweis: Es gibt keinen spezifischen Vergleichsindex, um zu entscheiden, was als hoher PPS-Wert angesehen wird. Dies hängt von der Infrastruktur und der Art des Datenverkehrs ab. Der Vergleich kann anhand von Notizen bei inaktivem und aktivem Alarm erfolgen.
Übertragungspuffer der Edge-Netzwerkkarte überschritten	Kritisch	Die Netzwerkkarte des Edge-Knotens hat vorübergehend keine TX-Ringpuffer mehr. Bei Erkennung des Ereignisses: „Der Übertragungs-Ringpuffer der Edge-Netzwerkkarte {edge_nic_name} wurde auf dem Edge-Knoten {entity_id} um {tx_ring_buffer_overflow_percentage} % überschritten. Die Anzahl der verpassten Pakete ist {tx_misses} und die Anzahl verarbeiteter Pakete ist {tx_processed}.“ Bei Auflösung des Ereignisses: „Die Übertragungs-Ringpuffernutzung der Edge-NIC {edge_nic_name} auf dem Edge-Knoten {entity_id} wird nicht mehr überschritten.“	Wenn viele VMs zusammen mit Edge durch den Hypervisor untergebracht werden, kann die Edge-VM möglicherweise nicht ausgeführt werden. Daher werden die Pakete möglicherweise nicht vom Hypervisor abgerufen. Ziehen Sie dann in Betracht, die Edge-VM auf einen Host mit weniger VMs zu migrieren. Erhöhen Sie die Ringgröße mithilfe des Befehls set dataplane ring-size tx <ring-size> um 1024. Wenn das Problem auch nach dem Erhöhen der Ringgröße weiterhin besteht, wenden Sie sich an den VMware Support, da der Übertragungs-Ringpuffer für die ESX-Seite möglicherweise einen niedrigeren Wert aufweist. Wenn es kein Problem auf ESX-Seite gibt, deutet dies darauf hin, dass der Edge auf eine Bereitstellung mit einem größeren Formfaktor skaliert werden muss, um dem Datenverkehr gerecht zu werden. Wenn der Alarm weiterhin schwankt, d. h. ausgelöst und schnell wieder aufgelöst wird, dann liegt dies an stoßartigem Datenverkehr. Überprüfen Sie TX PPS in diesem Fall mit dem Befehl get dataplane cpu stats. Wenn RX PPS während des aktiven Alarms nicht hoch ist, wenden Sie sich an den VMware Support. Wenn PPS hoch ist, bestätigt dies den stoßartigen Datenverkehr. Ziehen Sie in Betracht, den Alarm zu unterdrücken. Hinweis: Es gibt keinen spezifischen Vergleichsindex, um zu entscheiden, was als hoher PPS-Wert angesehen wird. Dies hängt von der Infrastruktur und der Art des Datenverkehrs ab. Der Vergleich kann anhand von Notizen bei inaktivem und aktivem Alarm erfolgen.
Speicherfehler	Kritisch	Ab NSX-T Data Center 3.0.1. Bei Erkennung des Ereignisses: „Die folgenden Festplattenpartitionen auf dem Edge-Knoten befinden sich im schreibgeschützten Modus: {disk_partition_name}.“ Bei Auflösung des Ereignisses: „Die folgenden Festplattenpartitionen auf dem Edge-Knoten befinden sich nicht mehr im schreibgeschützten Modus: {disk_partition_name}.“	Untersuchen Sie die schreibgeschützte Partition, um festzustellen, ob ein Neustart das Problem behebt oder die Festplatte ersetzt werden muss. Weitere Informationen erhalten Sie von GSS.
Edge-Datenpfad-NIC-Durchsatz hoch	Mittel	Der NIC-Durchsatz durch den Edge-Knoten-Datenpfad ist hoch. Bei Erkennung des Ereignisses: „Der Datenpfad-Netzwerkkarten-Durchsatz für {edge_nic_name} auf dem Edge-Knoten {entity_id} hat {nic_throughput} % erreicht und ist damit größer oder gleich dem Schwellenwert für hohen Durchsatz von {nic_throughput_threshold} %.“ Bei Auflösung des Ereignisses: „Der Datenpfad-NIC-Durchsatz für {edge_nic_name} auf dem Edge-Knoten {entity_id} hat {nic_throughput} % erreicht und liegt damit unter dem Schwellenwert für hohen Durchsatz von {nic_throughput_threshold} %.“	Untersuchen Sie die Durchsatzwerte des Datenverkehrs auf der Netzwerkkarte und ermitteln Sie, ob Konfigurationsänderungen erforderlich sind. Führen Sie den folgenden Befehl aus, um den Durchsatz zu überwachen. get dataplane throughput <seconds>
Edge-Datenpfad-NIC-Durchsatz sehr hoch	Kritisch	Der NIC-Durchsatz durch den Edge-Knoten-Datenpfad ist sehr hoch. Bei Erkennung des Ereignisses: „Der Datenpfad-NIC-Durchsatz für {edge_nic_name} auf dem Edge-Knoten {entity_id} hat {nic_throughput} % erreicht und ist damit größer oder gleich dem Schwellenwert für sehr hohen Durchsatz von {nic_throughput_threshold} %.“ Bei Auflösung des Ereignisses: „Der Datenpfad-NIC-Durchsatz für {edge_nic_name} auf dem Edge-Knoten {entity_id} hat {nic_throughput} % erreicht und liegt damit unter dem Schwellenwert für sehr hohen Durchsatz von {nic_throughput_threshold} %.“	Untersuchen Sie die Durchsatzwerte des Datenverkehrs auf der Netzwerkkarte und ermitteln Sie, ob Konfigurationsänderungen erforderlich sind. Rufen Sie den folgenden NSX-CLI-Befehl auf, um den Durchsatz zu überwachen. get dataplane throughput <seconds>
Fehlerdomäne nicht verfügbar	Kritisch	Alle Mitglieder der Fehlerdomäne sind nicht verfügbar. Bei Erkennung des Ereignisses: „Alle Mitglieder der Fehlerdomäne {transport_node_id} sind inaktiv.“ Bei Auflösung des Ereignisses: „Alle Mitglieder der Fehlerdomäne {transport_node_id} sind erreichbar.“	Überprüfen Sie auf dem durch {transport_node_id} identifizierten Edge-Knoten die Konnektivität zu Verwaltungs- und Steuerungsebenen, indem Sie den folgenden NSX-CLI-Befehl aufrufen. get managers und get controllers Rufen Sie den folgenden NSX-CLI-Befehl auf, um den Status der Verwaltungsschnittstelle zu überprüfen. get interface eth0 Rufen Sie die folgende NSX-CLI auf, um den Status der Kerndienste wie dataplane/local-controller/nestdb/router usw. zu überprüfen. get services Überprüfen Sie das /var/log/syslog, um den vermuteten Fehler zu finden. Starten Sie den Edge-Knoten neu.
Datenpfad-Thread im Deadlock	Kritisch	Der Datenpfad-Thread des Edge-Knotens weist eine Deadlock-Bedingung auf. Bei Erkennung des Ereignisses: „Der Datenpfad-Thread {edge_thread_name} des Edge-Knotens weist einen Deadlock auf.“ Bei Auflösung des Ereignisses: „Der Datenpfad-Thread {edge_thread_name} des Edge-Knotens weist keinen Deadlock auf.“	Starten Sie den Dienst für die Datenebene neu, indem Sie den folgenden NSX-CLI-Befehl aufrufen. restart service dataplane

Ereignisse für Endpoint-Schutz

Endpoint-Schutzereignisse stammen von den NSX Manager- oder ESXi-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
EAM-Status nicht verfügbar	Kritisch	Der ESX Agent Manager (EAM)-Dienst auf einem Compute Manager ist nicht verfügbar. Bei Erkennung des Ereignisses: „Der ESX Agent Manager(EAM)-Dienst auf Compute Manager {entity_id} ist nicht verfügbar.“ Bei Auflösung des Ereignisses: „ Der ESX Agent Manager(EAM)-Dienst auf Compute Manager {entity_id} ist entweder verfügbar oder Compute Manager {entity_id} wurde entfernt.“	Starten Sie den ESX Agent Manager(EAM)-Dienst neu: SSH im vCenter-Knoten und ausführen: service vmware-eam start
Partnerkanal nicht verfügbar	Kritisch	Die Verbindung zwischen Host-Modul und Partner-SVM ist ausgefallen. Bei Erkennung des Ereignisses: „Die Verbindung zwischen dem Host-Modul und der Partner-SVM {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Die Verbindung zwischen dem Host-Modul und der Partner-SVM {entity_id} ist aktiv.“	Schlagen Sie im Knowledgebase-Artikel 2148821 Fehlerbehebung für NSX Guest Introspection nach und stellen Sie sicher, dass die von {entity_id} ermittelte SVM erneut mit dem Host-Modul verbunden wird.

Gateway-Firewall-Ereignisse

Gateway-Firewalls-Ereignisse stammen aus NSX Edge-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Anzahl der ICMP-Flows überschritten	Kritisch	Ab NSX-T Data Center 3.1.3 Die Flow-Tabelle der Gateway-Firewall für ICMP-Datenverkehr hat den festgelegten Schwellenwert überschritten. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für ICMP-Datenverkehr auf logischem Router {entity_id} hat {firewall_icmp_flow_usage} % erreicht und entspricht damit dem hohen Schwellenwert von {system_usage_threshold} % bzw. überschreitet diesen. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.“ Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall auf dem logischen Router {entity_id} liegt unterhalb des Schwellenwerts für hohe Auslastung von {system_usage_threshold} %.“	Melden Sie sich als Administrator beim Edge-Knoten an und rufen Sie den folgenden NSX CLI-Befehl mithilfe der richtigen Schnittstellen-UUID auf und überprüfen Sie die Nutzung der Flow-Tabelle für ICMP-Flows. get firewall <LR_INT_UUID> interface stats | json Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist. Wenn der Datenverkehr innerhalb der normalen Last zu liegen scheint, aber der Alarmschwellenwert erreicht ist, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.
Anzahl der ICMP-Flows hoch	Mittel	Ab NSX-T Data Center 3.1.3 Die Auslastung der Flow-Tabelle der Gateway-Firewall für ICMP-Datenverkehr ist hoch. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für ICMP auf logischem Router {entity_id} hat {firewall_icmp_flow_usage} % erreicht und entspricht damit dem hohen Schwellenwert von {system_usage_threshold} % bzw. überschreitet diesen. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.“ Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für ICMP auf logischem Router {entity_id} liegt unterhalb des hohen Schwellenwerts von {system_usage_threshold} %.“	Melden Sie sich als Administrator beim Edge-Knoten an und rufen Sie den folgenden NSX CLI-Befehl mithilfe der richtigen Schnittstellen-UUID auf und überprüfen Sie die Nutzung der Flow-Tabelle für ICMP-Flows. get firewall <LR_INT_UUID> interface stats | json Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist. Wenn der Datenverkehr innerhalb der normalen Last zu liegen scheint, aber der Alarmschwellenwert erreicht ist, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.
Anzahl der IP-Flows überschritten	Kritisch	Ab NSX-T Data Center 3.1.3 Die Flow-Tabelle der Gateway-Firewall für IP-Datenverkehr hat den festgelegten Schwellenwert überschritten. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für IP-Datenverkehr auf logischem Router {entity_id} hat {firewall_ip_flow_usage} % erreicht und entspricht damit dem hohen Schwellenwert von {system_usage_threshold} % bzw. überschreitet diesen. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.“ Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall auf logischem Router {entity_id} liegt unterhalb des hohen Schwellenwerts von {system_usage_threshold} %.“	Melden Sie sich als Administrator beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl mithilfe der richtigen Schnittstellen-UUID auf und überprüfen Sie die Nutzung der Flow-Tabelle für IP-Flows. get firewall <LR_INT_UUID> interface stats | json Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist. Wenn der Datenverkehr innerhalb der normalen Last zu liegen scheint, aber der Alarmschwellenwert erreicht ist, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.
Anzahl der IP-Flows hoch	Mittel	Ab NSX-T Data Center 3.1.3 Die Auslastung der Flow-Tabelle der Gateway-Firewall für IP-Datenverkehr ist hoch. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für IP auf logischem Router {entity_id} hat {firewall_ip_flow_usage} % erreicht und entspricht damit dem hohen Schwellenwert von {system_usage_threshold} % bzw. überschreitet diesen. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.“ Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für Nicht-IP-Flows auf logischem Router {entity_id} liegt unterhalb des hohen Schwellenwerts von {system_usage_threshold} %.“	Melden Sie sich als Administrator beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl mithilfe der richtigen Schnittstellen-UUID auf und überprüfen Sie die Nutzung der Flow-Tabelle für IP-Flows. get firewall <LR_INT_UUID> interface stats | json Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist. Wenn der Datenverkehr innerhalb der normalen Last zu liegen scheint, aber der Alarmschwellenwert erreicht ist, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.
Anzahl der TCP-Flows überschritten	Kritisch	Ab NSX-T Data Center 3.1.3 Die Flow-Tabelle der Gateway-Firewall für halb offenen TCP-Datenverkehr hat den festgelegten Schwellenwert überschritten. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. Bei Erkennung des Ereignisses: „Auslastung der Flow-Tabelle der Gateway-Firewall für halb offenen TCP-Datenverkehr auf logischem Router {entity_id} hat {firewall_halfopen_flow_usage} % erreicht und entspricht damit dem hohen Schwellenwert von {system_usage_threshold} % bzw. überschreitet diesen. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.“ Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall auf logischem Router {entity_id} liegt unterhalb des hohen Schwellenwerts von {system_usage_threshold} %.“	Melden Sie sich als Administrator beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl mithilfe der richtigen Schnittstellen-UUID auf und überprüfen Sie die Nutzung der Flow-Tabelle für halb offene TCP-Flows. get firewall <LR_INT_UUID> interface stats | json Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist. Wenn der Datenverkehr innerhalb der normalen Last zu liegen scheint, aber der Alarmschwellenwert erreicht ist, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.
Anzahl der TCP-Flows hoch	Mittel	Ab NSX-T Data Center 3.1.3 Die Auslastung der Flow-Tabelle der Gateway-Firewall für halb offenen TCP-Datenverkehr ist hoch. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für TCP auf logischem Router {entity_id} hat {firewall_halfopen_flow_usage} % erreicht und entspricht damit dem hohen Schwellenwert von {system_usage_threshold} % bzw. überschreitet diesen. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.“ Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für halb offenen TCP-Datenverkehr auf logischem Router {entity_id} liegt unterhalb des hohen Schwellenwerts von {system_usage_threshold} %.“	Melden Sie sich als Administrator beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl mithilfe der richtigen Schnittstellen-UUID auf und überprüfen Sie die Nutzung der Flow-Tabelle für halb offene TCP-Flows. get firewall <LR_INT_UUID> interface stats | json Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist. Wenn der Datenverkehr innerhalb der normalen Last zu liegen scheint, aber der Alarmschwellenwert erreicht ist, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.
Anzahl der UDP-Flows überschritten	Kritisch	Ab NSX-T Data Center 3.1.3 Die Flow-Tabelle der Gateway-Firewall für UDP-Datenverkehr hat den festgelegten Schwellenwert überschritten. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für UDP-Datenverkehr auf logischem Router {entity_id} hat {firewall_udp_flow_usage} % erreicht und entspricht damit dem hohen Schwellenwert von {system_usage_threshold} % bzw. überschreitet diesen. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.“ Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall auf logischem Router {entity_id} liegt unterhalb des hohen Schwellenwerts.“	Melden Sie sich als Administrator beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl mithilfe der richtigen Schnittstellen-UUID auf und überprüfen Sie die Nutzung der Flow-Tabelle für UDP-Flows. get firewall <LR_INT_UUID> interface stats | json Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist. Wenn der Datenverkehr innerhalb der normalen Last zu liegen scheint, aber der Alarmschwellenwert erreicht ist, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.
Anzahl der UDP-Flows hoch	Mittel	Ab NSX-T Data Center 3.1.3 Die Auslastung der Flow-Tabelle der Gateway-Firewall für UDP-Datenverkehr ist hoch. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht. Bei Erkennung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für UDP auf logischem Router {entity_id} hat {firewall_udp_flow_usage} % erreicht und entspricht damit dem hohen Schwellenwert von {system_usage_threshold} % bzw. überschreitet diesen. Neue Flows werden von der Gateway-Firewall verworfen, wenn die Nutzung den maximalen Grenzwert erreicht.“ Bei Auflösung des Ereignisses: „Die Auslastung der Flow-Tabelle der Gateway-Firewall für UDP auf logischem Router {entity_id} liegt unterhalb des hohen Schwellenwerts.“	Melden Sie sich als Administrator beim Edge-Knoten an und rufen Sie den NSX CLI-Befehl mithilfe der richtigen Schnittstellen-UUID auf und überprüfen Sie die Nutzung der Flow-Tabelle für UDP-Flows. get firewall <LR_INT_UUID> interface stats | json Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist. Wenn der Datenverkehr innerhalb der normalen Last zu liegen scheint, aber der Alarmschwellenwert erreicht ist, sollten Sie den Alarmschwellenwert erhöhen oder neuen Datenverkehr an einen anderen Edge-Knoten weiterleiten.

Hochverfügbarkeitsereignisse

Hochverfügbarkeitsereignisse stammen aus den Knoten NSX Edge-Knoten und den Public Cloud Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Tier0-Gateway-Failover	Hoch	Ein Tier0-Gateway hat ein Failover durchgeführt. Bei Erkennung des Ereignisses: „Für das Tier-0-Gateway {Entitäts-ID} wurde ein Failover von {previous_gateway_state} auf {current_gateway_state} vorgenommen.“ Bei Auflösung des Ereignisses: „Das Tier-0-Gateway {entity-id} ist jetzt aktiv.“	Rufen Sie den NSX-CLI-Befehl get logical-router <service_router_id> auf, um die VRF-ID des Tier-0-Dienstrouters abzurufen. Wechseln Sie zum VRF-Kontext, indem Sie erst vrf <vrf-id> und dann get high-availability status aufrufen, um den inaktiven Dienst zu ermitteln.
Tier1-Gateway-Failover	Hoch	Ein Tier-1-Gateway hat ein Failover durchgeführt. Bei Erkennung des Ereignisses: „Für das Tier-1-Gateway {entity_id} wurde ein Failover von {previous_gateway_state} auf {current_gateway_state}, Dienst-Router {service_router_id} vorgenommen.“ Bei Auflösung des Ereignisses: „Das Tier-1-Gateway {entity-id} ist jetzt aktiv.“	Rufen Sie den NSX-CLI-Befehl get logical-router <service_router_id> auf, um die VRF-ID des Tier-1-Dienstrouters abzurufen. Wechseln Sie zum VRF-Kontext, indem Sie erst vrf <vrf-id> und dann get high-availability status aufrufen, um den inaktiven Dienst zu ermitteln.

Ereignisse der identitätsbasierten Firewall

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Verbindung mit LDAP-Server ist unterbrochen	Kritisch	Die Verbindung zum LDAP-Server ist unterbrochen. Bei Erkennung des Ereignisses: „Die Verbindung zum LDAP-Server {ldap_server} ist unterbrochen.“ Bei Erkennung des Ereignisses: „Die Verbindung zum LDAP-Server {ldap_server} ist wiederhergestellt.“	Führen Sie die folgenden Schritte aus, um die Verbindung zum LDAP-Server zu überprüfen: Der LDAP-Server ist von NSX-Knoten aus erreichbar. Die LDAP-Serverdetails sind korrekt in NSX konfiguriert. Der LDAP-Server wird ordnungsgemäß ausgeführt. Der Zugriff zwischen dem LDAP-Server und NSX-Knoten wird nicht durch Firewalls blockiert. Nachdem das Problem behoben wurde, verwenden Sie in der NSX-Benutzeroberfläche unter „Identitäts-Firewall-AD“ VERBINDUNG TESTEN, um die Verbindung zu testen.
Fehler bei der Delta-Synchronisierung	Kritisch	Beim Ausführen der Deltasynchronisierung sind Fehler aufgetreten. Bei Erkennung des Ereignisses: „Beim Ausführen der Deltasynchronisierung mit {directory_domain} sind Fehler aufgetreten.“ Bei Erkennung des Ereignisses: „Beim Ausführen der Deltasynchronisierung mit {directory_domain} sind keine Fehler aufgetreten.“	Überprüfen Sie, ob Alarme vorliegen, die sich auf die Unterbrechung der Verbindung zum LDAP-Server beziehen. Suchen Sie die Fehlerdetails in /var/log/syslog. Suchen Sie im Bereich des Alarmzeitpunkts nach dem Text: „Fehler beim Synchronisieren von LDAP-Objekten“. Prüfen Sie mit dem AD-Administrator, ob kürzlich vorgenommene AD-Änderungen gegebenenfalls die Fehler verursachen können. Falls die Fehler weiterhin auftreten, speichern Sie das Paket für den technischen Support und wenden Sie sich an den VMware Support.

Infrastruktur-Kommunikationsereignisse

Infrastruktur-Kommunikationsereignisse stammen aus den NSX Edge-, KVM-, ESXi- und den öffentlichen Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Edge-Tunnel inaktiv	Kritisch	Der Tunnelstatus eines Edge-Knotens ist inaktiv. Bei Erkennung des Ereignisses: „Der Gesamttunnelstatus des Edge-Knotens {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Die Tunnel des Edge-Knotens {entity_id} wurden wiederhergestellt.“	Rufen Sie den folgenden NSX-CLI-Befehl auf, um alle Tunnel-Ports abzurufen. get tunnel-ports Überprüfen Sie dann die einzelnen Tunnel-Statistiken auf Abbrüche, indem Sie den folgenden NSX-CLI-Befehl aufrufen. get tunnel-port <UUID> stats Überprüfen Sie anschließend in /var/log/syslog, ob auf Tunnel bezogene Fehler vorhanden sind.

Nachrichten-Kommunikationsereignisse

NSX Intelligence-Kommunikationsereignisse stammen aus dem NSX Manager-Knoten, dem ESXi-Knoten und der NSX Intelligence-Appliance.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Transportknoten-Flow-Exporter getrennt	Hoch	Ein Transportknoten ist vom Messaging-Broker des Intelligence-Knotens getrennt. Die Datenerfassung ist davon betroffen. Bei Erkennung des Ereignisses: „Der Flow-Exporter auf dem Transportknoten {entity-id} wurde vom Messaging-Broker des Intelligence Knotens getrennt. Die Datenerfassung ist davon betroffen.“ Bei Auflösung des Ereignisses: „Der Flow-Exporter auf dem Transportknoten {entity-id} wurde erneut mit dem Messaging-Broker des Intelligence Knotens verbunden.	Starten Sie den Nachrichtendienst neu, wenn er nicht im NSX Intelligence-Knoten ausgeführt wird. Beheben Sie den Netzwerkverbindungsfehler zwischen dem Transportknoten und dem NSX Intelligence-Knoten.
Steuerungskanal zum Transportknoten inaktiv	Mittel	Die Verbindung des Controller-Diensts mit dem Transportknoten ist getrennt. Bei Erkennung des Ereignisses: „Der Controller-Dienst {appliance_address} ({central_control_plane_id}) auf dem Manager-Knoten zum Transportknoten {entity-id} ist aus Sicht des Controller-Diensts seit mindestens drei Minuten inaktiv.“ Bei Auflösung des Ereignisses: „Der Controller-Dienst auf dem Manager-Knoten {appliance_address} ({central_control_plane_id}) stellt die Verbindung zum Transportknoten {entity_id} wieder her.“	Überprüfen Sie die Konnektivität zwischen dem Controller-Dienst central_control_plane_id und der Schnittstelle des Transportknotens {entity-id} mit einem Ping-Befehl. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie die Netzwerkkonnektivität. Überprüfen Sie, ob die TCP-Verbindungen mithilfe der netstat-Ausgabe eingerichtet wurden, um festzustellen, ob der Controller-Dienst {central_control_plane_id} Port 1235 auf Verbindungen überwacht. Falls nicht, überprüfen Sie die Firewall- (oder) iptables-Regeln, um festzustellen, ob Port 1235 Verbindungsanfragen von Transportknoten {entity_id} blockiert. Stellen Sie sicher, dass keine Host- oder Netzwerk-Firewalls im Underlay vorhanden sind, die die erforderlichen IP-Ports zwischen den Manager- und Transportknoten blockieren. Dies ist in unserem Tool für Ports und Protokolle beschrieben: https://ports.vmware.com/. Es ist möglich, dass sich der Transportknoten {entity_id} noch im Wartungsmodus befindet. Sie können über die folgende API überprüfen, ob sich der Transportknoten im Wartungsmodus befindet: GET https://<nsx-mgr>/api/v1/transport-nodes/<tn-uuid> Wenn der Wartungsmodus festgelegt ist, wird der Transportknoten nicht mit dem Controller-Dienst verbunden. Dies ist in der Regel der Fall, wenn ein Upgrade des Hosts ausgeführt wird. Warten Sie einige Minuten und prüfen Sie die Konnektivität erneut. Hinweis: Dieser Alarm ist kritisch und sollte aufgelöst werden. Wenden Sie sich zur Meldung dieses Alarms an den VMware Support, wenn der Alarm über einen längeren Zeitraum ungelöst bleibt.
Steuerungskanal zum Transportknoten lange inaktiv	Kritisch	Die Verbindung des Controllers mit dem Transportknoten ist bereits zu lange getrennt. Bei Erkennung des Ereignisses: „Der Controller-Dienst {appliance_address} ({central_control_plane_id}) auf dem Manager-Knoten zum Transportknoten {entity-id} ist aus Sicht des Controller-Diensts seit mindestens 15 Minuten inaktiv.“ Bei Auflösung des Ereignisses: „Der Controller-Dienst auf dem Manager-Knoten {appliance_address} ({central_control_plane_id}) stellt die Verbindung zum Transportknoten {entity_id} wieder her.“	Überprüfen Sie die Konnektivität zwischen dem Controller-Dienst {central_control_plane_id} und der Schnittstelle des Transportknotens {entity_id} mittels Ping und Traceroute. Dies kann über die Admin-CLI des NSX Manager-Knotens durchgeführt werden. Der Ping-Test sollte keine Abbrüche und konsistente Latenzwerte aufweisen. VMware empfiehlt Latenzwerte von 150 ms oder weniger. Navigieren Sie in der NSX-Benutzeroberfläche zu System > Fabric > Knoten > Transportknoten {entity_id}, um zu überprüfen, ob die TCP-Verbindungen zwischen dem Controller-Dienst auf dem Manager-Knoten {appliance_address} ({central_control_plane_id}) und dem Transportknoten {entity_id} hergestellt wurden. Falls nicht, überprüfen Sie die Firewallregeln im Netzwerk und auf den Hosts, um festzustellen, ob Port 1235 die Verbindungsanfragen des Transportknotens {entity_id} blockiert. Stellen Sie sicher, dass keine Host- oder Netzwerk-Firewalls im Underlay vorhanden sind, die die erforderlichen IP-Ports zwischen Manager-Knoten und Transportknoten blockieren. Dies ist in unserem Tool für Ports und Protokolle beschrieben: https://ports.vmware.com/.
Steuerungskanal zum Manager-Knoten inaktiv	Mittel	Die Control Plane-Verbindung des Transportknotens mit dem Manager-Knoten ist inaktiv. Bei Erkennung des Ereignisses: „Die Control Plane-Verbindung des Transportknotens {entity_id} mit dem Manager-Knoten {appliance_address} ist aus der Sicht des Transportknotens seit mindestens {timeout_in_minutes} Minuten inaktiv.“ Bei Auflösung des Ereignisses: „Der Transportknoten {entity_id} stellt die Control Plane-Verbindung mit dem Manager-Knoten {appliance_address} wieder her.“	Überprüfen Sie die Konnektivität des Transportknotens {entity_id} mit der Schnittstelle des Manager-Knotens {appliance_address} per Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im Netzwerk beeinträchtigt ist. Überprüfen Sie, ob die TCP-Verbindungen mithilfe der netstat-Ausgabe eingerichtet wurden, um festzustellen, ob der Controller-Dienst auf dem Manager-Knoten {appliance_address} Port 1235 auf Verbindungen überwacht. Falls nicht, überprüfen Sie die Firewall- (oder) iptables-Regeln, um festzustellen, ob Port 1235 Verbindungsanfragen von Transportknoten {entity_id} blockiert. Stellen Sie sicher, dass keine Host- oder Netzwerk-Firewalls im Underlay vorhanden sind, die die erforderlichen IP-Ports zwischen Manager-Knoten und Transportknoten blockieren. Dies ist in unserem Tool für Ports und Protokolle beschrieben: https://ports.vmware.com/. Es ist möglich, dass sich der Transportknoten {entity_id} noch im Wartungsmodus befindet. Über die folgende API können Sie überprüfen, ob sich der Transportknoten im Wartungsmodus befindet: GET https://<nsx-mgr>/api/v1/transport-nodes/<tn-uuid> Wenn der Wartungsmodus festgelegt ist, wird der Transportknoten nicht mit dem Controller-Dienst verbunden. Dies ist in der Regel der Fall, wenn ein Upgrade des Hosts ausgeführt wird. Warten Sie einige Minuten und prüfen Sie die Konnektivität erneut. Hinweis: Hinweis: Bitte beachten Sie, dass dieser Alarm nicht kritisch ist und aufgelöst werden sollte. GSS muss über diesen Alarm nicht benachrichtigt werden, es sei denn, er bleibt über einen längeren Zeitraum ungelöst.
Steuerungskanal zum Manager-Knoten ist zu lange inaktiv	Kritisch	Die Control Plane-Verbindung des Transportknotens mit dem Manager-Knoten ist bereits lange inaktiv. Bei Erkennung des Ereignisses: „Die Control Plane-Verbindung des Transportknotens {entity_id} mit dem Manager-Knoten {appliance_address} ist aus der Sicht des Transportknotens seit mindestens {timeout_in_minutes} Minuten inaktiv.“ Bei Auflösung des Ereignisses: „Der Transportknoten {entity_id} stellt die Control Plane-Verbindung mit dem Manager-Knoten {appliance_address} wieder her.“	Überprüfen Sie die Konnektivität des Transportknotens {entity_id} mit der Schnittstelle des Manager-Knotens {appliance_address} per Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im Netzwerk beeinträchtigt ist. Überprüfen Sie, ob die TCP-Verbindungen mithilfe der netstat-Ausgabe eingerichtet wurden, um festzustellen, ob der Controller-Dienst auf dem Manager-Knoten {appliance_address} Port 1235 auf Verbindungen überwacht. Falls nicht, überprüfen Sie die Firewall- (oder) iptables-Regeln, um festzustellen, ob Port 1235 Verbindungsanfragen von Transportknoten {entity_id} blockiert. Stellen Sie sicher, dass keine Host- oder Netzwerk-Firewalls im Underlay vorhanden sind, die die erforderlichen IP-Ports zwischen Manager-Knoten und Transportknoten blockieren. Dies ist in unserem Tool für Ports und Protokolle beschrieben: https://ports.vmware.com/. Es ist möglich, dass sich der Transportknoten {entity_id} noch im Wartungsmodus befindet. Über die folgende API können Sie überprüfen, ob sich der Transportknoten im Wartungsmodus befindet: GET https://<nsx-mgr>/api/v1/transport-nodes/<tn-uuid> Wenn der Wartungsmodus festgelegt ist, wird der Transportknoten nicht mit dem Controller-Dienst verbunden. Dies ist in der Regel der Fall, wenn ein Upgrade des Hosts ausgeführt wird. Warten Sie einige Minuten und prüfen Sie die Konnektivität erneut.
Verwaltungskanal für den Transportknoten ist nicht verfügbar	Mittel	Der Verwaltungskanal für den Transportknoten ist nicht verfügbar. Bei Erkennung des Ereignisses: „Der Verwaltungskanal zum Transportknoten {transport_node_name} ({transport_node_address}) ist seit 5 Minuten aktiv.“ Bei Auflösung des Ereignisses: „Der Verwaltungskanal zum Transportknoten {transport_node_name} ({transport_node_address}) ist aktiv.“	Stellen Sie sicher, dass Netzwerkkonnektivität zwischen den Manager-Knoten und dem Transportknoten {transport_node_name} ({transport_node_address}) besteht und keine Firewalls den Datenverkehr zwischen den Knoten blockieren. Stellen Sie auf Windows Transportknoten sicher, dass der nsx-proxy-Dienst auf dem Transportknoten ausgeführt wird, indem Sie den folgenden Befehl im Windows PowerShell aufrufen. C:NSX\nsx-proxy\nsx-proxy.ps1 status Wenn er nicht ausgeführt wird, starten Sie ihn neu, indem Sie den folgenden Befehl aufrufen: C:NSX\nsx-proxy\nsx-proxy.ps1 restart Stellen Sie auf allen anderen Transportknoten sicher, dass der NSX-Proxydienst auf dem Transportknoten ausgeführt wird, indem Sie den folgenden Befehl aufrufen: /etc/init.d/nsx-proxy status Wenn er nicht ausgeführt wird, starten Sie ihn neu, indem Sie den folgenden Befehl aufrufen: /etc/init.d/nsx-proxy restart.
Verwaltungskanal zum Transportknoten zu lang inaktiv	Kritisch	Verwaltungskanal zum Transportknoten ist zu lang inaktiv. Bei Erkennung des Ereignisses: „Der Verwaltungskanal zum Transportknoten {transport_node_name} ({transport_node_address}) ist seit 15 Minuten aktiv.“ Bei Auflösung des Ereignisses: „Der Verwaltungskanal zum Transportknoten {transport_node_name} ({transport_node_address}) ist aktiv.“	Stellen Sie sicher, dass Netzwerkkonnektivität zwischen den Manager-Knoten und dem Transportknoten {transport_node_name} ({transport_node_address}) besteht und keine Firewalls den Datenverkehr zwischen den Knoten blockieren. Stellen Sie auf Windows Transportknoten sicher, dass der nsx-proxy-Dienst auf dem Transportknoten ausgeführt wird, indem Sie den folgenden Befehl im Windows PowerShell aufrufen. C:NSX\nsx-proxy\nsx-proxy.ps1 status Wenn er nicht ausgeführt wird, starten Sie ihn neu, indem Sie den folgenden Befehl aufrufen: C:NSX\nsx-proxy\nsx-proxy.ps1 restart Stellen Sie auf allen anderen Transportknoten sicher, dass der NSX-Proxydienst auf dem Transportknoten ausgeführt wird, indem Sie den folgenden Befehl aufrufen: /etc/init.d/nsx-proxy status Wenn er nicht ausgeführt wird, starten Sie ihn neu, indem Sie den folgenden Befehl aufrufen: /etc/init.d/nsx-proxy restart.
Manager-Cluster-Latenz ist hoch	Mittel	Die durchschnittliche Netzwerklatenz zwischen Manager-Knoten ist hoch. Bei Erkennung des Ereignisses: „Die durchschnittliche Netzwerklatenz zwischen den Manager-Knoten {manager_node_id} ({appliance_address}) und {remote_manager_node_id} ({remote_appliance_address}) betrug in den letzten 5 Minuten mehr als 10 ms.“ Bei Auflösung des Ereignisses: „Die durchschnittliche Netzwerklatenz zwischen den Manager-Knoten {manager_node_id} ({appliance_address}) und {remote_manager_node_id} ({remote_appliance_address}) liegt innerhalb von 10 ms.“	Stellen Sie sicher, dass keine Firewallregeln den Ping-Datenverkehr zwischen den Manager-Knoten blockieren. Wenn andere Server mit hoher Bandbreite und Anwendungen, die das lokale Netzwerk nutzen, vorhanden sind, verschieben Sie diese gegebenenfalls in ein anderes Netzwerk.
Managerkontrollkanal ist nicht verfügbar	Kritisch	Der Kanal zwischen Manager und Controller ist nicht verfügbar. Bei Erkennung des Ereignisses: „Die Kommunikation zwischen der Verwaltungsfunktion und der Steuerungsfunktion ist auf dem Manager-Knoten {manager_node_name} ({appliance_address}) fehlgeschlagen.“ Bei Auflösung des Ereignisses: „Die Kommunikation zwischen der Verwaltungsfunktion und der Steuerungsfunktion wurde auf dem Manager-Knoten {manager_node_name} ({appliance_address}) wiederhergestellt.“	Rufen Sie auf dem Manager-Knoten {manager_node_name} ({appliance_address}) die folgenden beiden NSX-CLI-Befehle auf: restart service mgmt-plane-bus restart service manager
Lookup von Manager FQDN fehlgeschlagen	Kritisch	DNS-Lookup für den FQDN des Manager-Knotens fehlgeschlagen. Bei Erkennung des Ereignisses: „DNS-Lookup für den Manager-Knoten {entity_id} mit FQDN {appliance_fqdn} ist fehlgeschlagen und Flag publish_fqdns wurde gesetzt.“ Bei Auflösung des Ereignisses: „FQDN-Lookup für den Manager-Knoten {entity_id} mit FQDN {appliance_fqdn} war erfolgreich oder Flag publish_fqdns wurde gelöscht.“	Weisen Sie allen Manager-Knoten korrekte FQDNs zu und überprüfen Sie, ob die DNS-Konfiguration für einen erfolgreichen Lookup der FQDNs aller Manager-Knoten korrekt ist. Alternativ können Sie die Verwendung von FQDNs deaktivieren, indem Sie die folgende NSX API aufrufen, wobei „publish_fqdns“ im Anforderungstext auf „false“ gesetzt ist. PUT /api/v1/configs/management Danach nutzen Aufrufe von Transportknoten und vom Verbund an Manager-Knoten in diesem Cluster nur IP-Adressen.
Umgekehrter Lookup von Manager FQDN fehlgeschlagen	Kritisch	Umgekehrter DNS-Lookup für die IP-Adresse des-Manager-Knotens fehlgeschlagen. Bei Erkennung des Ereignisses: „Umgekehrter DNS-Lookup für den Manager-Knoten {entity_id} mit der IP-Adresse {appliance_address} ist fehlgeschlagen und Flag publish_fqdns wurde gesetzt.“ Bei Auflösung des Ereignisses: „Umgekehrter DNS-Lookup für den Manager-Knoten {entity_id} mit der IP-Adresse {appliance_address} war erfolgreich oder Flag publish_fqdns wurde gelöscht.“	Weisen Sie allen Manager-Knoten die korrekten FQDNs zu und stellen Sie sicher, dass die DNS-Konfiguration für einen erfolgreichen umgekehrten Lookup der IP-Adresse des Manager-Knotens korrekt ist. Alternativ können Sie die Verwendung von FQDNs deaktivieren, indem Sie die folgende NSX API aufrufen, wobei „publish_fqdns“ im Anforderungstext auf „false“ gesetzt ist. PUT /api/v1/configs/management Danach nutzen Aufrufe von Transportknoten und vom Verbund an Manager-Knoten in diesem Cluster nur IP-Adressen.
Verwaltungskanal zum Manager-Knoten inaktiv	Mittel	Verwaltungskanal zum Manager-Knoten ist inaktiv. Bei Erkennung des Ereignisses: „Verwaltungskanal zum Manager-Knoten {manager_node_id} ({appliance_address}) ist seit 5 Minuten inaktiv.“ Bei Auflösung des Ereignisses: „Der Verwaltungskanal zum Manager-Knoten {manager_node_id} ({appliance_address}) ist aktiv.“	Stellen Sie sicher, dass die Netzwerkkonnektivität zwischen dem Transportknoten {transport_node_id} und dem primären Manager-Knoten besteht. und keine Firewalls den Datenverkehr zwischen den Knoten blockieren. Stellen Sie sicher, dass der Messaging-Manager-Dienst auf Manager-Knoten ausgeführt wird, indem Sie den folgenden Befehl aufrufen. /etc/init.d/messaging-manager status Wenn der Messaging-Manager nicht ausgeführt wird, starten Sie ihn neu, indem Sie den folgenden Befehl aufrufen. /etc/init.d/messaging-manager restart
Verwaltungskanal zum Manager-Knoten lange inaktiv	Kritisch	Verwaltungskanal zum Manager-Knoten ist zu lang inaktiv. Bei Erkennung des Ereignisses: „Der Verwaltungskanal zum Manager-Knoten {manager_node_id} ({appliance_address}) ist seit 15 Minuten inaktiv.“ Bei Auflösung des Ereignisses: „Der Verwaltungskanal zum Manager-Knoten {manager_node_id} ({appliance_address}) ist aktiv.“	Stellen Sie sicher, dass die Netzwerkkonnektivität zwischen dem Transportknoten {transport_node_id} und dem primären Manager-Knoten besteht. und keine Firewalls den Datenverkehr zwischen den Knoten blockieren. Stellen Sie sicher, dass der Messaging-Manager-Dienst auf Manager-Knoten ausgeführt wird, indem Sie den folgenden Befehl aufrufen. /etc/init.d/messaging-manager status Wenn der Messaging-Manager nicht ausgeführt wird, starten Sie ihn neu, indem Sie den folgenden Befehl aufrufen. /etc/init.d/messaging-manager restart

Infrastruktur-Dienstereignisse

Infrastruktur-Dienstereignisse stammen aus den NSX Edge- und den öffentlichen Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Status des Edge-Diensts nicht verfügbar Hinweis: Alarm ist ab NSX-T Data Center 3.2 veraltet.	Kritisch	Der Edge-Dienst ist mindestens eine Minute lang inaktiv. Wenn der Link Laufzeitdetails anzeigen verfügbar ist, können Sie auf den Link klicken, um den Grund für den Ausfall des Diensts anzuzeigen. Bei Erkennung des Ereignisses: „Der Dienst {edge_service_name} ist mindestens eine Minute lang inaktiv.“ Bei Auflösung des Ereignisses: „Der Dienst {edge_service_name} ist aktiv.“	Stellen Sie auf dem Edge-Knoten sicher, dass der Dienst nicht aufgrund eines Fehlers beendet wurde, indem Sie im Verzeichnis /var/log/core nach Core-Dump-Dateien suchen. Rufen Sie zum Bestätigen, ob der Dienst angehalten wurde, den NSX-CLI-Befehl get services auf. Ist dies der Fall, führen Sie start service <service-name> aus, um den Dienst neu zu starten.
Status des Edge-Diensts hat sich geändert	Mittel	Der Status des Edge-Diensts hat sich geändert. Wenn der Link Laufzeitdetails anzeigen verfügbar ist, können Sie auf den Link klicken, um den Grund für den Ausfall des Diensts anzuzeigen. Bei Erkennung des Ereignisses: „Der Dienst {edge_service_name} hat sich von {previous_service_state} in {current_service_state} geändert.“ Bei Auflösung des Ereignisses: „Der Dienst {edge_service_name} hat sich von {previous_service_state} in {current_service_state} geändert.“	Stellen Sie auf dem Edge-Knoten sicher, dass der Dienst nicht aufgrund eines Fehlers beendet wurde, indem Sie im Verzeichnis /var/log/core nach Core-Dateien suchen. Rufen Sie darüber hinaus den NSX-CLI-Befehl get services auf, um festzustellen, ob der Dienst angehalten wurde. Ist dies der Fall, rufen Sie start service <service-name> auf, um den Dienst neu zu starten.

Intelligence-Integritätsereignisse

NSX IntelligenceIntegritätsereignisse stammen vom NSX Manager-Knoten und der NSX Intelligence-Appliance.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
CPU-Nutzung sehr hoch	Kritisch	Die CPU-Auslastung durch den Intelligence-Knoten ist sehr hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt unter dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Verwenden Sie den Befehl top, um zu überprüfen, welche Prozesse die meiste Arbeitsspeichernutzung aufweisen. Überprüfen Sie dann /var/log/syslog und die lokalen Protokolle dieser Prozesse, um festzustellen, ob ausstehende Fehler behoben werden müssen.
CPU-Nutzung hoch	Mittel	Die CPU-Auslastung durch den Intelligence-Knoten ist hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt unter dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Verwenden Sie den Befehl top, um zu überprüfen, welche Prozesse die meiste Arbeitsspeichernutzung aufweisen. Überprüfen Sie dann /var/log/syslog und die lokalen Protokolle dieser Prozesse, um festzustellen, ob ausstehende Fehler behoben werden müssen.
Arbeitsspeichernutzung sehr hoch	Kritisch	Die Arbeitsspeichernutzung durch den Intelligence-Knoten ist sehr hoch. Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt unter dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Verwenden Sie den Befehl top, um zu überprüfen, welche Prozesse die meiste Arbeitsspeichernutzung aufweisen. Überprüfen Sie dann /var/log/syslog und die lokalen Protokolle dieser Prozesse, um festzustellen, ob ausstehende Fehler behoben werden müssen.
Arbeitsspeichernutzung hoch	Mittel	Die Arbeitsspeichernutzung durch den Intelligence-Knoten ist hoch. Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt unter dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Verwenden Sie den Befehl top, um zu überprüfen, welche Prozesse die meiste Arbeitsspeichernutzung aufweisen. Überprüfen Sie dann /var/log/syslog und die lokalen Protokolle dieser Prozesse, um festzustellen, ob ausstehende Fehler behoben werden müssen.
Festplattennutzung sehr hoch	Kritisch	Die Festplattennutzung durch den Intelligence-Knoten ist sehr hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung der Festplattenpartition {disk_partition_name} auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung der Festplattenpartition {disk_partition_name} auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt unter dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Untersuchen Sie die Festplattenpartition {disk_partition_name} und überprüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
Festplattennutzung hoch	Mittel	Die Festplattennutzung durch den Intelligence-Knoten ist hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung der Festplattenpartition {disk_partition_name} auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung der Festplattenpartition {disk_partition_name} auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt unter dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Untersuchen Sie die Festplattenpartition {disk_partition_name} und überprüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
Nutzung der Datenfestplatten-Partition sehr hoch	Kritisch	Die Nutzung der Datenträgerpartition durch den Intelligence-Knoten ist sehr hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung der Festplattenpartition /data auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung der Festplattenpartition /data auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt unter dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Stoppen Sie die NSX Intelligence-Datenerfassung, bis sich die Festplattennutzung unterhalb des Schwellenwerts bewegt. Navigieren Sie in der NSX-Benutzeroberfläche zu System Appliances NSX Intelligence-Appliance. Wählen Sie dann AKTIONEN > Datenerfassung stoppen.
Nutzung der Datenfestplatten-Partition hoch	Mittel	Die Nutzung der Datenträgerpartition durch den Intelligence-Knoten ist hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung der Festplattenpartition /data auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt über dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung der Festplattenpartition /data auf dem NSX Intelligence-Knoten {intelligence_node_id} liegt unter dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Stoppen Sie die NSX Intelligence-Datenerfassung, bis sich die Festplattennutzung unterhalb des Schwellenwerts bewegt. Untersuchen Sie die Partition /data und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
Knotenstatus herabgestuft	Hoch	Der Status des Intelligence-Knotens ist „Herabgestuft“. Bei Erkennung des Ereignisses: „Der Dienst {service_name} auf dem NSX Intelligence-Knoten {intelligence_node_id} wird nicht ausgeführt.“ Bei Auflösung des Ereignisses: „Der Dienst {service_name} auf dem NSX Intelligence-Knoten {intelligence_node_id} wird ordnungsgemäß ausgeführt.“	Untersuchen Sie den Dienststatus und die Integritätsdaten mit dem NSX-CLI-Befehl get services im NSX Intelligence-Knoten. Starten Sie unerwartet angehaltenen Dienste mit dem NSX-CLI-Befehl restart service <service-name>.

Ereignisse der IP-Adressverwaltung

IP-Adressverwaltung (IPAM)-Ereignisse stammen von den NSX Manager-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
IP-Blocknutzung sehr hoch	Mittel	Ab NSX-T Data Center 3.1.2 Die IP-Subnetznutzung eines IP-Blocks hat 90 % erreicht. Bei Erkennung des Ereignisses: „IP-Block-Nutzung von <intent_path> ist sehr hoch. IP-Block nähert sich seiner Gesamtkapazität, die Erstellung eines Subnetzes mit IP-Block könnte fehlschlagen.“ Bei Auflösung des Ereignisses: Keine Nachricht.	Überprüfen Sie die IP-Block-Nutzung. Verwenden Sie einen neuen IP-Block für die Ressourcenerstellung oder löschen Sie das nicht verwendete IP-Subnetz aus dem IP-Block. Zur Überprüfung des Subnetzes, das für einen IP-Block verwendet wird: Navigieren Sie in der NSX-Benutzeroberfläche zu Netzwerk > IP-Adresspools > IP-Adresspools. Wählen Sie IP-Pools aus, in denen der IP-Block verwendet wird. Prüfen Sie die Spalten Subnetze und Zugewiesene IPs. Löschen Sie das Subnetz oder den IP-Pool, wenn keine der Zuteilungen verwendet wird und auch in Zukunft nicht verwendet werden soll. Verwenden Sie die folgenden APIs, um zu prüfen, ob der IP-Block vom IP-Pool verwendet wird, und um IP-Zuteilungen zu prüfen. Um konfigurierte Subnetze eines IP-Pools abzurufen, rufen Sie die folgende NSX API auf. GET /policy/api/v1/infra/ip-pools/<ip-pool>/ip-subnets Um IP-Zuteilungen zu erhalten, rufen Sie die folgende NSX API auf. GET /policy/api/v1/infra/ip-pools/<ip-pool>/ip-allocations Hinweis: Löschen Sie einen IP-Pool oder ein Subnetz nur, wenn er/es keine zugewiesenen IPs hat und in Zukunft nicht mehr verwendet wird.
IP-Pool-Nutzung sehr hoch	Mittel	Ab NSX-T Data Center 3.1.2 Die IP-Zuteilungsnutzung eines IP-Pools hat 90 % erreicht. Bei Erkennung des Ereignisses: „IP-Pool-Nutzung von <intent_path> ist sehr hoch. Der IP-Pool nähert sich seiner Gesamtkapazität. Die Erstellung einer Entität/eines Dienstes, die/der von der Zuteilung einer IP aus dem IP-Pool abhängt, könnte fehlschlagen.“ Bei Auflösung des Ereignisses: Keine Nachricht.	Überprüfen Sie die IP-Pool-Nutzung. Geben Sie ungenutzte IP-Zuteilungen aus dem IP-Pool frei oder erstellen Sie einen neuen IP-Pool. Navigieren Sie in der NSX-Benutzeroberfläche zu Netzwerk > IP-Adresspools > IP-Adresspools. Wählen Sie IP-Pools und aktivieren Sie die Spalte Zugewiesene IPs, um die aus dem IP-Pool zugeteilten IPs anzuzeigen. Sie können die IPs freigeben, die nicht genutzt werden. Um ungenutzte IP-Zuteilungen freizugeben, rufen Sie die folgende NSX API auf. DELETE /policy/api/v1/infra/ip-pools/<ip-pool>/ip-allocations/<ip-allocation>

Lizenzereignisse

Lizenzereignisse stammen vom NSX Manager-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Lizenz abgelaufen	Kritisch	Eine Lizenz ist abgelaufen. Bei Erkennung des Ereignisses: „Die Lizenz vom Typ {license_edition_type} ist abgelaufen.“ Bei Auflösung des Ereignisses: „Die abgelaufene Lizenz vom Typ {license_edition_type} wurde entfernt, aktualisiert oder ist nicht mehr abgelaufen.“	Fügen Sie eine neue, nicht abgelaufene Lizenz hinzu: Navigieren Sie in der NSX-Benutzeroberfläche zu System > Lizenzen. Klicken Sie auf Hinzufügen und geben Sie den Schlüssel für die neue Lizenz an. Löschen Sie die abgelaufene Lizenz, indem Sie das Kontrollkästchen aktivieren und auf Zuweisung aufheben klicken.
Lizenz läuft in Kürze ab	Mittel	Eine Lizenz läuft in Kürze ab. Bei Erkennung des Ereignisses: „Die Lizenz vom Typ {license_edition_type} läuft in Kürze ab.“ Bei Auflösung des Ereignisses: „Die ablaufende Lizenz vom Typ {license_edition_type} wurde entfernt, aktualisiert oder läuft nicht mehr demnächst ab.“	Fügen Sie eine neue, nicht abgelaufene Lizenz hinzu: Navigieren Sie in der NSX-Benutzeroberfläche zu System > Lizenzen. Klicken Sie auf Hinzufügen und geben Sie den Schlüssel für die neue Lizenz an. Löschen Sie die abgelaufene Lizenz, indem Sie das Kontrollkästchen aktivieren und auf Zuweisung aufheben klicken.

Load Balancer-Ereignisse

Load-Balancer-Ereignisse gehen von NSX Edge-Knoten oder von NSX Manager-Knoten aus.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
LB-CPU sehr hoch	Mittel	Die CPU-Auslastung durch den Load Balancer ist sehr hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung von Load Balancer {entity_id} ist sehr hoch. Der Schwellenwert ist {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung des Load Balancer {entity_id} ist niedrig genug. Der Schwellenwert ist {system_usage_threshold} %.“	Wenn die CPU-Auslastung des Load Balancers höher als der Schwellenwert für die Systemauslastung ist, ist die Arbeitslast für diesen Load Balancer zu hoch. Skalieren Sie den Load Balancer-Dienst neu, indem Sie die Load Balancer-Größe von klein zu mittel oder von mittel zu groß ändern. Wenn die CPU-Nutzung dieses Load Balancers immer noch hoch ist, sollten Sie die Formfaktorgröße der Edge-Appliance anpassen oder die Load Balancer-Dienste für die jeweilige Arbeitslast auf andere Edge-Knoten verschieben.
LB-Status inaktiv	Kritisch	Der zentralisierte Load Balancer-Dienst ist inaktiv. Bei Erkennung des Ereignisses: „Der zentralisierte Load Balancer-Dienst {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Der zentralisierte Load Balancer-Dienst {entity_id} ist aktiv.“	Prüfen Sie auf dem aktiven Edge-Knoten den Load Balancer-Status, indem Sie den folgenden NSX-CLI-Befehl aufrufen. get load-balancer <lb-uuid> status Wenn der LB-Status des Load Balancer-Dienstes „not_ready“ ist oder keine Ausgabe erfolgt, veranlassen Sie den Edge-Knoten, in den Wartungsmodus zu wechseln, und beenden Sie dann den Wartungsmodus.
Status des virtuellen Servers inaktiv	Mittel	Der virtuelle Load Balancer-Dienst ist inaktiv. Bei Erkennung des Ereignisses: „Der virtuelle Load Balancer-Server {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Der virtuelle Load Balancer-Server {entity_id} ist aktiv.“	Bestimmen Sie den Status des Load Balancer-Pools und überprüfen Sie dessen Konfiguration. Wenn er falsch konfiguriert ist, konfigurieren Sie ihn neu und entfernen Sie den Load Balancer-Pool vom virtuellen Server und fügen Sie ihn dann erneut dem virtuellen Server hinzu.
Pool-Status inaktiv	Mittel	Der Load Balancer-Pool ist inaktiv. Bei Erkennung des Ereignisses: „Der Load Balancer-Pool {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Der Load Balancer-Pool {entity_id} ist aktiv.“	Prüfen Sie den Load Balancer-Pool, um zu ermitteln, welche Mitglieder inaktiv sind. Überprüfen Sie die Netzwerkkonnektivität zwischen dem Load Balancer und den betroffenen Poolmitgliedern. Validieren Sie die Anwendungsintegrität der einzelnen Poolmitglieder. Validieren Sie mit dem konfigurierten Monitor die Integrität der einzelnen Poolmitglieder. Wenn der Integritätszustand des Mitglieds ermittelt wurde, wird der Status des Poolmitglieds basierend auf der Konfiguration „Anzahl bis zum erneuten Versuch“ in der Überwachung auf „fehlerfrei“ aktualisiert.
LB-Status herabgestuft	Mittel	Ab NSX-T Data Center 3.1.2 Der Load Balancer-Dienst ist herabgestuft. Bei Erkennung des Ereignisses: „Der Load Balancer-Dienst {entity_id} ist herabgestuft.“ Bei Auflösung des Ereignisses: „Der Load Balancer-Dienst {entity_id} ist nicht herabgestuft.“	Für zentralisierten Load Balancer: Prüfen Sie auf dem Standby-Edge-Knoten den Load Balancer-Status, indem Sie den folgenden NSX-CLI-Befehl aufrufen. get load-balancer <lb-uuid> status Wenn der LB-Status des Load Balancer-Diensts „not_ready“ lautet oder keine Ausgabe erfolgt, veranlassen Sie den Edge-Knoten, in den Wartungsmodus zu wechseln, und beenden Sie dann den Wartungsmodus. Für verteilte Load Balancer: Erhalten Sie einen detaillierten Status, indem Sie die folgende NSX API aufrufen. GET /policy/api/v1/infra/lb-services/<LBService>/detailed-status?source=realtime Suchen Sie in der API-Ausgabe den ESXi-Host, der eine Instanznummer ungleich null mit dem Status NOT_READY oder CONFLICT meldet. Rufen Sie auf dem ESXi-Hostknoten den folgenden NSX-CLI-Befehl auf. get load-balancer <lb-uuid> status Wenn „Conflict LSP“ gemeldet wird, prüfen Sie, ob dieser LSP mit einem anderen Load Balancer-Dienst verbunden ist. Prüfen Sie, ob dieser Konflikt akzeptabel ist. Wenn „Not Ready LSP“ gemeldet wird, prüfen Sie den Status dieses LSP, indem Sie den folgenden NSX CLI-Befehl aufrufen. get logical-switch-port status
DLB-Status inaktiv	Kritisch	Ab NSX-T Data Center 3.1.2 Der Distributed Load Balancer-Dienst ist inaktiv. Bei Erkennung des Ereignisses: „Der verteilte Load Balancer-Dienst {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Der verteilte Load Balancer-Dienst {entity_id} ist aktiv.“	Rufen Sie auf dem ESXi-Hostknoten den folgenden NSX-CLI-Befehl auf. get load-balancer <lb-uuid> status Wenn der Bericht „Conflict LSP“ anzeigt, prüfen Sie, ob dieser LSP mit einem anderen Load Balancer-Dienst verbunden ist. Prüfen Sie auch, ob dieser Konflikt akzeptabel ist. Wenn der Bericht „Not Ready LSP“ anzeigt, prüfen Sie den Status dieses LSP, indem Sie den folgenden NSX CLI-Befehl aufrufen. get logical-switch-port status
LB-Edge-Kapazität in Verwendung hoch	Mittel	Ab NSX-T Data Center 3.1.2 Auslastung des Load Balancers ist hoch Bei Erkennung des Ereignisses: „Die Auslastung des Load Balancer-Dienstes im Edge-Knoten {entity_id} ist hoch. Der Schwellenwert ist {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Auslastung des Load Balancer-Dienstes im Edge-Knoten {entity_id} ist niedrig genug. Der Schwellenwert ist {system_usage_threshold} %.“	Wenn in diesem Edge-Knoten mehrere LB-Instanzen konfiguriert wurden, stellen Sie einen neuen Edge-Knoten bereit und verschieben Sie einige LB-Instanzen auf diesen neuen Edge-Knoten. Wenn nur eine einzelne LB-Instanz (klein/mittel/etc) in einem Edge-Knoten derselben Größe (klein/mittel/etc) konfiguriert wurde, stellen Sie einen neuen größeren Edge-Knoten bereit und verschieben Sie die LB-Instanz auf den neuen Edge-Knoten.
LB-Pool-Mitgliedskapazität in Verwendung sehr hoch	Kritisch	Ab NSX-T Data Center 3.1.2 Die Auslastung des Load Balancer-Poolmitglieds ist sehr hoch. Bei Erkennung des Ereignisses: „Die Auslastung der Poolmitglieder im Edge-Knoten {entity_id} ist hoch. Der Schwellenwert ist {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Auslastung der Poolmitglieder im Edge-Knoten {entity_id} ist niedrig genug. Der Schwellenwert ist {system_usage_threshold} %.“	Stellen Sie einen neuen Edge-Knoten bereit und verschieben Sie den Load Balancer-Dienst von den vorhandenen Edge-Knoten auf den neu bereitgestellten Edge-Knoten.
Die Load Balancing-Konfiguration wurde wegen unzureichendem Arbeitsspeicher nicht realisiert	Mittel	Die Load Balancer-Konfiguration wurde wegen einer hohen Arbeitsspeichernutzung auf dem Edge-Knoten nicht realisiert. Bei Erkennung des Ereignisses: „Die Load Balancer-Konfiguration {entity_id} wird wegen einer hohen Arbeitsspeichernutzung auf dem Edge-Knoten {transport_node_id} nicht realisiert.“ Bei Auflösung des Ereignisses: „Die Load Balancer-Konfiguration {entity_id} wird auf {transport_node_id} realisiert.“	Definieren Sie anstelle von großen Load Balancern bevorzugt kleine und mittlere Load Balancer. Verteilen Sie Load Balancer-Dienste auf die verfügbaren Edge-Knoten. Reduzieren Sie die Anzahl der definierten virtuellen Server.

Manager-Integritätsereignisse

NSX Manager-Integritätsereignisse stammen vom Cluster des NSX Manager-Knotens.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Doppelte IP-Adresse	Mittel	Die IP-Adresse des Manager-Knotens wird von einem anderen Gerät verwendet. Bei Erkennung des Ereignisses: „Der Manager-Knoten {entity_id} mit IP-Adresse {duplicate_ip_address} wird derzeit von einem anderen Gerät im Netzwerk verwendet.“ Bei Erkennung des Ereignisses: „Das Gerät, das die dem Manager-Knoten {entity_id} zugewiesene IP-Adresse verwendet, scheint {duplicate_ip_address} nicht mehr zu verwenden.“	Legen Sie fest, welches Gerät die IP-Adresse des Managers verwendet, und weisen Sie dem Gerät eine neue IP-Adresse zu. Hinweis: Das Neukonfigurieren des Managers für die Verwendung einer neuen IP-Adresse wird nicht unterstützt. Überprüfen Sie, ob der Pool/DHCP-Server für die statische IP-Adresse ordnungsgemäß konfiguriert ist. Korrigieren Sie die IP-Adresse des Geräts, wenn sie manuell zugewiesen wird.
Manager-CPU-Nutzung sehr hoch	Kritisch	Die CPU-Auslastung durch den Manager-Knoten ist sehr hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Manager-Knotens. Ziehen Sie eine Anpassung der Formfaktorgröße der Manager-Appliance in Erwägung.
Manager-CPU-Nutzung hoch	Mittel	Ab NSX-T Data Center 3.0.1. Die CPU-Auslastung durch den Manager-Knoten ist hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Manager-Knotens. Ziehen Sie eine Anpassung der Formfaktorgröße der Manager-Appliance in Erwägung.
Manager-Arbeitsspeichernutzung sehr hoch	Kritisch	Ab NSX-T Data Center 3.0.1. Die Arbeitsspeichernutzung des Manager-Knotens ist sehr hoch. Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Manager-Knotens. Ziehen Sie eine Anpassung der Formfaktorgröße der Manager-Appliance in Erwägung.
Manager-Arbeitsspeichernutzung hoch	Mittel	Die Arbeitsspeichernutzung des Manager-Knotens ist hoch. Bei Erkennung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Arbeitsspeichernutzung auf dem Manager-Knoten {entity_id} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Überprüfen Sie die Konfiguration, die Dienstausführung und die Dimensionierung dieses Manager-Knotens. Ziehen Sie eine Anpassung der Formfaktorgröße der Manager-Appliance in Erwägung.
Manager-Festplattennutzung sehr hoch	Kritisch	Die Festplattennutzung des Manager-Knotens ist sehr hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Untersuchen Sie die Partition mit hoher Auslastung und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
Manager-Festplattennutzung hoch	Mittel	Die Festplattennutzung des Manager-Knotens ist hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition {disk_partition_name} hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Untersuchen Sie die Partition mit hoher Auslastung und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
Manager-Konfigurationsfestplatten-Nutzung sehr hoch	Kritisch	Die Festplattennutzung der Manager-Knotenkonfiguration ist sehr hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition /config hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. Dies kann ein Hinweis auf eine hohe Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis /config/corfu sein.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition /config hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Führen Sie das folgende Tool aus und wenden Sie sich an GSS, wenn Probleme auftreten: /opt/vmware/tools/support/inspect_checkpoint_issues.py
Manager-Konfigurationsfestplatten-Nutzung hoch	Mittel	Die Festplattennutzung der Manager-Knotenkonfiguration ist hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition /config hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. Dies kann ein Hinweis auf eine steigende Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis „/config/corfu“ sein.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition /config hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Untersuchen Sie die Partition /config und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
Festplattenbelegung durch Operations DB hoch	Mittel	Die Festplattennutzung der nonconfig-Instanz des Manager-Knotens ist hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition /nonconfig hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %. Dies kann ein Hinweis auf eine steigende Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis /nonconfig/corfu sein.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition /nonconfig hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine hohe Nutzung von {system_usage_threshold} %.“	Führen Sie das folgende Tool aus und wenden Sie sich an GSS, sofern Probleme gemeldet werden /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig.
Festplattenbelegung durch Operations DB sehr hoch	Kritisch	Die Festplattennutzung der nonconfig-Instanz des Manager-Knotens ist sehr hoch. Bei Erkennung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition /nonconfig hat {system_resource_usage} % erreicht und ist damit größer als oder gleich dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %. Dies kann ein Hinweis auf eine hohe Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis /nonconfig/corfu sein.“ Bei Auflösung des Ereignisses: „Die Festplattennutzung für die Manager-Knoten-Festplattenpartition /nonconfig hat {system_resource_usage} % erreicht und ist damit geringer als der Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Führen Sie das folgende Tool aus und wenden Sie sich an GSS, sofern Probleme gemeldet werden /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig.

NCP-Ereignisse

NSX Container Plug-in(NCP)-Ereignisse stammen aus den ESXi- und KVM-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
NCP-Plug-in nicht verfügbar	Kritisch	Manager-Knoten hat erkannt, dass NCP ausgefallen oder fehlerhaft ist. Bei Erkennung des Ereignisses: „Manager-Knoten hat erkannt, dass NCP ausgefallen oder fehlerhaft ist.“ Bei Auflösung des Ereignisses: „Manager-Knoten hat erkannt, dass der NCP wieder betriebsbereit oder fehlerfrei ist.“	Um nach Clustern zu suchen, die Probleme aufweisen, führen Sie eine der folgenden Aktionen aus: Navigieren Sie in der NSX-Benutzeroberfläche zu der Seite „Alarme“. Der Wert „Entitätsname“ für diese Alarminstanz identifiziert den Clusternamen. Rufen Sie die NSX API GET /api/v1/systemhealth/container-cluster/ncp/status auf, um alle Clusterstatus abzurufen und den Namen der Cluster zu ermitteln, die als INAKTIV oder UNBEKANNT gemeldet sind. Suchen Sie dann in der NSX-Benutzeroberfläche auf der Seite „Bestand“ | „Container“ | „Cluster“ nach dem Namen des Clusters und klicken Sie auf die Registerkarte „Knoten“, in der alle Kubernetes- und PAS-Cluster-Mitglieder aufgeführt sind. Für Kubernetes-Cluster: Überprüfen Sie die NCP-Pod-Aktivität, indem Sie unter allen Cluster-Mitgliedern den primären K8s-Knoten suchen und sich beim primären Knoten anmelden. Rufen Sie dann den kubectl-Befehl kubectl get pods --all-namespaces auf. Wenn ein Problem mit dem NCP-Pod vorliegt, verwenden Sie den Befehl „kubectl logs“, um das Problem zu überprüfen und den Fehler zu beheben. Überprüfen Sie die Verbindung zwischen NCP und dem Kubernetes-API-Server. Die NSX-CLI kann innerhalb des NCP-Pods verwendet werden, um diesen Verbindungsstatus zu überprüfen, indem Sie auf der primären VM die folgenden Befehle aufrufen. kubectl exec -it <NCP-Pod-Name> -n nsx-system bash nsxcli get ncp-k8s-api-server status Wenn ein Problem mit der Verbindung besteht, prüfen Sie die Netzwerk- und NCP-Konfigurationen. Überprüfen Sie die Verbindung zwischen NCP und NSX Manager. Die NSX-CLI kann innerhalb des NCP-Pods verwendet werden, um diesen Verbindungsstatus zu überprüfen, indem Sie auf der primären VM den folgenden Befehl aufrufen. kubectl exec -it <NCP-Pod-Name> -n nsx-system bash nsxcli get ncp-nsx status Wenn ein Problem mit der Verbindung besteht, prüfen Sie die Netzwerk- und die NCP-Konfiguration. Für PAS-Cluster: Überprüfen Sie die Netzwerkverbindungen zwischen den virtuellen Maschinen und beheben Sie Netzwerkprobleme. Überprüfen Sie den Status von Knoten und Diensten und korrigieren Sie abgestürzte Knoten oder Dienste. Rufen Sie die Befehle bosh vms und bosh instances -p auf, um den Status von Knoten und Diensten zu prüfen.

Knoten-Agents-Integritätsereignisse

Die Knoten-Agent-Integritätsereignisse stammen von den ESXi- und KVM-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Knoten-Agents inaktiv	Hoch	Die Agents, die innerhalb der Knoten-VM ausgeführt werden, scheinen ausgefallen zu sein. Bei Erkennung des Ereignisses: „Die Agents, die innerhalb der Knoten-VM ausgeführt werden, scheinen ausgefallen zu sein.“ Bei Auflösung des Ereignisses: „Die Agents innerhalb der Knoten-VM werden ausgeführt.“	Für ESX: Wenn Vmk50 fehlt, schlagen Sie im Knowledgebase-Artikel 67432 nach. Wenn Hyperbus 4094 fehlt: das Neustarten von nsx-cfgagent oder der Containerhost-VM kann helfen. Wenn die VIF des Container-Hosts blockiert ist, prüfen Sie die Verbindung mit dem Controller, um sicherzustellen, dass alle Konfigurationen heruntergefahren werden. Wenn nsx-cfgagent angehalten wurde, starten Sie nsx-cfgagent neu. Für KVM: Wenn der Hyperbus-Namespace fehlt, kann ein Neustart von nsx-opsagent dabei helfen, den Namespace neu zu erstellen. Wenn die Hyperbus-Schnittstelle innerhalb des Hyperbus-Namespace fehlt, kann ein Neustart von nsx-opsagent hilfreich sein. Wenn nsx-agent angehalten wurde, starten Sie nsx-agent neu. Sowohl für ESX als auch für KVM: Wenn das node-agent-Paket fehlt: Überprüfen Sie, ob das node-agent-Paket erfolgreich auf der VM des Container-Hosts installiert wurde. Wenn die Schnittstelle für node-agent auf der Container-Host-VM inaktiv ist: Überprüfen Sie den eth1-Schnittstellenstatus in der VM des Container-Hosts.

NSX-Verbund-Ereignisse

NSX-Verbund-Ereignisse stammen von den NSX Manager-, NSX Edge- und den öffentlichen Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
GM-zu-GM-Latenzwarnung	Mittel	Die Latenz zwischen globalen Manager-Instanzen ist länger als erwartet und beträgt mehr als 2 Minuten. Bei Erkennung des Ereignisses: „Die Latenz zwischen den globalen Managern {from_gm_path} und {to_gm_path} ist länger als erwartet.“ Bei Auflösung des Ereignisses: „Die Latenz zwischen den globalen Managern {from_gm_path} und {to_gm_path} liegt unter dem erwarteten Niveau.“	Überprüfen Sie die Konnektivität zwischen dem globalen Manager {from_gm_path}({site_id}) und dem globalen Manager {to_gm_path}({remote_site_id}) per Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im WAN beeinträchtigt ist.
GM-zu-GM-Synchronisierungsfehler	Hoch	Aktiver globaler Manager kann mehr als 5 Minuten lang nicht mit dem globalen Standby-Manager synchronisiert werden. Bei Erkennung des Ereignisses: „Der aktive globale Manager {from_gm_path} kann seit mehr als 5 Minuten nicht mit dem globalen Standby-Manager {to_gm_path} synchronisiert werden.“ Bei Auflösung des Ereignisses: „Die Synchronisierung vom aktiven globalen Manager {from_gm_path} zum globalen Standby-Manager {to_gm_path} ist fehlerfrei.“	Überprüfen Sie die Konnektivität zwischen dem globalen Manager {from_gm_path}({site_id}) und dem globalen Manager {to_gm_path}({remote_site_id}) per Ping.
GM-zu-GM-Synchronisierungswarnung	Mittel	Der aktive globale Manager kann nicht mit dem globalen Standby-Manager synchronisiert werden. Bei Erkennung des Ereignisses: „Der aktive globale Manager {from_gm_path} kann nicht mit dem globalen Standby-Manager {to_gm_path} synchronisiert werden.“ Bei Auflösung des Ereignisses: „Die Synchronisierung vom aktiven globalen Manager {from_gm_path} zum globalen Standby-Manager {to_gm_path} ist fehlerfrei.“	Überprüfen Sie die Konnektivität zwischen dem globalen Manager {from_gm_path}({site_id}) und dem globalen Manager {to_gm_path}({remote_site_id}) per Ping.
LM-zu-LM-Synchronisierung: Fehler	Hoch	Ab NSX-T Data Center 3.0.1. Synchronisation zwischen Remotespeicherorten seit mehr als 5 Minuten fehlgeschlagen. Bei Erkennung des Ereignisses: „Die Synchronisierung zwischen {site_name}({site_id}) und {remote_site_name}({remote_site_id}) ist seit mehr als 5 Minuten fehlgeschlagen.“ Bei Auflösung des Ereignisses: „Die Remote-Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) werden jetzt synchronisiert.“	Führen Sie den NSX-CLI-Befehl get site-replicator remote-sites aus, um den Verbindungszustand zwischen den Remotespeicherorten abzurufen. Wenn ein Remotespeicherort verbunden ist, aber nicht synchronisiert wird, befindet sich der Speicherort möglicherweise noch im Prozess der Auflösung des primären Knotens. Warten Sie in diesem Fall etwa 10 Sekunden und versuchen Sie dann erneut, den CLI-Befehl auszuführen, um den Zustand des Remotespeicherorts zu überprüfen. Wenn ein Speicherort getrennt ist, versuchen Sie es mit dem nächsten Schritt. Überprüfen Sie die Konnektivität zwischen dem lokalen Manager (LM) am Speicherort {site_name}{site_id} mit den LMs am Speicherort {remote_site_name}{remote_site_id}) mittels Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im WAN beeinträchtigt ist. Wenn keine Probleme mit der physischen Netzwerkkonnektivität vorliegen, versuchen Sie den nächsten Schritt. Überprüfen Sie die Datei /var/log/cloudnet/nsx-ccp.log auf den Manager-Knoten im lokalen Cluster am Speicherort {site_name}({site_id}, der den Alarm ausgelöst hat, um festzustellen, ob es sich um Site-übergreifende Kommunikationsfehler handelt. Suchen Sie außerdem nach Fehlermeldungen, die von der Teilkomponente nsx-appl-proxy in /var/log/syslog protokolliert wurden.
LM-zu-LM-Synchronisierung: Warnung	Mittel	Ab NSX-T Data Center 3.0.1. Synchronisation zwischen Remotespeicherorten fehlgeschlagen. Bei Erkennung des Ereignisses: „Die Synchronisierung zwischen {site_name}({site_id}) und {remote_site_name}({remote_site_id}) ist fehlgeschlagen.“ Bei Auflösung des Ereignisses: „Die Remote-Speicherorte {site_name}({site_id}) und {remote_site_name}({remote_site_id}) werden jetzt synchronisiert.“	Führen Sie den NSX-CLI-Befehl get site-replicator remote-sites aus, um den Verbindungszustand zwischen den Remotespeicherorten abzurufen. Wenn ein Remotespeicherort verbunden ist, aber nicht synchronisiert wird, befindet sich der Speicherort möglicherweise noch im Prozess der Auflösung des primären Knotens. Warten Sie in diesem Fall etwa 10 Sekunden und versuchen Sie dann erneut, den CLI-Befehl auszuführen, um den Zustand des Remotespeicherorts zu überprüfen. Wenn ein Speicherort getrennt ist, versuchen Sie es mit dem nächsten Schritt. Überprüfen Sie die Konnektivität zwischen dem lokalen Manager (LM) am Speicherort {site_name}{site_id} mit den LMs am Speicherort {remote_site_name}{remote_site_id}) mittels Ping. Wenn sie über einen Ping-Befehl nicht erreichbar sind, überprüfen Sie, ob die Konnektivität im WAN beeinträchtigt ist. Wenn keine Probleme mit der physischen Netzwerkkonnektivität vorliegen, versuchen Sie den nächsten Schritt. Überprüfen Sie die Datei /var/log/cloudnet/nsx-ccp.log auf den Manager-Knoten im lokalen Cluster am Speicherort {site_name}({site_id}, der den Alarm ausgelöst hat, um festzustellen, ob es sich um Site-übergreifende Kommunikationsfehler handelt. Suchen Sie außerdem nach Fehlermeldungen, die von der Teilkomponente nsx-appl-proxy in /var/log/syslog protokolliert wurden.
RTEP-BGP inaktiv	Hoch	Ab NSX-T Data Center 3.0.1. RTEP-BGP-Nachbar ist inaktiv. Bei Erkennung des Ereignisses: „Die RTEP(Remote Tunnel Endpoint)-BGP-Sitzung von der Quell-IP {bgp_source_ip} zum Remotespeicherort {remote_site_name} mit der Nachbar-IP {bgp_neighbor_ip} ist inaktiv.“ Bei Auflösung des Ereignisses: „Die RTEP(Remote Tunnel Endpoint)-BGP-Sitzung von der Quell-IP {bgp_source_ip} zum Remotespeicherort {remote_site_name} mit der Nachbar-IP {bgp_neighbor_ip} wurde eingerichtet.“	Führen Sie auf dem betroffenen Edge-Knoten den NSX-CLI-Befehl get logical-routers aus. Zum REMOTE_TUNNEL_VRF-Kontext wechseln Führen Sie den NSX-CLI-Befehl get bgp neighbor aus und überprüfen Sie den BGP-Nachbar: Rufen Sie alternativ die NSX API GET /api/v1/transport-nodes/<transport-node-id>/inter-site/bgp/summary auf, um den BGP-Nachbarstatus abzurufen. Führen Sie den NSX-CLI-Befehl get interfaces aus und prüfen Sie, ob der Schnittstelle mit dem Namen remote-tunnel-endpoint die korrekte RTEP-IP-Adresse zugewiesen ist. . Überprüfen Sie, ob der Ping-Befehl zwischen der zugewiesenen RTEP-IP-Adresse {bgp_source_ip} und dem Remotespeicherort {remote_site_name} Nachbar-IP {bgp_neighbor_ip} erfolgreich ausgeführt wird. Überprüfen Sie in /var/log/syslog, ob Fehler im Zusammenhang mit BGP vorliegen. Rufen Sie die API GET oder PUT /api/v1/transport-nodes/<transport-node-id> auf, um die remote_tunnel_endpoint-Konfiguration auf dem Edge-Knotens abzurufen bzw. zu aktualisieren. Dadurch wird die dem betroffenen Edge-Knoten zugewiesene RTEP-IP-Adresse aktualisiert.
GM-zu-LM-Synchronisierungswarnung	Mittel	Die Datensynchronisierung zwischen dem globalen Manager (GM) und dem lokalen Manager (LM) ist fehlgeschlagen. Bei Erkennung des Ereignisses: „Die Datensynchronisierung zwischen den Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) ist für den {flow_identifier} fehlgeschlagen.“ Bei Auflösung des Ereignisses: „Die Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) werden jetzt für {flow_identifier} synchronisiert.“	Prüfen Sie die Netzwerkkonnektivität zwischen der Remote-Site und der lokalen Site per Ping. Stellen Sie sicher, dass der Datenverkehr an Port TCP/1236 zwischen der lokalen Site und der Remote-Site zulässig ist. Stellen Sie sicher, dass der async-replicator-Dienst sowohl auf lokalen als auch auf Remote-Sites ausgeführt wird. Rufen Sie die GET /api/v1/node/services/async_replicator/status NSX API oder den NSX-CLI-Befehl get service async_replicator auf, um festzustellen, ob der Dienst ausgeführt wird. Wenn der Dienst nicht ausgeführt wird, rufen Sie die POST /api/v1/node/services/async_replicator?action=restart NSX API oder den NSX-CLI-Befehl restart service async_replicator auf, um den Dienst neu zu starten. Überprüfen Sie in /var/log/async-replicator/ar.log, ob Fehler gemeldet wurden.
GM-zu-LM-Synchronisierungsfehler	Hoch	Die Datensynchronisierung zwischen dem globalen Manager (GM) und dem lokalen Manager (LM) ist für einen längeren Zeitraum fehlgeschlagen. Bei Erkennung des Ereignisses: „Die Datensynchronisierung zwischen den Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) ist für den {flow_identifier} über einen längeren Zeitraum fehlgeschlagen.“ Bei Auflösung des Ereignisses: „Die Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) werden jetzt für {flow_identifier} synchronisiert.“	Prüfen Sie die Netzwerkkonnektivität zwischen der Remote-Site und der lokalen Site per Ping. Stellen Sie sicher, dass der Datenverkehr an Port TCP/1236 zwischen der lokalen Site und der Remote-Site zulässig ist. Stellen Sie sicher, dass der async-replicator-Dienst sowohl auf lokalen als auch auf Remote-Sites ausgeführt wird. Rufen Sie die GET /api/v1/node/services/async_replicator/status NSX API oder den NSX-CLI-Befehl get service async_replicator auf, um festzustellen, ob der Dienst ausgeführt wird. Wenn der Dienst nicht ausgeführt wird, rufen Sie die POST /api/v1/node/services/async_replicator?action=restart NSX API oder den NSX-CLI-Befehl restart service async_replicator auf, um den Dienst neu zu starten. Überprüfen Sie in /var/log/async-replicator/ar.log, ob Fehler gemeldet wurden. Erfassen Sie ein Support-Paket und wenden Sie sich an den VMware Support.
Schwellenwert für Warteschlangenbelegung überschritten	Mittel	Warnung, dass der Schwellenwert für die Belegung der Warteschlange überschritten wurde. Bei Erkennung des Ereignisses: „Die Warteschlange ({queue_name}), die für die Synchronisierung von Daten zwischen Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) verwendet wird, hat die Größe {queue_size} erreicht und ist damit größer oder gleich dem maximalen Schwellenwert von {queue_size_threshold} %.“ Bei Auflösung des Ereignisses: „Die Warteschlange ({queue_name}), die für die Synchronisierung von Daten zwischen Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) verwendet wird, hat die Größe {queue_size} erreicht und liegt damit unter dem maximalen Schwellenwert von {queue_size_threshold} %.“	Die Warteschlangengröße kann den Schwellenwert aufgrund eines Kommunikationsproblems mit der Remote-Site oder eines überlasteten Systems überschreiten. Überprüfen Sie die Systemleistung und stellen Sie anhand von /var/log/async-replicator/ar.log fest, ob Fehler gemeldet wurden.
GM-zu-LM-Latenzwarnung	Mittel	Die Latenz zwischen dem globalen Manager und dem lokalen Manager ist länger als erwartet und beträgt mehr als 2 Minuten. Bei Erkennung des Ereignisses: „Die Latenz zwischen Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) hat {latency_value} erreicht und liegt damit über dem Schwellenwert von {latency_threshold}.“ Bei Auflösung des Ereignisses: „Die Latenz zwischen Sites {site_name}({site_id}) und {remote_site_name}({remote_site_id}) hat {latency_value} erreicht und liegt damit unter dem Schwellenwert von {latency_threshold}.“	Prüfen Sie die Netzwerkkonnektivität zwischen der Remote-Site und der lokalen Site per Ping. Stellen Sie sicher, dass der Datenverkehr an Port TCP/1236 zwischen der lokalen Site und der Remote-Site zulässig ist. Überprüfen Sie in /var/log/async-replicator/ar.log, ob Fehler gemeldet wurden.
Cluster herabgestuft	Mittel	Gruppenmitglied ist nicht verfügbar. Bei Erkennung des Ereignisses: „Gruppenmitglied {manager_node_id} von {group_type} ist inaktiv.“ Bei Auflösung des Ereignisses: „Gruppenmitglied {manager_node_id} von {group_type} ist aktiv.“	Rufen Sie den NSX-CLI-Befehl get cluster status auf, um den Status der Gruppenmitglieder des Clusters anzuzeigen. Stellen Sie sicher, dass der Dienst für {group_type} auf dem Knoten ausgeführt wird. Rufen Sie die GET /api/v1/node/services/<service_name>/status NSX API oder den NSX-CLI-Befehl get service <service_name> auf, um festzustellen, ob der Dienst ausgeführt wird. Wenn der Dienst nicht ausgeführt wird, rufen Sie die POST /api/v1/node/services/<service_name>?action=restart NSX API oder den NSX-CLI-Befehl restart service <service_name> auf, um den Dienst neu zu starten. Überprüfen Sie anhand von /var/log/ für den Dienst {group_type}, ob Fehler gemeldet wurden.
Cluster nicht verfügbar	Hoch	Alle Gruppenmitglieder des Dienstes sind nicht verfügbar. Bei Erkennung des Ereignisses: „Alle Gruppenmitglieder {manager_node_ids} des Diensts {group_type} sind inaktiv.“ Bei Auflösung des Ereignisses: „Alle Gruppenmitglieder {manager_node_ids} des Diensts {group_type} sind aktiv.“	Stellen Sie sicher, dass der Dienst für {group_type} auf dem Knoten ausgeführt wird. Rufen Sie die GET /api/v1/node/services/<service_name>/status NSX API oder den NSX-CLI-Befehl get service <service_name> auf, um festzustellen, ob der Dienst ausgeführt wird. Wenn er nicht ausgeführt wird, rufen Sie die POST /api/v1/node/services/<service_name>?action=restart NSX API oder den NSX-CLI-Befehl restart service <service_name> auf, um den Dienst neu zu starten. Überprüfen Sie anhand von /var/log/ für den Dienst {group_type}, ob Fehler gemeldet wurden.

Kennwortverwaltungsereignisse

Kennwortverwaltungsereignisse stammen von den NSX Manager-, NSX Edge- und den öffentlichen Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Kennwort abgelaufen	Kritisch	Das Benutzerkennwort ist abgelaufen. Bei Erkennung des Ereignisses: „Das Kennwort für den Benutzer {username} ist abgelaufen.“ Bei Auflösung des Ereignisses: „Das Kennwort für den Benutzer {username} wurde erfolgreich geändert oder ist nicht länger abgelaufen.“	Das Kennwort für den Benutzer {username} muss jetzt geändert werden, um auf das System zugreifen zu können. Wenn Sie beispielsweise ein neues Kennwort für einen Benutzer anwenden möchten, rufen Sie die folgende NSX API mit einem gültigen Kennwort im Anforderungstext auf: PUT /api/v1/node/users/<userid> Dabei ist <userid> die ID des Benutzers. Wenn das Kennwort des Admin-Benutzers (mit <userid> 10000) abgelaufen ist, muss sich der Admin über SSH (sofern aktiviert) oder über die Konsole beim System anmelden, um das Kennwort zu ändern. Bei der Eingabe des aktuellen, abgelaufenen Kennworts wird der Admin aufgefordert, ein neues Kennwort einzugeben.
Kennwort läuft in Kürze ab	Hoch	Das Benutzerkennwort läuft in Kürze ab. Bei Erkennung des Ereignisses: „Das Kennwort für Benutzer {username} läuft in {password_expiration_days} Tagen ab.“ Bei Auflösung des Ereignisses: „Das Kennwort für Benutzer {username} wurde erfolgreich geändert oder läuft nicht mehr in Kürze ab.“	Stellen Sie sicher, dass das Kennwort für den durch {username} identifizierten Benutzer sofort geändert wird. Wenn Sie beispielsweise ein neues Kennwort für einen Benutzer anwenden möchten, rufen Sie die folgende NSX API mit einem gültigen Kennwort im Anforderungstext auf: PUT /api/v1/node/users/<userid> Dabei ist <userid> die ID des Benutzers.
Kennwortablauf steht bevor	Mittel	Das Benutzerkennwort läuft in Kürze ab. Bei Erkennung des Ereignisses: „Das Kennwort für Benutzer {username} läuft in {password_expiration_days} Tagen ab.“ Bei Auflösung des Ereignisses: „Das Kennwort für Benutzer {username} wurde erfolgreich geändert oder läuft nicht mehr in Kürze ab.“	Das Kennwort für den durch {username} identifizierten Benutzer muss in Kürze geändert werden. Wenn Sie beispielsweise ein neues Kennwort für einen Benutzer anwenden möchten, rufen Sie die folgende NSX API mit einem gültigen Kennwort im Anforderungstext auf: PUT /api/v1/node/users/<userid> Dabei ist <userid> die ID des Benutzers.

Routing-Ereignisse

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
BGP inaktiv	Hoch	Der BGP-Nachbar ist inaktiv. Bei Erkennung des Ereignisses: „Im Router {entity_id} ist der BGP-Nachbar {bgp_neighbor_ip} inaktiv, Grund: {failure_reason}.“ Bei Auflösung des Ereignisses: „Im Router {entity_id} ist der BGP-Nachbar {bgp_neighbor_ip} aktiv.“	SSH in den Edge-Knoten. Rufen Sie den NSX-CLI-Befehl auf: get logical-routers Wechseln Sie zum Dienstrouter {sr_id}. Überprüfen Sie /var/log/syslog, um festzustellen, ob Fehler bezüglich der BGP-Konnektivität vorliegen.
BFD auf externer Schnittstelle inaktiv	Hoch	Die BFD-Sitzung ist inaktiv. Bei Erkennung des Ereignisses: „Im Router {entity_id} ist die BFD-Sitzung für Peer {peer_address} inaktiv.“ Bei Auflösung des Ereignisses: „Im Router {entity_id} ist die BFD-Sitzung für Peer {peer_address} aktiv.“	Rufen Sie den NSX-CLI-Befehl get logical-routers auf. Wechseln Sie zum Dienstrouter {sr_id}. Führen Sie den NSX-CLI-Befehl ping {peer_address} aus und überprüfen Sie den Konnektivität.
Routing ausgefallen	Hoch	Alle BGP/BFD-Sitzungen sind inaktiv. Bei Erkennung des Ereignisses: „Alle BGP/BFD-Sitzungen sind inaktiv“. Bei Auflösung des Ereignisses: „Mindestens eine BGP/BFD-Sitzung ist aktiv“.	Rufen Sie den NSX-CLI-Befehl get logical-routers auf, um den Tier-0-Dienstrouter abzurufen. Wechseln Sie zur VRF des Tier-0-Dienstrouters und rufen Sie dann die folgenden NSX-CLI-Befehle auf: Überprüfen der Konnektivität: ping <BFD peer IP address> Überprüfen der BFD-Integrität: get bfd-config get bfd-sessions Überprüfen der BGP-Integrität: get bgp neighbor summary get bfd neconfig get bfd-sessions Überprüfen Sie /var/log/syslog, um festzustellen, ob Fehler bezüglich der BGP-Konnektivität vorliegen.
Statisches Routing entfernt	Hoch	Statische Route wurde entfernt. Bei Erkennung des Ereignisses: „Im Router {entity_id} wurde die statische Route {static_address} entfernt, weil BFD inaktiv war.“ Bei Auflösung des Ereignisses: „Im Router {entity_id} wurde die statische Route {static_address} wieder hinzugefügt, da BFD wiederhergestellt wurde.“	SSH in den Edge-Knoten. Rufen Sie den NSX-CLI-Befehl auf: get logical-routers Wechseln Sie zum Dienstrouter {sr_id}. Überprüfen Sie die Konnektivität, indem Sie den folgenden NSX-CLI-Befehl aufrufen: get bgp neighbor summary Überprüfen Sie außerdem die Konfiguration sowohl im NSX- als auch im BFD-Peer, um sicherzustellen, dass die Timer nicht geändert wurden.
Nicht übereinstimmende MTU innerhalb der Transportzone	Hoch	Nicht übereinstimmende MTU-Konfiguration zwischen Transportknoten (ESXi, KVM und Edge), die an dieselbe Transportzone angeschlossen sind. Wenn die MTU-Werte für alle Switches, die mit derselben Transportzone verbunden sind, nicht konsistent sind, verursacht das Verbindungsprobleme.	Navigieren Sie in der NSX-Benutzeroberfläche zuSystem > Fabric > Einstellungen und klicken Sie unter Prüfung der MTU-Konfiguration auf Inkonsistent, um weitere Details zu Nichtübereinstimmungen anzuzeigen. Legen Sie denselben MTU-Wert auf allen Switches fest, die an dieselbe Transportzone angehängt sind, indem Sie die NSX API PUT /api/v1/host-switch-profiles/<host-switch-profile-id> mit mtu im Anforderungstext oder die API PUT /api/v1/global-configs/SwitchingGlobalConfig mit physical_uplink_mtu im Anforderungstext aufrufen.
MTU des globalen Routers zu groß	Mittel	Die MTU-Konfiguration des globalen Routers ist größer als die MTU der Switches in der Overlay-Transportzone, die mit Tier0 oder Tier1 verbunden ist. Der MTU-Wert des globalen Routers sollte kleiner sein als der MTU-Wert aller Switches und mindestens 100 betragen, da wir für die Geneve-Kapselung ein Kontingent von 100 benötigen.	Navigieren Sie in der NSX-Benutzeroberfläche zuSystem > Fabric > Einstellungen und klicken Sie unter Prüfung der MTU-Konfiguration auf Inkonsistent, um weitere Details zu Nichtübereinstimmungen anzuzeigen. Legen Sie den größeren MTU-Wert auf Switches fest, indem Sie die NSX API PUT /api/v1/host-switch-profiles/<host-switch-profile-id> mit mtu im Anforderungstext oder die API PUT /api/v1/global-configs/SwitchingGlobalConfig mit physical_uplink_mtu im Anforderungstext aufrufen. Oder legen Sie den kleineren MTU-Wert der globalen Routerkonfiguration fest, indem Sie die NSX API PUT /api/v1/global-configs/RoutingGlobalConfig mit logical_uplink_mtu im Anforderungstext aufrufen.

Transportknotenintegrität

Transportknoten-Integritätsereignisse stammen aus den KVM- und ESXi-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
LAG-Mitglied inaktiv	Mittel	LACP meldet Mitglied als inaktiv. Bei Erkennung des Ereignisses: „LACP meldet Mitglied als inaktiv.“ Bei Auflösung des Ereignisses: „LACP meldet Mitglied als aktiv.“	Überprüfen Sie den Verbindungsstatus der LAG-Mitglieder auf den Hosts. Navigieren Sie in der NSX-Benutzeroberfläche zu Fabric > Knoten > Transportknoten > Host-Transportknoten. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte „Knotenstatus“. Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus. Wählen Sie <Transportknoten> > Überwachen aus. Finden Sie die Bindung (Uplink), die als herabgestuft oder inaktiv gemeldet wird. Überprüfen Sie die Statusdetails der LACP-Mitglieder, indem Sie sich bei dem fehlgeschlagenen Host anmelden und den entsprechenden Befehl ausführen: ESXi: esxcli network vswitch dvs vmware lacp status get KVM: ovs-appctl bond/show und ovs-appctl lacp/show
Transportknoten-Uplink deaktiviert	Mittel	Uplink wird inaktiv. Bei Erkennung des Ereignisses: „Uplink wird inaktiv.“ Bei Auflösung des Ereignisses: „Uplink wird aktiv.“	Überprüfen Sie den Status der physischen Netzwerkkarten von Uplinks auf Hosts. Navigieren Sie in der NSX-Benutzeroberfläche zu Fabric > Knoten > Transportknoten > Host-Transportknoten. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte Knotenstatus. Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus. Wählen Sie <Transportknoten> > Überwachen aus. Überprüfen Sie die Statusdetails der Bindung (Uplink), die als herabgestuft oder inaktiv gemeldet wird. Stellen Sie zum Vermeiden eines herabgestuften Zustands sicher, dass alle Uplink-Schnittstellen verbunden und aktiv sind. Dabei ist es unerheblich, ob sie verwendet werden oder nicht.

VPN-Ereignisse

VPN-Ereignisse stammen von den NSX Edge- und den öffentlichen Gateway-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Auf IPSec-Richtlinie basierende Sitzung ausgefallen	Mittel	Die richtlinienbasierte IPSec-VPN-Sitzung ist ausgefallen. Bei Erkennung des Ereignisses: „Die richtlinienbasierte IPSec-VPN-Sitzung {entity_id} ist inaktiv. Grund: {session_down_reason}.“ Bei Auflösung des Ereignisses: „Die richtlinienbasierte IPSec-VPN-Sitzung {entity_id} ist aktiv.“	Überprüfen Sie die IPsec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund für die inaktive Sitzung.
Auf IPSec-Route basierende Sitzung ausgefallen	Mittel	Die routenbasierte IPSec-VPN-Sitzung ist ausgefallen. Bei Erkennung des Ereignisses: „Die routenbasierte IPSec-VPN-Sitzung {entity_id} ist inaktiv. Grund: {session_down_reason}.“ Bei Auflösung des Ereignisses: „Die routenbasierte IPSec-VPN-Sitzung {entity_id} ist aktiv.“	Überprüfen Sie die IPsec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund für die inaktive Sitzung.
Auf IPSec-Richtlinie basierender Tunnel ausgefallen	Mittel	Die richtlinienbasierten IPSec-VPN-Tunnel sind ausgefallen. Bei Erkennung des Ereignisses: „Mindestens ein richtlinienbasierter IPSec-VPN-Tunnel in der Sitzung {entity_id} ist inaktiv.“ Bei Erkennung des Ereignisses: „Alle richtlinienbasierten IPSec-VPN-Tunnel in der Sitzung {entity_id} sind aktiv.“	Überprüfen Sie die IPSec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund für den inaktiven Tunnel.
Auf IPSec-Route basierender Tunnel ausgefallen	Mittel	Die routenbasierten IPSec-VPN-Tunnel sind ausgefallen. Bei Erkennung des Ereignisses: „Mindestens ein routenbasierter IPSec-VPN-Tunnel in der Sitzung {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Alle routenbasierten IPSec-VPN-Tunnel in der Sitzung {entity_id} sind aktiv.“	Überprüfen Sie die IPSec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund für den inaktiven Tunnel.
L2VPN-Sitzung ausgefallen	Mittel	L2VPN-Sitzung ist inaktiv. Bei Erkennung des Ereignisses: „Die L2VPN-Sitzung {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Die L2VPN-Sitzung {entity_id} ist aktiv.“	Überprüfen Sie die IPSec-VPN-Sitzungskonfiguration und beheben Sie Fehler basierend auf dem Grund.
IPSec-Dienst ausgefallen	Mittel	IPSec-Dienst ist ausgefallen. Um den Grund für den Ausfall des Diensts anzuzeigen, klicken Sie auf den Link Laufzeitdetails anzeigen. Bei Erkennung des Ereignisses: „Der IPSec-Dienst {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Der IPSec-Dienst {entity_id} ist aktiv.“	Deaktivieren und aktivieren Sie den IPSec-Dienst über die NSX Manager-Benutzeroberfläche. Wenn das Problem weiterhin besteht, wenden Sie sich an den VMware Support.