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

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

Die maximale Kapazität einer Objektkategorie wurde erreicht. Die Alarmdetails geben die betroffene Objektkategorie an.

Nehmen Sie Anpassungen an den entsprechenden Konfigurationen vor, um potenziell negativen Folgen vorzubeugen.

Schwellenwert für Maximalkapazität Hoch

Der Grenzwert für die maximale Kapazität einer Objektkategorie wurde erreicht. Die Alarmdetails geben die betroffene Objektkategorie an.

Wenn dieser Alarm erwartet wurde, nehmen Sie Anpassungen der entsprechenden Konfigurationen vor, um den Alarm zu beheben. Wenn dieser Alarm unerwartet auftritt, passen Sie den Schwellenwert für die Objektkategorie an.

Schwellenwert für Mindestkapazität Mittel

Der Schwellenwert für die minimale Kapazität einer Objektkategorie wurde erreicht. Die Alarmdetails geben die betroffene Objektkategorie an.

Wenn dieser Alarm erwartet wurde, nehmen Sie gegebenenfalls Anpassungen der entsprechenden Konfigurationen vor, um den Alarm zu beheben. Wenn dieser Alarm unerwartet auftritt, passen Sie den Schwellenwert für die Objektkategorie an.

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 die angegebene DNS-Weiterleitung aus, die derzeit aktiviert ist.“

Bei Auflösung des Ereignisses: „Die DNS-Weiterleitung {entity_id} wird erneut ausgeführt.“

  1. Rufen Sie den NSX-CLI-Befehl get dns-forwarders status auf, um zu überprüfen, ob die DNS-Weiterleitung den Status „inaktiv“ aufweist.
  2. Überprüfen Sie /var/log/syslog, um festzustellen, ob Fehler gemeldet wurden.
  3. Erfassen Sie ein Support-Paket und wenden Sie sich an das NSX-Supportteam.
Weiterleitung deaktiviert 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.“

  1. Rufen Sie den NSX-CLI-Befehl get dns-forwarders status auf, um zu überprüfen, ob die DNS-Weiterleitung den Status „deaktiviert“ aufweist.
  2. 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:
  1. Melden Sie sich als Root-Benutzer an.
  2. Rufen Sie den Befehl edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show auf.
  3. Überprüfen Sie, ob die Nutzung des Nachbar-Caches normal ist.
    1. 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:
  1. 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:
  1. 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.

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 logischem Router {entity_id} liegt unterhalb des hohen Schwellenwerts von {system_usage_threshold} %.“

  1. 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
  2. Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist.
  3. 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} %.“

  1. 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
  2. Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist.
  3. 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} %.“

  1. 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
  2. Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist.
  3. 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} %.“

  1. 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
  2. Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist.
  3. 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} %.“

  1. 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
  2. Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist.
  3. 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} %.“

  1. 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
  2. Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist.
  3. 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.“

  1. 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
  2. Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist.
  3. 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.“

  1. 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
  2. Überprüfen Sie, ob der Datenverkehrsfluss, der über das Gateway fließt, kein DOS-Angriff oder anomaler Burst ist.
  3. 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.“

Bestimmen Sie den inaktiven Dienst und starten Sie ihn neu.
  1. Identifizieren Sie die Tier-0-VRF-ID, indem Sie den NSX-CLI-Befehl get logical-routers ausführen.
  2. Wechseln Sie zum VRF-Kontext, indem Sie vrf <vrf-id> ausführen.
  3. 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.
  1. Identifizieren Sie die Tier-1-VRF-ID, indem Sie den NSX-CLI-Befehl get logical-routers ausführen.
  2. Wechseln Sie zum VRF-Kontext, indem Sie vrf <vrf-id> ausführen.
  3. 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.“

  1. Melden Sie sich mithilfe von SSH beim Edge-Knoten an.
  2. Rufen Sie den Status ab.
    nsxcli get tunnel-ports
  3. Überprüfen Sie in jedem Tunnel die Statistiken auf Drops.
    get tunnel-port <UUID> stats
  4. Ü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.

  1. Starten Sie den Nachrichtendienst neu, wenn er nicht im NSX Intelligence-Knoten ausgeführt wird.
  2. Beheben Sie den Netzwerkverbindungsfehler zwischen dem Transportknoten und dem NSX Intelligence-Knoten.
Steuerungskanal zum Transportknoten inaktiv Mittel 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.

  1. Ü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 die Netzwerkkonnektivität.
  2. Ü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/.
  3. 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

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.

  1. Ü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.
  2. Ü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/.
  3. 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.

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:
    1. Navigieren Sie in der NSX-Benutzeroberfläche zu Netzwerk > IP-Adresspools > IP-Adresspools.
    2. Wählen Sie IP-Pools aus, in denen der IP-Block verwendet wird. Prüfen Sie die Spalten Subnetze und Zugewiesene IPs.
    3. 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.

  1. Navigieren Sie in der NSX-Benutzeroberfläche zu Netzwerk > IP-Adresspools > IP-Adresspools.
  2. 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:
  1. Navigieren Sie in der NSX-Benutzeroberfläche zu System > Lizenzen.
  2. Klicken Sie auf Hinzufügen und geben Sie den Schlüssel für die neue Lizenz an.
  3. 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:
  1. Navigieren Sie in der NSX-Benutzeroberfläche zu System > Lizenzen.
  2. Klicken Sie auf Hinzufügen und geben Sie den Schlüssel für die neue Lizenz an.
  3. 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-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.

LB-Status inaktiv

Kritisch

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

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

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

  1. Prüfen Sie den Load Balancer-Pool, um zu ermitteln, welche Mitglieder inaktiv sind.
  2. Überprüfen Sie die Netzwerkkonnektivität zwischen dem Load Balancer und den betroffenen Poolmitgliedern.
  3. Validieren Sie die Anwendungsintegrität der einzelnen Poolmitglieder.
  4. 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.

LB-Status herabgestuft

Mittel

Ab NSX-T Data Center 3.1.2

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:
    1. 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
    2. 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.
  • Für verteilte Load Balancer:
  1. Erhalten Sie einen detaillierten Status, indem Sie die folgende NSX API aufrufen.

    GET /policy/api/v1/infra/lb-services/<LBService>/detailed-status?source=realtime
  2. Suchen Sie in der API-Ausgabe den ESXi-Host, der eine Instanznummer ungleich null mit dem Status NOT_READY oder CONFLICT meldet.
  3. 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

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

  1. Rufen Sie auf dem ESXi-Hostknoten den folgenden NSX-CLI-Befehl auf.

    get load-balancer <lb-uuid> status
  2. 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

Kritisch

Ab NSX-T Data Center 3.1.2

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} %.“

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.

LB-Pool-Mitgliedskapazität in Verwendung sehr hoch

Kritisch

Ab NSX-T Data Center 3.1.2

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.

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

  1. 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.
  2. Überprüfen Sie, ob der Pool/DHCP-Server für die statische IP-Adresse ordnungsgemäß konfiguriert ist.
  3. 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:
  1. Ü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.

  2. Ü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.
  3. Ü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:
  1. Überprüfen Sie die Netzwerkverbindungen zwischen den virtuellen Maschinen und beheben Sie Netzwerkprobleme.
  2. Ü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:

  1. Wenn Vmk50 fehlt, schlagen Sie im Knowledgebase-Artikel 67432 nach.
  2. Wenn Hyperbus 4094 fehlt: das Neustarten von nsx-cfgagent oder der Containerhost-VM kann helfen.
  3. Wenn die VIF des Container-Hosts blockiert ist, prüfen Sie die Verbindung mit dem Controller, um sicherzustellen, dass alle Konfigurationen heruntergefahren werden.
  4. Wenn nsx-cfgagent angehalten wurde, starten Sie nsx-cfgagent neu.

Für KVM:

  1. Wenn der Hyperbus-Namespace fehlt, kann ein Neustart von nsx-opsagent dabei helfen, den Namespace neu zu erstellen.
  2. Wenn die Hyperbus-Schnittstelle innerhalb des Hyperbus-Namespace fehlt, kann ein Neustart von nsx-opsagent hilfreich sein.
  3. Wenn nsx-agent angehalten wurde, starten Sie nsx-agent neu.

Sowohl für ESX als auch für KVM:

  1. Wenn das node-agent-Paket fehlt: Überprüfen Sie, ob das node-agent-Paket erfolgreich auf der VM des Container-Hosts installiert wurde.
  2. 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

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.

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

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

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

Steuerungskanal zum Transportknoten ist zu lang inaktiv

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

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

  3. Ü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}.

  1. Führen Sie auf dem betroffenen Edge-Knoten den NSX-CLI-Befehl get logical-routers aus.

  2. Zum Kontext REMOTE_TUNNEL_VRF wechseln
  3. Führen Sie den NSX-CLI-Befehl get bgp neighbor aus und überprüfen Sie den BGP-Nachbar:
  4. Rufen Sie alternativ die NSX-API GET /api/v1/transport-nodes/<transport-node-id>/inter-site/bgp/summary auf, um den BGP-Nachbarstatus abzurufen.
  5. 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.
  6. . Ü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.
  7. Prüfen Sie, ob /var/log/syslog etwaige Fehler im Zusammenhang mit BGP enthält.
  8. 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.

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 Administratorbenutzers (mit <userid> 10000) abgelaufen ist, muss sich der Administrator ü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 Administrator 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.“

  1. SSH in den Edge-Knoten.
  2. Rufen Sie den NSX-CLI-Befehl auf: get logical-routers
  3. Wechseln Sie zum Dienstrouter {sr_id}.
  4. Ü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.“

  1. SSH in den Edge-Knoten.
  2. Rufen Sie den NSX-CLI-Befehl auf: get logical-routers
  3. Wechseln Sie zum Dienstrouter {sr_id}.
  4. Ü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“.

  1. Rufen Sie den NSX-CLI-Befehl get logical-routers auf, um den Tier-0-Dienstrouter abzurufen.
  2. 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.“

  1. SSH in den Edge-Knoten.
  2. Rufen Sie den NSX-CLI-Befehl auf: get logical-routers
  3. Wechseln Sie zum Dienstrouter {sr_id}.
  4. Überprüfen Sie die Konnektivität, indem Sie den folgenden NSX-CLI-Befehl aufrufen:
    get bgp neighbor summary
  5. Ü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.
  1. Navigieren Sie in der NSX-Benutzeroberfläche zu Fabric > Knoten > Transportknoten > Host-Transportknoten.
  2. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte „Knotenstatus“.

    Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus.

  3. Wählen Sie <Transportknoten> > Überwachen aus.

    Finden Sie die Bindung (Uplink), die als herabgestuft oder inaktiv gemeldet wird.

  4. Ü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.
  1. Navigieren Sie in der NSX-Benutzeroberfläche zu Fabric > Knoten > Transportknoten > Host-Transportknoten.
  2. Überprüfen Sie in der Liste „Host-Transportknoten“ die Spalte „Knotenstatus“.

    Suchen Sie den Transportknoten mit herabgestuftem oder inaktivem Knotenstatus.

  3. 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
Verbindung mit LDAP-Server ist unterbrochen

Kritisch

Die Verbindung zum LDAP-Server ist unterbrochen.

Bei Erkennung des Ereignisses: Die Verbindung zum LDAP-Server konnte nicht hergestellt werden.

Bei Erkennung des Ereignisses: Die Verbindung zum LDAP-Server wurde erfolgreich hergestellt.

Führen Sie die folgenden Schritte aus, um die Verbindung zum LDAP-Server zu überprüfen:

  1. Der LDAP-Server ist von NSX-Knoten aus erreichbar.
  2. Die LDAP-Serverdetails sind korrekt in NSX konfiguriert.
  3. Der LDAP-Server wird ordnungsgemäß ausgeführt.
  4. Der Zugriff zwischen dem LDAP-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 LDAP-Server zu testen.

Fehler bei der Deltasynchronisierung

Kritisch

Fehler bei der Deltasynchronisierung mit AD-Domäne

Bei Erkennung des Ereignisses: Deltasynchronisierung wurde mit Fehler abgeschlossen.

Bei Erkennung des Ereignisses: Deltasynchronisierung wurde ohne Fehler abgeschlossen.

Wenn der Alarm
Verbindung zum LDAP-Server ist unterbrochen
ausgelöst wird, beheben Sie diesen Alarm.

Wenn die Verbindung mit dem LDAP-Server hergestellt ist, befolgen Sie die Fehlermeldung im Protokoll, um die zugehörigen Änderungen im AD-Server zu überprüfen.