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 grafische Benutzeroberfläche (GUI) von NSX und die NSX API GET /api/v1/alarm melden keine neuen Alarme mehr. Syslog-Einträge und SNMP-Traps (sofern aktiviert) werden jedoch immer noch ausgegeben und melden die zugrunde liegenden Ereignisdetails. Wenn die Ursachen für die hohe Anzahl von 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 Maßnahme 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.

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
CPU-Auslastung der verteilten Firewall sehr hoch	Kritisch	Die CPU-Auslastung der verteilten Firewall 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 DNS-Weiterleitung {entity_id} wird erneut ausgeführt.“	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.
Arbeitsspeicherauslastung der verteilten Firewall sehr hoch	Kritisch	Die Arbeitsspeicherauslastung der verteilten Firewall 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.

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 alle konfigurierten DNS-Weiterleitungen aus, die derzeit aktiviert sind.“ 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	Hoch	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-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 Dienstausführung 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 Dienstausführung 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 Edge-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.
Edge-Datenpfad-CPU-Auslastung 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.
Crypto-Treiber des Edge-Datenpfads inaktiv	Kritisch	Der Crypto-Treiber des Datenpfads auf dem Edge-Knoten ist inaktiv. Bei Erkennung des Ereignisses: „Der Crypto-Treiber des Edge-Knotens ist inaktiv.“ Bei Auflösung des Ereignisses: „Der Crypto-Treiber des Edge-Knotens ist aktiv.“	Aktualisieren Sie den Edge-Knoten nach Bedarf.
Arbeitsspeicherpool des Edge-Datenpfads ist hoch	Mittel	Die Auslastung des Arbeitsspeicherpools des Datenpfads auf dem Edge-Knoten 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 ist damit größer als der Schwellenwert für eine hohe Nutzung.“ Bei Auflösung des Ereignisses: „Die globale ARP-Tabellennutzung auf dem Edge-Knoten {entity-id} liegt nun unter dem hohen Schwellenwert.“	Vergrößern Sie die ARP-Tabelle: Melden Sie sich als Root-Benutzer an. Rufen Sie den Befehl edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show auf. Überprüfen Sie, ob die Nutzung des Nachbar-Caches normal ist. Wenn sie normal ist, rufen Sie den Befehl edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries auf, um die ARP-Tabelle zu vergrößern.
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 Dienstausführung 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 Dienstausführung 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	Kritisch	Empfangsdeskriptor-Ringpuffer der Netzwerkkarte des Edge-Knotens hat keinen Speicherplatz mehr. Bei Erkennung des Ereignisses: „Empfangs-Ringpuffer der Edge-Netzwerkkarte {edge_nic_name} wurde über einen Zeitraum von mehr als 60 Sekunden um {rx_ring_buffer_overflow_percentage} % auf dem Edge-Knoten {entity-id} überschritten.“ Bei Auflösung des Ereignisses: „Empfangs-Ringpuffer der Edge-Netzwerkkarte {edge_nic_name} auf dem Edge-Knoten {entity-id} wird nicht mehr überschritten.“	Rufen Sie den NSX-CLI-Befehl get dataplane auf und überprüfen Sie Folgendes: Wenn die PPS- und CPU-Auslastungen hoch sind, überprüfen Sie die RX-Ringgröße durch einen Aufruf von get dataplane | find ring-size rx. Wenn die PPS- und CPU-Auslastungen hoch sind und die RX-Ringgröße niedrig ist, rufen Sie set dataplane ring-size rx <ring-size> auf und legen Sie set <ring-size> auf einen höheren Wert fest, um eingehende Pakete unterzubringen. Wenn die obige Bedingung nicht erfüllt ist und die Ringgröße hoch und die CPU-Auslastung immer noch hoch ist, kann die Ursache auf eine Overhead-Verzögerung bei der Datenebenenverarbeitung zurückzuführen sein.
Übertragungspuffer der Edge-Netzwerkkarte überschritten	Kritisch	Übertragungsdeskriptor-Ringpuffer der Netzwerkkarte des Edge-Knotens hat keinen Speicherplatz mehr. Bei Erkennung des Ereignisses: „Übertragungs-Ringpuffer der Edge-Knoten-Netzwerkkarte {edge_nic_name} wurde über einen Zeitraum von mehr als 60 Sekunden um {tx_ring_buffer_overflow_percentage} % auf dem Edge-Knoten {entity-id} überschritten.“ Bei Auflösung des Ereignisses: „Die Übertragungs-Ringpuffernutzung für die Edge-Knoten-Netzwerkkarte {edge_nic_name} auf dem Edge-Knoten {entity-id} wird nicht mehr überschritten.“	Rufen Sie den NSX-CLI-Befehl get dataplane auf und überprüfen Sie Folgendes: Wenn die PPS- und CPU-Auslastungen hoch sind, überprüfen Sie die RX-Ringgröße durch einen Aufruf von get dataplane | find ring-size tx. Wenn die PPS- und CPU-Auslastungen hoch sind und die TX-Ringgröße niedrig ist, rufen Sie set dataplane ring-size tx <ring-size> auf und legen Sie set <ring-size> auf einen höheren Wert fest, um ausgehende Pakete unterzubringen. Wenn die obige Bedingung nicht erfüllt ist und die Ringgröße hoch und die CPU-Auslastung gering oder normal ist, kann die Ursache auf die Einstellung der Übertragungs-Ringgröße auf dem Hypervisor zurückzuführen sein.
Speicherfehler	Kritisch	Ab NSX-T Data Center 3.0.1. Die folgenden Festplattenpartitionen auf dem Edge-Knoten befinden sich 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 hierzu finden Sie im Knowledgebase-Artikel https://kb.vmware.com/s/article/2146870.

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.

Verbundereignisse

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

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
LM-zu-LM-Synchronisierung: Fehler	Hoch	Ab NSX-T Data Center 3.0.1. Die Synchronisierung zwischen {site_name}({site_id} und {remote_site_name}({remote_site_id} ist für mehr als 5 Minuten fehlgeschlagen.	Führen Sie den NSX-CLI-Befehl get site-replicator remote-sites aus, um den Verbindungszustand zwischen den Remotespeicherorten abzurufen. Wenn ein Remotespeicherort verbunden, aber nicht synchronisiert ist, kann es sein, dass sich der Speicherort noch im Prozess der Masterauflösung befindet. 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. Die Synchronisierung zwischen {site_name}({site_id} und {remote_site_name}({remote_site_id} ist fehlgeschlagen.	Führen Sie den NSX-CLI-Befehl get site-replicator remote-sites aus, um den Verbindungszustand zwischen den Remotespeicherorten abzurufen. Wenn ein Remotespeicherort verbunden, aber nicht synchronisiert ist, kann es sein, dass sich der Speicherort noch im Prozess der Masterauflösung befindet. 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. Die RTEP-BGP-Sitzung von der Quell-IP {bgp_source_ip} mit dem Remotespeicherort {remote_site_name} Nachbar-IP {bgp_neighbor_ip} ist ausgefallen. Grund: {failure_reason}.	Führen Sie auf dem betroffenen Edge-Knoten den NSX-CLI-Befehl get logical-routers aus. Zum Kontext REMOTE_TUNNEL_VRF 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 Oberfläche 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. Prüfen Sie, ob /var/log/syslog etwaige Fehler im Zusammenhang mit BGP enthält. Führen Sie API GET oder PUT /api/v1/transport-nodes/<transport-node-id> aus, um die remote_tunnel_endpoint-Konfiguration vom Edge-Knoten abzurufen bzw. auf dem Edge-Knoten zu aktualisieren. Dadurch wird die dem betroffenen Edge-Knoten zugewiesene RTEP-IP-Adresse aktualisiert.

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.“	Bestimmen Sie den inaktiven Dienst und starten Sie ihn neu. Identifizieren Sie die Tier-0-VRF-ID, indem Sie den NSX-CLI-Befehl get logical-routers ausführen. Wechseln Sie zum VRF-Kontext, indem Sie vrf <vrf-id> ausführen. Zeigen Sie den inaktiven Dienst an, indem Sie get high-availability status ausführen.
Tier1-Gateway-Failover	Hoch	Ein Tier-1-Gateway hat ein Failover durchgeführt. Bei Erkennung des Ereignisses: „Für das Tier-1-Gateway {Entitäts-ID} wurde ein Failover von {previous_gateway_state} auf {current_gateway_state} vorgenommen.“ Bei Auflösung des Ereignisses: „Das Tier-1-Gateway {entity-id} ist jetzt aktiv.“	Bestimmen Sie den inaktiven Dienst und starten Sie ihn neu. Identifizieren Sie die Tier-1-VRF-ID, indem Sie den NSX-CLI-Befehl get logical-routers ausführen. Wechseln Sie zum VRF-Kontext, indem Sie vrf <vrf-id> ausführen. Zeigen Sie den inaktiven Dienst an, indem Sie get high-availability status ausführen.

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: „Gesamttunnelstatus des Edge-Knotens {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Die Tunnel des Edge-Knotens {entity_id} wurden wiederhergestellt.“	Melden Sie sich mithilfe von SSH beim Edge-Knoten an. Rufen Sie den Status ab. nsxcli get tunnel-ports Überprüfen Sie in jedem Tunnel die Statistiken auf Drops. get tunnel-port <UUID> stats Überprüfen Sie die syslog-Datei auf tunnelbezogene Fehler.

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	Kritisch	Der Edge-Dienst ist mindestens eine Minute lang inaktiv. 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	Niedrig	Der Status des Edge-Diensts hat sich geändert. 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-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.

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	Kritisch	Der Steuerungskanal zum Transportknoten ist inaktiv. Bei Erkennung des Ereignisses: Controller-Dienst central_control_plane_id zum Transportknoten {entity-id} aus Sicht des Controller-Dienstes für mindestens drei Minuten inaktiv. Bei Auflösung des Ereignisses: Controller-Dienst central_control_plane_id stellt die Verbindung zum Transportknoten {entity-id} wieder her.	Überprüfen Sie die Konnektivität der Schnittstelle des Controller-Dienstes central_control_plane_id und des Transportknotens {entity-id} mit einem Ping-Befehl. 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 {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: 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 Transportknoten ist zu lang inaktiv	Warnung	Der Steuerungskanal zum Transportknoten ist zu lang inaktiv. Bei Erkennung des Ereignisses: Controller-Dienst central_control_plane_id zu Transportknoten {entity-id} ist aus Sicht des Controller-Dienstes seit mindestens 15 Minuten inaktiv. Bei Auflösung des Ereignisses: Controller-Dienst central_control_plane_id stellt die Verbindung zum Transportknoten {entity-id} wieder her.	Überprüfen Sie die Konnektivität der Schnittstelle des Controller-Dienstes central_control_plane_id und des Transportknotens {entity-id} mit einem Ping-Befehl. 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 {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.
Verwaltungskanal für den Transportknoten ist nicht verfügbar	Kritisch	Trennung der Verbindung vom Manager-Knoten zum Transportknoten. Bei Erkennung des Ereignisses: Bei Auflösung des Ereignisses	Stellen Sie sicher, dass die Netzwerkkonnektivität zwischen den Manager-Knoten und dem Transportknoten nodename (IP) vorhanden ist und dass keine Firewalls den Datenverkehr zwischen diesen Knoten blockieren. Stellen Sie sicher, dass der nsx-proxy-Dienst auf dem Transportknoten ausgeführt wird, indem Sie den folgenden Befehl ausführen. /etc/init.d/nsx-prxy status Wenn der nsx-proxy-Dienst nicht ausgeführt wird, starten Sie ihn neu, indem Sie den folgenden Befehl ausführen. /etc/init.d/nsx-proxy restart
Managerkontrollkanal ist nicht verfügbar	Kritisch	Der Kanal zwischen Manager und Controller ist nicht verfügbar. Bei Erkennung des Ereignisses: Bei Auflösung des Ereignisses:	Führen Sie auf dem Manager-Knoten managernode (IP) die beiden folgenden NSX CLI-Befehle aus: restart service mgmt-plane-bus restart service manage

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>.

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	Bei Erkennung des Ereignisses: „Die Lizenz vom Typ {license_edition_type} läuft demnächst 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 stammen vom NSX Edge-Knoten.

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
CPU-Auslastung durch den Load Balancer sehr hoch	Mittel	Die CPU-Auslastung durch den Load Balancer ist sehr hoch. Bei Erkennung des Ereignisses: „Die CPU-Auslastung durch den Load Balancer {entity_id} beträgt {system_resource_usage} % und liegt damit über dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“ Bei Auflösung des Ereignisses: „Die CPU-Auslastung durch den Load Balancer {entity_id} beträgt {system_resource_usage} % und liegt damit unter dem Schwellenwert für eine sehr hohe Nutzung von {system_usage_threshold} %.“	Wenn die CPU-Nutzung durch den Load Balancer mehr als {system_usage_threshold} % beträgt, 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.
Status des Load Balancers inaktiv	Mittel	Der Load Balancer-Dienst ist inaktiv. Bei Erkennung des Ereignisses: „Der Load Balancer-Dienst {entity_id} ist inaktiv.“ Bei Auflösung des Ereignisses: „Der Load Balancer-Dienst {entity_id} ist aktiv.“	Überprüfen Sie, ob der Load Balancer-Dienst im Edge-Knoten ausgeführt wird. Wenn der Status des Load Balancer-Diensts nicht „Bereit“ ist, versetzen Sie den Edge-Knoten in den Wartungsmodus und beenden Sie dann den Wartungsmodus. Wenn der Status des Load Balancer-Diensts immer noch nicht wiederhergestellt wurde, prüfen Sie, ob in der syslog-Datei ein Fehlerprotokoll enthalten ist.
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	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 die Integrität des Mitglieds hergestellt wird, wird der Status des Poolmitglieds basierend auf der Anzahl bis zum erneuten Versuch auf „fehlerfrei“ aktualisiert.

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: „Der Manager-Knoten {entity_id} 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} %.“	Untersuchen Sie die Partition /config und prüfen Sie, ob unerwartete große Dateien vorhanden sind, die entfernt werden können.
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 für die Festplattenpartition /nonconfig des Manager-Knotens hat {system_resource_usage}% erreicht und ist damit größer als der Schwellenwert {system_usage_threshold}% oder gleicht ihm. Dies kann ein Hinweis auf eine steigende Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis /nonconfig/corfu sein.	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 für die Festplattenpartition /nonconfig des Manager-Knotens hat {system_resource_usage}% erreicht und ist damit größer als der sehr hohe Schwellenwert {system_usage_threshold}% oder gleicht ihm. Dies kann ein Hinweis auf eine steigende Festplattennutzung durch den NSX-Datenspeicherdienst im Verzeichnis /nonconfig/corfu sein.	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.“	Rufen Sie zum Auffinden der problembehafteten Cluster die NSX API GET /api/v1/systemhealth/container-cluster/ncp/status auf, um alle Clusterstatus abzurufen und den Namen der Cluster zu ermitteln, die INAKTIV oder UNBEKANNT sind. Navigieren Sie auf der NSX-Benutzeroberfläche zu Bestand > Container > Cluster, um die Namen der Cluster zu finden, die den Status INAKTIV oder UNBEKANNT gemeldet haben, und klicken Sie auf die Registerkarte „Knoten“. Dort werden alle Kubernetes- und PAS-Cluster-Mitglieder aufgelistet. Für Kubernetes-Cluster: Überprüfen Sie die NCP-Pod-Aktivität, indem Sie den K8s-Master-Knoten unter sämtlichen Cluster-Mitgliedern finden, und melden Sich sich beim Master-Knoten an. 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 prü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 Master-VM die folgenden Befehle abrufen. 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 Master-VM den folgenden Befehl abrufen. 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 NCP-Konfigurationen. 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.

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.
Bidirektionale Weiterleitungserkennung (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.“	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: ping <peer_address>.
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.

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
N-VDS-Uplink inaktiv	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.

Ereignisse der identitätsbasierten Firewall

Ereignisname	Schweregrad	Warnmeldung	Empfohlene Aktion
Konnektivität zum AD-Server	Kritisch	Die Verbindung zum AD-Server ist unterbrochen. Bei Erkennung des Ereignisses: Die Verbindung zum Identitäts-Firewall-AD-Server ist getrennt. Bei Erkennung des Ereignisses: Die Verbindung zum Identitäts-Firewall-AD-Server ist hergestellt.	Der AD-Server ist von NSX-Knoten aus erreichbar. Die AD-Serverdetails sind korrekt in NSX konfiguriert. Der AD-Server wird ordnungsgemäß ausgeführt. Der Zugriff zwischen dem AD-Server und NSX-Knoten wird nicht durch Firewalls blockiert. Nachdem das Problem behoben ist, führen Sie auf der Benutzeroberfläche des LDAP-Servers „TESTVERBINDUNG“ aus, um die Verbindung zum AD-Server zu testen.
Fehler bei der Deltasynchronisierung	Kritisch	Fehler beim Synchronisieren des AD-Servers: error description Bei Erkennung des Ereignisses: Fehler während der selektiven Synchronisierung des Identitäts-Firewall-AD-Servers: error details. Bei Erkennung des Ereignisses: Selektive Synchronisierungsfehler des Identitäts-Firewall-AD-Servers wurden behoben.	Überprüfen Sie, ob der Load Balancer-Dienst im Edge-Knoten ausgeführt wird. Wenn der Status des Load Balancer-Diensts nicht „Bereit“ ist, versetzen Sie den Edge-Knoten in den Wartungsmodus und beenden Sie dann den Wartungsmodus. Wenn der Status des Load Balancer-Dienstes immer noch nicht wiederhergestellt wurde, prüfen Sie, ob in der syslog-Datei ein Fehlerprotokoll enthalten ist.