Les tableaux suivants décrivent les événements qui déclenchent des alarmes, y compris les messages d'alarme et les actions recommandées pour les résoudre. Tout événement d'une gravité supérieure à FAIBLE déclenche une alarme.

Événements de gestion des alarmes

Les événements de gestion des alarmes proviennent des nœuds NSX Manager et du gestionnaire global.

Nom de l'événement Gravité Message d'alerte Action recommandée
Service d'alarme surchargé Critique

Le service d'alarme est surchargé.

Lorsque l'événement est détecté : « En raison d'un volume important d'alarmes signalé, le service d'alarme est temporairement surchargé. L'interface utilisateur de NSX et NSX API GET /api/v1/alarm ont arrêté de signaler de nouvelles alarmes. Les entrées Syslog et les interruptions SNMP (si elles sont activées) sont toujours émises en signalant les informations de l'événement sous-jacent. Lorsque les problèmes sous-jacents entraînant un volume important d'alarmes sont résolus, le service d'alarme recommence à signaler de nouvelles alarmes. »

Lorsque l'événement est résolu : « Le volume important d'alarmes est sous-présent et les nouvelles alarmes sont de nouveau signalées. »

Vérifiez toutes les alarmes actives sur la page Alarmes dans l'interface utilisateur de NSX ou à l'aide de NSX API GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED. Pour chaque alarme active, analysez la cause principale en suivant l'action recommandée pour l'alarme. Lorsqu'un nombre suffisant d'alarmes est résolu, le service d'alarme commencera à signaler de nouveau de nouvelles alarmes.

Volume d'alarmes important Critique

Volume important d'un type d'alarme spécifique détecté.

Lorsque l'événement est détecté : « En raison d'un volume important d'alarmes {event_id}, le service d'alarme a temporairement arrêté de signaler des alarmes de ce type. L'interface utilisateur de NSX et NSX API GET /api/v1/alarms ne signalent pas de nouvelles instances de ces alarmes. Les entrées Syslog et les interruptions SNMP (si elles sont activées) sont toujours émises en signalant les informations de l'événement sous-jacent. Lorsque les problèmes sous-jacents entraînant un volume important d'alarmes {event_id} sont résolus, le service d'alarme commence à signaler de nouvelles alarmes {event_id} lorsque de nouveaux problèmes sont détectés à nouveau. »

Lorsque l'événement est résolu : « Le volume important d'alarmes {event_id} a diminué et de nouvelles alarmes de ce type sont à nouveau signalées. »

Vérifiez toutes les alarmes actives sur la page Alarmes dans l'interface utilisateur de NSX ou à l'aide de NSX API GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED. Pour chaque alarme active, analysez la cause principale en suivant l'action recommandée pour l'alarme. Lorsqu'un nombre suffisant d'alarmes est résolu, le service d'alarme commencera à signaler de nouveau de nouvelles alarmes {event_id}.

Événements liés à la capacité

Les événements suivants peuvent déclencher des alarmes lorsque l'inventaire actuel de certaines catégories d'objets atteint un certain niveau. Pour plus d'informations, reportez-vous à la section Afficher l'utilisation et la capacité des catégories d'objets.

Nom de l'événement Gravité Message d'alerte Action recommandée
Capacité maximale Critique

La capacité maximale d'une catégorie d'objets a été atteinte. Les détails de l'alarme indiquent la catégorie d'objets spécifique.

Ajustez les configurations appropriées afin d'éviter toute conséquence négative.

Seuil de capacité maximal Élevé

Le seuil de capacité maximal d'une catégorie d'objets a été atteint. Les détails de l'alarme indiquent la catégorie d'objets spécifique.

Si cette alarme est attendue, ajustez les configurations appropriées pour résoudre l'alarme. Si cette alarme est inattendue, ajustez la valeur de seuil de la catégorie d'objets.

Seuil de capacité minimal Moyenne

Le seuil de capacité minimal d'une catégorie d'objets a été atteint. Les détails de l'alarme indiquent la catégorie d'objets spécifique.

Si cette alarme est attendue, ajustez les configurations appropriées pour résoudre l'alarme si nécessaire. Si cette alarme est inattendue, ajustez la valeur de seuil de la catégorie d'objets.

Événements de certificats

Des événements de certificat proviennent du nœud NSX Manager.

Nom de l'événement Gravité Message d'alerte Action recommandée
Certificat expiré Critique

Un certificat a expiré.

Lorsque l'événement est détecté : « Le certificat {entity-id} a expiré. »

Lorsque l'événement est résolu : « Le certificat expiré {entity-id} a été supprimé ou n'a plus expiré.

Assurez-vous que les services qui utilisent actuellement le certificat sont mis à jour afin d'utiliser un nouveau certificat non expiré. Par exemple, pour appliquer un nouveau certificat au service HTTP, appelez l'appel d'API suivant :

POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<cert-id>

<cert-id> est l'ID d'un certificat valide signalé par l'appel d'API GET /api/v1/trust-management/certificates.

Une fois que le certificat expiré n'est plus utilisé, il doit être supprimé à l'aide de l'appel d'API suivant :

DELETE /api/v1/trust-management/certificates/{entity_id}

Certificat sur le point d'expirer Élevé

Un certificat est sur le point d'expirer

Lorsque l'événement est détecté : « Le certificat {entity-id} est sur le point d'expirer. »

Lorsque l'événement est résolu : « Le certificat arrivant à expiration {entity-id} ou n'est plus sur le point d'expirer. »

Assurez-vous que les services qui utilisent actuellement le certificat sont mis à jour pour utiliser un nouveau certificat non expiré. Par exemple, pour appliquer un nouveau certificat au service HTTP, appelez l'appel d'API suivant :

POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<cert-id>

<cert-id> est l'ID d'un certificat valide signalé par l'appel d'API GET /api/v1/trust-management/certificates.

Une fois que le certificat arrivant à expiration n'est plus utilisé, il doit être supprimé à l'aide de l'appel d'API :

DELETE /api/v1/trust-management/certificates/{entity_id}

Expiration du certificat approchant Moyenne

Un certificat approche de son expiration.

Lorsque l'événement est détecté : « Le certificat {entity-id} approche de son expiration. »

Lorsque l'événement est résolu : « Le certificat arrivant à expiration {entity-id} ou n'approche plus de son expiration. »

Assurez-vous que les services qui utilisent actuellement le certificat sont mis à jour pour utiliser un nouveau certificat non expiré. Par exemple, pour appliquer un nouveau certificat au service HTTP, appelez l'appel d'API suivant :

POST /api/v1/node/services/http?action=apply_certificate&certificate_id=<cert-id>

<cert-id> est l'ID d'un certificat valide signalé par l'appel d'API GET /api/v1/trust-management/certificates.

Une fois que le certificat arrivant à expiration n'est plus utilisé, il doit être supprimé à l'aide de l'appel d'API :

DELETE /api/v1/trust-management/certificates/{entity_id}

Événements de santé de CNI

Les événements de santé de CNI proviennent des nœuds ESXi et KVM.

Nom de l'événement Gravité Message d'alerte Action recommandée
Connexion Hyperbus Manager inactive Moyenne

Hyperbus ne peut pas communiquer avec le nœud de gestionnaire.

Lorsque l'événement est détecté : « Hyperbus ne peut pas communiquer avec le nœud de gestionnaire. »

Lorsque l'événement est résolu : « Hyperbus peut communiquer avec le nœud de gestionnaire. »

L'interface Hyperbus vmkernel (vmk50) est peut-être manquante. Reportez-vous à Knowledge Base article 67432.

Événements DHCP

Les événements DHCP proviennent des nœuds NSX Edge et de passerelle publique.

Nom de l'événement Gravité Message d'alerte Action recommandée
Échec de l'allocation de bail du pool Élevé

Les adresses IP d'un pool d'adresses IP ont été épuisées.

Lorsque l'événement est détecté : « Les adresses du pool d'adresses IP {entity_id} du serveur DHCP {dhcp_server_id} ont été épuisées. La dernière demande DHCP a échoué et les futures demandes échoueront. »

Lorsque l'événement est résolu : « Le pool d'adresses IP {entity_id} du serveur DHCP {dhcp_server_id} n'est plus épuisé. Un bail a été alloué à la dernière demande DHCP. »

Vérifiez la configuration du pool DHCP dans l'interface utilisateur de NSX ou sur le nœud Edge sur lequel le serveur DHCP s'exécute en appelant la commande get dhcp ip-pool de l'interface de ligne de commande NSX.

Vérifiez également les baux actifs actuels sur le nœud Edge en appelant la commande get dhcp lease de l'interface de ligne de commande NSX.

Comparez les baux au nombre de VM actives. Pensez à réduire la durée du bail sur la configuration du serveur DHCP si le nombre de VM est faible par rapport au nombre de baux actifs. Pensez également à développer la plage de pools pour le serveur DHCP en consultant la page Mise en réseau > Segments > Segment de l'interface utilisateur de NSX.

Pool surchargé Moyenne

Un pool d'adresses IP est surchargé.

Lorsque l'événement est détecté : « L'utilisation du pool d'adresses IP {entity_id} du serveur DHCP {dhcp_server_id} approche de l'épuisement avec {dhcp_pool_usage} % d'adresses IP allouées. »

Lorsque l'événement est résolu : « Le pool d'adresses IP {entity_id} du serveur DHCP {dhcp_server_id} est tombé en dessous du seuil d'utilisation élevé. »

Vérifiez la configuration du pool DHCP dans l'interface utilisateur de NSX ou sur le nœud Edge sur lequel le serveur DHCP s'exécute en appelant la commande get dhcp ip-pool de l'interface de ligne de commande NSX.

Vérifiez également les baux actifs actuels sur le nœud Edge en appelant la commande get dhcp lease de l'interface de ligne de commande NSX.

Comparez les baux au nombre de VM actives. Pensez à réduire la durée du bail sur la configuration du serveur DHCP si le nombre de VM est faible par rapport au nombre de baux actifs. Pensez également à développer la plage de pools pour le serveur DHCP en consultant la page Mise en réseau > Segments > Segment de l'interface utilisateur de NSX.

Événements de pare-feu distribué

Des événements de pare-feu distribué proviennent des nœuds NSX Manager ou ESXi.

Nom de l'événement Gravité Message d'alerte Action recommandée
Utilisation très élevée du CPU du pare-feu distribué Critique

L'utilisation du CPU du pare-feu distribué est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU de DFW sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « Le redirecteur DNS {entity_id} s'exécute de nouveau. »

Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

Vérifiez la conception de la sécurité pour l'optimisation. Par exemple, utilisez la configuration applicable si les règles ne s'appliquent pas à l'ensemble du centre de données.

Utilisation très élevée de la mémoire du pare-feu distribué Critique

L'utilisation de la mémoire du pare-feu distribué est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire de DFW {heap_type} sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire de DFW {heap_type} sur le nœud de transport {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %. »

Affichez l'utilisation actuelle de la mémoire DFW en appelant la commande get firewall thresholds de l'interface de ligne de commande NSX sur l'hôte.

Pensez à rééquilibrer les charges de travail sur cet hôte vers d'autres hôtes.

Événements DNS

Les événements DNS proviennent des nœuds NSX Edge et de passerelle publique.

Nom de l'événement Gravité Message d'alerte Action recommandée
Redirecteur inactif Élevé

Un redirecteur DNS est inactif.

Lorsque l'événement est détecté : « Le redirecteur DNS {entity_id} n'est pas en cours d'exécution. Cela affecte le redirecteur DNS identifié actuellement activé. »

Lorsque l'événement est résolu : « Le redirecteur DNS {entity_id} s'exécute de nouveau. »

  1. Appelez la commande get dns-forwarders status de l'interface de ligne de commande NSX pour vérifier si le redirecteur DNS se trouve dans un état inactif.
  2. Vérifiez /var/log/syslog pour voir si des erreurs sont signalées.
  3. Collectez un bundle de support et contactez l'équipe du support NSX.
Redirecteur désactivé Faible

Un redirecteur DNS est désactivé.

Lorsque l'événement est détecté : « Le redirecteur DNS {entity_id} est désactivé. »

Lorsque l'événement est résolu : « Le redirecteur DNS {entity_id} est activé. »

  1. Appelez la commande get dns-forwarders status de l'interface de ligne de commande NSX pour vérifier si le redirecteur DNS se trouve dans un état désactivé.
  2. Utilisez l'API de stratégie NSX ou l'API de gestionnaire pour activer le redirecteur DNS qui ne doit pas être dans l'état désactivé.

Événements de santé du dispositif Edge

Les événements de santé du dispositif Edge proviennent de NSX Edge et des nœuds de passerelle publique.

Nom de l'événement Gravité Message d'alerte Action recommandée
Utilisation très élevée du CPU Edge Critique

L'utilisation du CPU du nœud Edge est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %. »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud Edge. Pensez à ajuster la taille du format du dispositif Edge ou à rééquilibrer les services vers d'autres nœuds Edge pour la charge de travail applicable.
Utilisation élevée du CPU Edge Moyenne

L'utilisation du CPU du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %. »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud Edge. Pensez à ajuster la taille du format du dispositif Edge ou à rééquilibrer les services vers d'autres nœuds Edge pour la charge de travail applicable.
Échec de la configuration du chemin de données Edge Élevé

La configuration du chemin de données du nœud Edge a échoué.

Lorsque l'événement est détecté : « Échec de l'activation du chemin de données sur le nœud Edge après trois tentatives. »

Lorsque l'événement est résolu : « Le chemin de données sur le nœud Edge a été correctement activé. »

Vérifiez que la connexion du nœud Edge au nœud de gestionnaire est saine.

Dans l'interface de ligne de commande NSX du nœud Edge, appelez la commande get services pour vérifier la santé des services.

Si le service du plan de données est arrêté, appelez la commande start service dataplane pour le redémarrer.

Utilisation très élevée du CPU du chemin de données Edge Critique

L'utilisation du CPU du chemin de données du nœud Edge est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du chemin de données sur le nœud Edge {entity-id} a atteint {datapath_resource_usage} %, ce qui est supérieur ou égal au seuil très élevé pendant au moins deux minutes. »

Lorsque l'événement est résolu : « L'utilisation du CPU du chemin de données sur le nœud Edge {entity-id} est passée sous le seuil maximal. »

Vérifiez les statistiques du CPU sur le nœud Edge en appelant la commande get dataplane cpu stats NSX pour afficher les taux de paquets par cœur de CPU.

Une utilisation plus élevée du CPU est attendue avec des taux de paquets supérieurs.

Pensez à augmenter la taille du format du dispositif Edge et à rééquilibrer les services sur ce nœud Edge vers d'autres nœuds Edge dans le même cluster ou dans d'autres clusters Edge.

Utilisation élevée du CPU du chemin de données Edge Moyenne

L'utilisation du CPU du chemin de données du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU du chemin données sur le nœud Edge {entity-id} a atteint {datapath_resource_usage} %, ce qui est supérieur ou égal au seuil élevé pendant au moins deux minutes. »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud Edge {entity-id} est passée sous le seuil élevé. »

Vérifiez les statistiques du CPU sur le nœud Edge en appelant la commande get dataplane cpu stats NSX pour afficher les taux de paquets par cœur de CPU.

Une utilisation plus élevée du CPU est attendue avec des taux de paquets supérieurs.

Pensez à augmenter la taille du format du dispositif Edge et à rééquilibrer les services sur ce nœud Edge vers d'autres nœuds Edge dans le même cluster ou dans d'autres clusters Edge.

Pilote de cryptographie du chemin de données Edge inactif Critique

Le pilote de cryptographie du chemin de données du nœud Edge est inactif.

Lorsque l'événement est détecté : « Le pilote de cryptographie du nœud Edge est inactif. »

Lorsque l'événement est résolu : « Le pilote de cryptographie du nœud Edge est actif. »

Mettez à niveau le nœud Edge si nécessaire.

Le pool de mémoire du chemin de données Edge est élevé Moyenne

Le pool de mémoire du chemin de données du nœud Edge est élevé.

Lorsque l'événement est détecté : « L'utilisation du pool de mémoires du chemin de données pour {mempool_name} sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du pool de mémoires du chemin de données pour {mempool_name} sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %. »

Connectez-vous en tant qu'utilisateur racine et appelez les commandes edge-appctl -t /var/run/vmware/edge/dpd.ctl mempool/show et edge-appctl -t /var/run/vmware/edge/dpd.ctl memory/show malloc_heap pour vérifier l'utilisation de la mémoire DPDK.
Utilisation très élevée du disque Edge Critique

L'utilisation du disque du nœud Edge est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque {disk_partition_name} du nœud Edge a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque {disk_partition_name} du nœud Edge a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %. »

Examinez la partition ayant une utilisation élevée et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.
Utilisation élevée du disque Edge Moyenne

L'utilisation du disque du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque {disk_partition_name} du nœud Edge a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque {disk_partition_name} du nœud Edge a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %. »

Examinez la partition ayant une utilisation élevée et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.
Utilisation de la table ARP globale Edge élevée Moyenne

L'utilisation de la table ARP globale du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation de la table ARP globale sur le nœud Edge {entity-id} a atteint {datapath_resource_usage} %, ce qui est supérieur au seuil élevé pendant plus de deux minutes. »

Lorsque l'événement est résolu : « L'utilisation de la table ARP globale sur le nœud Edge {entity-id} est passée sous le seuil élevé. »

Augmentez la taille de la table ARP :
  1. Connectez-vous en tant qu'utilisateur racine.
  2. Appelez la commande edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show.
  3. Vérifiez si l'utilisation du cache neigh est normale.
    1. Si elle est normale, appelez la commande edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries pour augmenter la taille de la table ARP.
Utilisation très élevée de la mémoire Edge Critique

L'utilisation de la mémoire du nœud Edge est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %. »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud Edge. Pensez à ajuster la taille du format du dispositif Edge ou à rééquilibrer les services vers d'autres nœuds Edge pour la charge de travail applicable.
Utilisation élevée de la mémoire Edge Moyenne

L'utilisation de la mémoire du nœud Edge est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud Edge {entity-id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %. »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud Edge. Pensez à ajuster la taille du format du dispositif Edge ou à rééquilibrer les services vers d'autres nœuds Edge pour la charge de travail applicable.
État de liaison de la carte réseau Edge inactif Critique

La liaison de la carte réseau du nœud Edge est inactive.

Lorsque l'événement est détecté : « La liaison de la carte réseau du nœud Edge {edge_nic_name} est inactive. »

Lorsque l'événement est détecté : « La liaison de la carte réseau du nœud Edge {edge_nic_name} est active. »

Sur le nœud Edge, confirmez que la liaison de la carte réseau est physiquement inactive en appelant la commande get interfaces de l'interface de ligne de commande NSX.

Si elle est inactive, vérifiez la connexion du câble.

Mémoire tampon de réception insuffisante de la carte réseau Edge Critique

La mémoire tampon d'anneau du descripteur de réception de la carte réseau du nœud Edge ne dispose plus de suffisamment d'espace.

Lorsque l'événement est détecté : « La mémoire tampon d'anneau de réception de la carte réseau Edge {edge_nic_name} a été dépassée de {rx_ring_buffer_overflow_percentage} % sur le nœud Edge {entity-id} pendant plus de 60 secondes. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire tampon de l'anneau de réception de la carte réseau Edge {edge_nic_name} sur le nœud Edge {entity-id} ne dépasse plus. »

Appelez la commande get dataplane de l'interface de ligne de commande NSX et vérifiez les points suivants :
  1. Si l'utilisation du PPS et du CPU est élevée et vérifiez la taille de l'anneau de réception à l'aide de get dataplane | find ring-size rx.
    • Si le PPS et le CPU sont élevés et si la taille de l'anneau de réception est basse, appelez set dataplane ring-size rx <ring-size>, et set <ring-size> sur une valeur plus élevée afin d'intégrer les paquets entrants.
    • Si la condition ci-dessus n'est pas remplie, que la taille de l'anneau est élevée et que l'utilisation du CPU reste élevée, cela peut être dû à un retard de la capacité supplémentaire de traitement du plan de données.
Mémoire tampon de transmission insuffisante de la carte réseau Edge Critique

La mémoire tampon d'anneau du descripteur de transmission de la carte réseau du nœud Edge ne dispose plus de suffisamment d'espace.

Lorsque l'événement est détecté : « La mémoire tampon d'anneau de transmission de la carte réseau du nœud Edge {edge_nic_name} a dépassé de {tx_ring_buffer_overflow_percentage} % sur le nœud Edge {entity-id} pendant plus de 60 secondes. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire tampon de l'anneau de transmission de la carte réseau du nœud Edge {edge_nic_name} sur le nœud Edge {entity-id} ne dépasse plus. »

Appelez la commande get dataplane de l'interface de ligne de commande NSX et vérifiez les points suivants :
  1. Si l'utilisation du PPS et du CPU est élevée et vérifiez la taille de l'anneau de réception à l'aide de get dataplane | find ring-size tx.
    • Si le PPS et le CPU sont élevés et si la taille de l'anneau de transmission est basse, appelez set dataplane ring-size tx <ring-size>, et set <ring-size> sur une valeur plus élevée afin d'intégrer les paquets sortants.
    • Si la condition ci-dessus n'est pas remplie, que la taille de l'anneau est élevée et que l'utilisation du CPU est faible ou nominale, la cause peut être due au paramètre de taille de l'anneau de transmission sur l'hyperviseur.
Erreur de stockage Critique

À partir de NSX-T Data Center 3.0.1.

Les partitions de disque suivantes sur le nœud Edge sont en lecture seule : {disk_partition_name}

.

Examinez la partition en lecture seule pour savoir si le redémarrage résout le problème ou si vous devez remplacer le disque. Reportez-vous à l'article de la base de connaissances https://kb.vmware.com/s/article/2146870.

Événements de protection du point de terminaison

Les événements de protection du point de terminaison proviennent des nœuds NSX Manager ou ESXi.

Nom de l'événement Gravité Message d'alerte Action recommandée
État d'EAM inactif Critique

Le service ESX Agent Manager (EAM) sur un gestionnaire de calcul est inactif.

Lorsque l'événement est détecté : « Le service EAM (ESX Agent Manager) sur le gestionnaire de calcul {entity_id} est inactif. »

Lorsque l'événement est résolu : « Le service ESX Agent Manager (EAM) sur le gestionnaire de calcul {entity_id} est activé ou le gestionnaire de calcul {entity_id} a été supprimé. »

Redémarrez le service ESX Agent Manager (EAM) :
  • Connectez-vous via SSH au nœud vCenter et exécutez :
    service vmware-eam start
Canal de partenaire inactif Critique

La connexion du module hôte et de la SVM du partenaire est inactive.

Lorsque l'événement est détecté : « La connexion entre le module hôte et la SVM partenaire {entity_id} est inactive. »

Lorsque l'événement est résolu : « La connexion entre le module hôte et la SVM partenaire {entity_id} est active. »

Reportez-vous à l'article 2148821 de la base de connaissances Dépannage de NSX Guest Introspection et assurez-vous que la SVM partenaire identifiée par {entity_id} est reconnectée au module hôte.

Événements de pare-feu de passerelle

Les événements de pare-feu de passerelle proviennent de nœuds NSX Edge.

Nom de l'événement Gravité Message d'alerte Action recommandée

Nombre de flux ICMP dépassé

Critique À partir de NSX-T Data Center 3.1.3.

La table de flux du pare-feu de passerelle pour le trafic ICMP a dépassé le seuil défini. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsqu'un événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour ICMP sur le routeur logique {entity_id} a atteint {firewall_icmp_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale. »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

  1. Connectez-vous en tant qu'administrateur sur le nœud Edge et appelez la commande CLI NSX suivante en utilisant l'UUID d'interface de droite et en vérifiant l'utilisation de la table de flux pour les flux ICMP.

    get firewall <LR_INT_UUID> interface stats | json
  2. Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale.
  3. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.
Nombre de flux ICMP élevé Moyenne À partir de NSX-T Data Center 3.1.3.

L'utilisation de la table de flux du pare-feu de passerelle pour le trafic ICMP est élevée. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsqu'un événement est détecté :« L'utilisation de la table de flux du pare-feu de passerelle pour ICMP sur le routeur logique {entity_id} a atteint {firewall_icmp_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale. »

Lorsque l'événement est résolu :« L'utilisation de la table de flux du pare-feu de passerelle pour ICMP sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

  1. Connectez-vous en tant qu'administrateur sur le nœud Edge et appelez la commande CLI NSX suivante en utilisant l'UUID d'interface de droite et en vérifiant l'utilisation de la table de flux pour les flux ICMP.

    get firewall <LR_INT_UUID> interface stats | json
  2. Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale.
  3. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.
Nombre de flux IP dépassé Critique À partir de NSX-T Data Center 3.1.3.

La table de flux du pare-feu de passerelle pour le trafic IP a dépassé le seuil défini. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsqu'un événement est détecté :« L'utilisation de la table de flux du pare-feu de passerelle pour le trafic IP sur le routeur logique {entity_id} a atteint {firewall_ip_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale. »

Lorsque l'événement est résolu :« L'utilisation de la table de flux du pare-feu de passerelle sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

  1. Connectez-vous en tant qu'administrateur sur le nœud Edge et appelez la commande CLI NSX en utilisant l'UUID d'interface de droite et en vérifiant l'utilisation de la table de flux pour les flux IP.

    get firewall <LR_INT_UUID> interface stats | json
  2. Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale.
  3. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.
Nombre de flux IP élevé Moyenne À partir de NSX-T Data Center 3.1.3.

L'utilisation de la table de flux du pare-feu de passerelle pour le trafic IP est élevée. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale

Lorsqu'un événement est détecté :« L'utilisation de la table de flux du pare-feu de passerelle pour IP sur le routeur logique {entity_id} a atteint {firewall_ip_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale. »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour les flux non-IP sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

  1. Connectez-vous en tant qu'administrateur sur le nœud Edge et appelez la commande CLI NSX en utilisant l'UUID d'interface de droite et en vérifiant l'utilisation de la table de flux pour les flux IP.

    get firewall <LR_INT_UUID> interface stats | json
  2. Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale.
  3. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.
Nombre de flux TCP dépassé Critique À partir de NSX-T Data Center 3.1.3.

La table de flux du pare-feu de passerelle pour le trafic semi-ouvert TCP a dépassé le seuil défini. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsque l'événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour le trafic semi-ouvert TCP sur le routeur logique {entity_id} a atteint {firewall_halfopen_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale. »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

  1. Connectez-vous en tant qu'administrateur sur le nœud Edge et appelez la commande CLI NSX en utilisant l'UUID d'interface de droite et en vérifiant l'utilisation de la table de flux pour les flux semi-ouverts TCP.

    get firewall <LR_INT_UUID> interface stats | json
  2. Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale.
  3. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.
Nombre de flux TCP élevé Moyenne À partir de NSX-T Data Center 3.1.3.

L'utilisation de la table de flux du pare-feu de passerelle pour le trafic semi-ouvert TCP est élevée. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsqu'un événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour TCP sur le routeur logique {entity_id} a atteint {firewall_halfopen_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale. »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle pour TCP semi-ouvert sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

  1. Connectez-vous en tant qu'administrateur sur le nœud Edge et appelez la commande CLI NSX en utilisant l'UUID d'interface de droite et en vérifiant l'utilisation de la table de flux pour les flux semi-ouverts TCP.

    get firewall <LR_INT_UUID> interface stats | json
  2. Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale.
  3. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.
Nombre de flux UDP dépassé Critique À partir de NSX-T Data Center 3.1.3.

La table de flux du pare-feu de passerelle pour le trafic UDP a dépassé le seuil défini. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsqu'un événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour UDP sur le routeur logique {entity_id} a atteint {firewall_udp_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale. »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée. »

  1. Connectez-vous en tant qu'administrateur sur le nœud Edge et appelez la commande CLI NSX en utilisant l'UUID d'interface de droite et en vérifiant l'utilisation de la table de flux pour les flux UDP.

    get firewall <LR_INT_UUID> interface stats | json
  2. Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale.
  3. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.
Nombre de flux UDP élevé Moyenne À partir de NSX-T Data Center 3.1.3.

L'utilisation de la table de flux du pare-feu de passerelle pour le trafic UDP est élevée. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale.

Lorsqu'un événement est détecté : « L'utilisation de la table de flux du pare-feu de passerelle pour UDP sur le routeur logique {entity_id} a atteint {firewall_udp_flow_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Les nouveaux flux seront abandonnés par le pare-feu de passerelle lorsque l'utilisation atteint la limite maximale. »

Lorsque l'événement est résolu : « L'utilisation de la table de flux du pare-feu de passerelle sur le routeur logique {entity_id} est inférieure à la valeur de seuil élevée. »

  1. Connectez-vous en tant qu'administrateur sur le nœud Edge et appelez la commande CLI NSX en utilisant l'UUID d'interface de droite et en vérifiant l'utilisation de la table de flux pour les flux UDP.

    get firewall <LR_INT_UUID> interface stats | json
  2. Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale.
  3. Si le trafic semble être dans la charge normale, mais que le seuil d'alarme est atteint, envisagez d'augmenter le seuil d'alarme ou d'acheminer le nouveau trafic vers un autre nœud Edge.

Événements de haute disponibilité

Des événements de haute disponibilité proviennent de NSX Edge et des nœuds de passerelle de cloud public.

Nom de l'événement Gravité Message d'alerte Action recommandée
Basculement de la passerelle de niveau 0 Élevé

Une passerelle de niveau 0 a basculé.

Lorsque l'événement est détecté : « Basculement de la passerelle de niveau 0 {entity-id} de {previous_gateway_state} à {current_gateway_state}. »

Lorsque l'événement est résolu : « La passerelle de niveau 0 {entity-id} est désormais active. »

Déterminez le service inactif et redémarrez-le.
  1. Identifiez l'ID de VRF de niveau 0 en exécutant la commande get logical-routers de l'interface de ligne de commande NSX.
  2. Basculez sur le contexte VRF en exécutant vrf <vrf-id>.
  3. Affichez le service inactif en exécutant get high-availability status.
Basculement de la passerelle de niveau 1 Élevé

Une passerelle de niveau 1 a basculé.

Lorsque l'événement est détecté : « Basculement de la passerelle de niveau 1 {entity-id} de {previous_gateway_state} à {current_gateway_state}. »

Lorsque l'événement est résolu : « La passerelle de niveau 1 {entity-id} est maintenant active. »

Déterminez le service inactif et redémarrez-le.
  1. Identifiez l'ID de VRF de niveau 1 en exécutant la commande get logical-routers de l'interface de ligne de commande NSX.
  2. Basculez sur le contexte VRF en exécutant vrf <vrf-id>.
  3. Affichez le service inactif en exécutant get high-availability status.

Événements de communication de l'infrastructure

Les événements de communication de l'infrastructure proviennent des nœuds NSX Edge, KVM, ESXi et de passerelle publique.

Nom de l'événement Gravité Message d'alerte Action recommandée
Tunnels Edge inactifs Critique

L'état du tunnel d'un nœud Edge est inactif.

Lorsque l'événement est détecté : « L'état du tunnel global du nœud Edge {entity_id} est inactif. »

Lorsque l'événement est résolu : « Les tunnels du nœud Edge {entity_id} ont été restaurés. »

  1. À l'aide de SSH, connectez-vous au nœud Edge.
  2. Obtenez l'état.
    nsxcli get tunnel-ports
  3. Sur chaque tunnel, vérifiez les statistiques pour chaque abandon.
    get tunnel-port <UUID> stats
  4. Recherchez dans le fichier syslog les erreurs liées au tunnel.

Événements de service d'infrastructure

Les événements de service d'infrastructure proviennent des nœuds NSX Edge et de passerelle publique.

Nom de l'événement Gravité Message d'alerte Action recommandée
État du service Edge inactif Critique

Le service Edge est inactif pendant au moins une minute.

Lorsque l'événement est détecté : « Le service {edge_service_name} est inactif pendant au moins une minute. »

Lorsque l'événement est résolu : « Le service {edge_service_name} est actif. »

Sur le nœud Edge, vérifiez que le service n'est pas fermé en raison d'une erreur en examinant les fichiers de vidage de mémoire dans le répertoire /var/log/core.

Pour confirmer que le service est arrêté, appelez la commande get services de l'interface de ligne de commande NSX.

Si c'est le cas, exécutez start service <service-name> pour redémarrer le service.

État du service Edge modifié Faible

État du service Edge modifié.

Lorsque l'événement est détecté : « Le service {edge_service_name} est passé de {previous_service_state} à {current_service_state}. »

Lorsque l'événement est résolu : « Le service {edge_service_name}est passé de {previous_service_state} à {current_service_state}. »

Sur le nœud Edge, vérifiez que le service n'est pas fermé en raison d'une erreur en examinant les fichiers de vidage de mémoire dans le répertoire /var/log/core.

Pour confirmer que le service est arrêté, appelez la commande get services de l'interface de ligne de commande NSX.

Si c'est le cas, exécutez start service <service-name> pour redémarrer le service.

Événements de communication d'Intelligence

Les événements de communication de NSX Intelligence proviennent du nœud NSX Manager, du nœud ESXi et du dispositif NSX Intelligence.

Nom de l'événement Gravité Message d'alerte Action recommandée
L'exportateur de flux du nœud de transport est déconnecté Élevé

Un nœud de transport est déconnecté de son broker de messagerie de nœud Intelligence. Cela affecte la collecte de données.

Lorsque l'événement est détecté : « L'exportateur de flux sur le nœud de transport {entity-id} est déconnecté du Broker de messagerie du nœud Intelligence. Cela affecte la collecte de données. »

Lorsque l'événement est résolu : « L'exportateur de flux sur le nœud de transport {entity-id} est reconnecté au Broker de messagerie du nœud Intelligence. »

  1. Redémarrez le service de messagerie s'il n'est pas en cours d'exécution dans le nœud NSX Intelligence.
  2. Résolvez l'échec de la connexion réseau entre le nœud de transport et le nœud NSX Intelligence.
Canal de contrôle vers le nœud de transport inactif Moyenne Canal de contrôle vers le nœud de transport inactif.

Lorsque l'événement est détecté : le service de contrôleur central_control_plane_id vers le nœud de transport {entity-id} est inactif pendant au moins trois minutes du point de vue des services de contrôleur.

Lorsque l'événement est résolu : le service de contrôleur central_control_plane_id restaure la connexion au nœud de transport {entity-id}.

  1. Vérifiez la connectivité à partir du service de contrôleur central_control_plane_id et l'interface du nœud de transport {entity-id} à l'aide de la commande ping. Si la commande ping n'est pas possible, vérifiez la connectivité réseau.
  2. Vérifiez si les connexions TCP sont établies à l'aide de la sortie netstat pour déterminer si le service de contrôleur {central_control_plane_id} écoute les connexions sur le port 1235. Si ce n'est pas le cas, vérifiez les règles de pare-feu (ou) iptables pour voir si le port 1235 bloque les demandes de connexion {entity_id} du nœud de transport. Assurez-vous qu'il n'y a pas de pare-feu d'hôte ou de pare-feu de réseau dans la sous-couche bloquant les ports IP requis entre les nœuds de gestionnaire et les nœuds de transport. Cela est documenté dans l'outil ports et protocoles disponible ici : https://ports.vmware.com/.
  3. Il est possible que le nœud de transport {entity_id} soit toujours en mode de maintenance. Vous pouvez vérifier si le nœud de transport est en mode de maintenance via l'API suivante :

    GET https://<nsx-mgr>/api/v1/transport-nodes/<tn-uuid>

    Lorsque le mode de maintenance est défini, le nœud de transport n'est pas connecté au service de contrôleur. Cela est généralement le cas lorsque la mise à niveau de l'hôte est en cours. Attendez quelques minutes et vérifiez de nouveau la connectivité.
    Note : Cette alarme est critique et doit être résolue. Contactez le support VMware pour lui notifier cette alarme si elle reste non résolue pendant une période prolongée.

Canal de contrôle vers le nœud de transport inactif pendant longtemps

Critique

Canal de contrôle vers le nœud de transport inactif pendant trop longtemps.

Lorsque l'événement est détecté : le service de contrôleur central_control_plane_id vers le nœud de transport {entity-id} est inactif pendant au moins 15 minutes du point de vue des services de contrôleur.

Lorsque l'événement est résolu : le service de contrôleur central_control_plane_id restaure la connexion au nœud de transport {entity-id}.

  1. Vérifiez la connectivité à partir du service de contrôleur central_control_plane_id et l'interface du nœud de transport {entity-id} à l'aide de la commande ping. Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité réseau.
  2. Vérifiez si les connexions TCP sont établies à l'aide de la sortie netstat pour déterminer si le service de contrôleur {central_control_plane_id} écoute les connexions sur le port 1235. Si ce n'est pas le cas, vérifiez les règles de pare-feu (ou) iptables pour voir si le port 1235 bloque les demandes de connexion {entity_id} du nœud de transport. Assurez-vous qu'il n'y a pas de pare-feu d'hôte ou de pare-feu de réseau dans la sous-couche bloquant les ports IP requis entre les nœuds de gestionnaire et les nœuds de transport. Cela est documenté dans l'outil ports et protocoles disponible ici : https://ports.vmware.com/.
  3. Il est possible que le nœud de transport {entity_id} soit toujours en mode de maintenance. Vous pouvez vérifier si le nœud de transport est en mode de maintenance via l'API suivante :

    GET https://<nsx-mgr>/api/v1/transport-nodes/<tn-uuid>

    Lorsque le mode de maintenance est défini, le nœud de transport n'est pas connecté au service de contrôleur. Cela est généralement le cas lorsque la mise à niveau de l'hôte est en cours. Attendez quelques minutes et vérifiez de nouveau la connectivité.

Événements de santé d'Intelligence

Les événements de santé de NSX Intelligence proviennent du nœud NSX Manager et du dispositif NSX Intelligence.

Nom de l'événement Gravité Message d'alerte Action recommandée
Utilisation très élevée du CPU Critique

L'utilisation du CPU du nœud Intelligence est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud NSX Intelligence {intelligence_node_id} est au-dessus de la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud NSX Intelligence {intelligence_node_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %. »

Utilisez la commande top pour vérifier quels processus présentent le plus d'utilisations de la mémoire, puis vérifiez /var/log/syslog et les journaux locaux de ces processus pour voir si des erreurs en attente doivent être résolues.

Utilisation élevée du CPU Moyenne

L'utilisation du CPU du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud NSX Intelligence {intelligence_node_id} est au-dessus de la valeur de seuil élevée de{system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud NSX Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de{system_usage_threshold} %. »

Utilisez la commande top pour vérifier quels processus présentent le plus d'utilisations de la mémoire, puis vérifiez /var/log/syslog et les journaux locaux de ces processus pour voir si des erreurs en attente doivent être résolues.

Utilisation très élevée de la mémoire Critique

L'utilisation de la mémoire du nœud Intelligence est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud NSX Intelligence {intelligence_node_id} est au-dessus de la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud NSX Intelligence {intelligence_node_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %. »

Utilisez la commande top pour vérifier quels processus présentent le plus d'utilisations de la mémoire, puis vérifiez /var/log/syslog et les journaux locaux de ces processus pour voir si des erreurs en attente doivent être résolues.

Utilisation élevée de la mémoire Moyenne

L'utilisation de la mémoire du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud NSX Intelligence {intelligence_node_id} est au-dessus de la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud NSX Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

Utilisez la commande top pour vérifier quels processus présentent le plus d'utilisations de la mémoire, puis vérifiez /var/log/syslog et les journaux locaux de ces processus pour voir si des erreurs en attente doivent être résolues.

Utilisation très élevée du disque Critique

L'utilisation du disque du nœud Intelligence est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque de la partition de disque {disk_partition_name} sur le nœud NSX Intelligence {intelligence_node_id} est au-dessus de la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du disque de la partition de disque {disk_partition_name} sur le nœud NSX Intelligence {intelligence_node_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %. »

Examinez la partition de disque {disk_partition_name} et vérifiez si vous pouvez supprimer des fichiers volumineux inattendus.
Utilisation élevée du disque Moyenne

L'utilisation du disque du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque de la partition de disque {disk_partition_name} sur le nœud NSX Intelligence {intelligence_node_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du disque de la partition de disque {disk_partition_name} sur le nœud NSX Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

Examinez la partition de disque {disk_partition_name} et vérifiez si vous pouvez supprimer des fichiers volumineux inattendus.
Utilisation très élevée de la partition de disque de données Critique

L'utilisation de la partition de disque de données du nœud Intelligence est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque de la partition de disque /data sur le nœud NSX Intelligence {intelligence_node_id} est supérieure à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du disque de la partition de disque /data sur le nœud NSX Intelligence {intelligence_node_id} est inférieure à la valeur de seuil très élevée de {system_usage_threshold} %. »

Arrêtez la collecte de données NSX Intelligence jusqu'à ce que l'utilisation du disque soit inférieure au seuil.

Dans l'interface utilisateur de NSX, accédez à Système Dispositifs Dispositif NSX Intelligence. Sélectionnez ensuite ACTIONS > Arrêter la collecte des données.

Utilisation élevée de la partition de disque de données Moyenne

L'utilisation de la partition de disque de données du nœud Intelligence est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque de la partition de disque /data sur le nœud NSX Intelligence {intelligence_node_id} est supérieure à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du disque de la partition de disque /data sur le nœud NSX Intelligence {intelligence_node_id} est inférieure à la valeur de seuil élevée de {system_usage_threshold} %. »

Arrêtez la collecte de données NSX Intelligence jusqu'à ce que l'utilisation du disque soit inférieure au seuil.

Examinez la partition /data et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.

État du nœud dégradé Élevé

L'état du nœud Intelligence est dégradé.

Lorsque l'événement est détecté : « Le service {service_name} sur le nœud NSX Intelligence {intelligence_node_id} n'est pas en cours d'exécution. »

Lorsque l'événement est résolu : « Le service {service_name} sur le nœud NSX Intelligence {intelligence_node_id} s'exécute correctement. »

Examinez l'état du service et les informations de santé avec la commande get services de l'interface de ligne de commande NSX sur le nœud NSX Intelligence.

Redémarrez les services arrêtés inattendus avec la commande restart service <service-name> de l'interface de ligne de commande NSX.

Événements de gestion des adresses IP

Les événements de gestion des adresses IP (IPAM) proviennent des nœuds NSX Manager.

Nom de l'événement Gravité Message d'alerte Action recommandée
Utilisation très élevée du bloc d'adresses IP Moyenne

À partir de NSX-T Data Center 3.1.2.

L'utilisation du sous-réseau IP d'un bloc d'adresses IP a atteint 90 %.

Lorsqu'un événement est détecté : « L'utilisation du bloc d'adresses IP <intent_path> est très élevée. Le bloc d'adresses IP approche de sa capacité totale, la création d'un sous-réseau à l'aide d'un bloc d'adresses IP peut échouer. »

Lorsque l'événement est résolu :

aucun message.

  • Examinez l'utilisation du bloc d'adresses IP. Utilisez un nouveau bloc d'adresses IP pour la création de ressources ou supprimez le sous-réseau IP inutilisé du bloc d'adresses IP. Pour vérifier le sous-réseau utilisé pour un bloc d'adresses IP :
    1. Dans l'interface utilisateur de NSX, accédez à Mise en réseau > Pools d'adresses IP > Pools d'adresses IP.
    2. Sélectionnez les pools d'adresses IP dans lesquels le bloc d'adresses IP est utilisé. Vérifiez Sous-réseaux et Adresses IP allouées.
    3. Supprimez le sous-réseau ou le pool d'adresses IP si aucune des allocations n'est utilisée et ne sera plus utilisée à l'avenir.
  • Utilisez les API suivantes pour vérifier si le bloc d'adresses IP est utilisé par le pool d'adresses IP et également pour vérifier les allocations IP.
    • Pour obtenir les sous-réseaux configurés d'un pool d'adresses IP, appelez la NSX API suivante.

      GET /policy/api/v1/infra/ip-pools/<ip-pool>/ip-subnets

    • Pour obtenir des allocations IP, appelez la NSX API suivante.

      GET /policy/api/v1/infra/ip-pools/<ip-pool>/ip-allocations

Note : Supprimez un pool d'adresses IP ou un sous-réseau uniquement s'il n'a pas d'adresses IP allouées et s'il ne sera pas utilisé ultérieurement.
Utilisation très élevée du pool d'adresses IP Moyenne

À partir de NSX-T Data Center 3.1.2.

L'utilisation de l'allocation IP d'un pool d'adresses IP a atteint 90 %.

Lorsqu'un événement est détecté : « L'utilisation du pool d'adresses IP <intent_path> est très élevée. Pool d'adresses IP proche de sa capacité totale. La création d'une entité/d'un service qui dépend de l'adresse IP allouée à partir du pool d'adresses IP peut échouer. »

Lorsque l'événement est résolu :

aucun message.

Examinez l'utilisation du pool d'adresses IP. Libérez les allocations d'adresses IP inutilisées du pool d'adresses IP ou créez un pool d'adresses IP.

  1. Dans l'interface utilisateur de NSX, accédez à Mise en réseau > Pools d'adresses IP > Pools d'adresses IP.
  2. Sélectionnez des pools d'adresses IP et cochez la colonne Adresses IP allouées pour afficher les adresses IP allouées à partir du pool d'adresses IP.

Vous pouvez libérer ces adresses IP qui ne sont pas utilisées. Pour libérer les allocations d'adresses IP inutilisées, appelez la NSX API suivante.

DELETE /policy/api/v1/infra/ip-pools/<ip-pool>/ip-allocations/<ip-allocation>

Événements de licence

Les événements de licence proviennent du nœud NSX Manager.

Nom de l'événement Gravité Message d'alerte Action recommandée
Licence expirée Critique

Une licence a expiré.

Lorsque l'événement est détecté : « La licence de type {license_edition_type} a expiré. »

Lorsque l'événement est résolu : « La licence expirée de type {license_edition_type} a été supprimée, mise à jour ou n'est plus expirée. »

Ajoutez une nouvelle licence non expirée :
  1. Dans l'interface utilisateur de NSX, accédez à Système > Licences.
  2. Cliquez sur Ajouter et spécifiez la clé de la nouvelle licence.
  3. Supprimez la licence expirée en cochant la case et en cliquant sur Annuler l'attribution.
Licence sur le point d'expirer Moyenne

Lorsque l'événement est détecté : « La licence de type {license_edition_type} est sur le point d'expirer. »

Lorsque l'événement est résolu : « La licence expirée identifiée par {license_edition_type} a été supprimée, mise à jour ou n'est plus sur le point d'expirer. »

Ajoutez une nouvelle licence non expirée :
  1. Dans l'interface utilisateur de NSX, accédez à Système > Licences.
  2. Cliquez sur Ajouter et spécifiez la clé de la nouvelle licence.
  3. Supprimez la licence expirée en cochant la case et en cliquant sur Annuler l'attribution.

Événements d'équilibreur de charge

Les événements d'équilibreur de charge proviennent de nœuds NSX Edge ou NSX Manager.

Nom de l'événement Gravité Message d'alerte Action recommandée
CPU d'équilibrage de charge très élevé Moyenne

L'utilisation du CPU de l'équilibreur de charge est très élevée.

Lorsqu'un événement est détecté : « L'utilisation du CPU par l'équilibreur de charge {entity_id} est très élevée. Le seuil est {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du CPU par l'équilibreur de charge {entity_id} est suffisamment faible. Le seuil est {system_usage_threshold} %. »

Si l'utilisation du CPU de l'équilibreur de charge de est supérieure à {system_usage_threshold} %, la charge de travail est trop élevée pour cet équilibreur de charge.

Redimensionnez le service d'équilibreur de charge en passant la taille de l'équilibreur de charge de petite à moyenne ou de moyenne à grande.

Si l'utilisation du CPU de cet équilibreur de charge est toujours élevée, pensez à ajuster la taille du format du dispositif Edge ou à déplacer les services d'équilibreur de charge vers d'autres nœuds Edge pour la charge de travail applicable.

État d'équilibrage de charge inactif

Critique

Lorsque l'événement est détecté : « Le service d'équilibreur de charge centralisé {entity_id} est inactif. »

Lorsque l'événement est résolu : « Le service d'équilibreur de charge centralisé {entity_id} est actif. »

  1. Sur le nœud Edge actif, vérifiez l'état de l'équilibreur de charge en appelant la commande CLI NSX suivante.

    get load-balancer <lb-uuid> status
  2. Si l'état de l'équilibreur de charge du service d'équilibreur de charge est « not_ready » ou s'il n'existe aucune sortie, faites entrer le nœud Edge en mode de maintenance, puis quittez le mode de maintenance.
État du serveur virtuel inactif Moyenne

Le service virtuel d'équilibreur de charge est inactif.

Lorsque l'événement est détecté : « Le serveur virtuel d'équilibreur de charge {entity_id} est inactif. »

Lorsque l'événement est résolu : « Le serveur virtuel d'équilibreur de charge {entity_id} est actif. »

Consultez le pool d'équilibreurs de charge pour déterminer son état et vérifier sa configuration.

S'il est configuré de manière incorrecte, reconfigurez-le et supprimez le pool d'équilibreurs de charge du serveur virtuel, puis rajoutez-le à nouveau au serveur virtuel.

État du pool inactif Moyenne

Lorsque l'événement est détecté : « L'état du pool d'équilibreur de charge {entity_id} est inactif. »

Lorsque l'événement est résolu : « L'état du pool d'équilibreur de charge {entity_id} est actif. »

  1. Consultez le pool d'équilibreur de charge pour déterminer quels membres sont inactifs.
  2. Vérifiez la connectivité réseau entre l'équilibreur de charge et les membres du pool concernés.
  3. Validez la santé de l'application de chaque membre du pool.
  4. Validez la santé de chaque membre du pool à l'aide du moniteur configuré.

Lorsque la santé du membre est établie, l'état du membre du pool est mis à jour sur Sain en fonction du Nombre de reconnexions.

État de l'équilibrage de charge dégradé

Moyenne

À partir de NSX-T Data Center 3.1.2.

Lorsque l'événement est détecté : « Le service d'équilibreur de charge {entity_id} est dégradé. »

Lorsque l'événement est résolu : « Le service d'équilibreur de charge {entity_id} n'est pas dégradé. »

  • Pour l'équilibreur de charge centralisé :
    1. Sur le nœud Edge en veille, vérifiez l'état de l'équilibreur de charge en appelant la commande CLI NSX suivante.

      get load-balancer <lb-uuid> status
    2. Si l'état de l'équilibreur de charge du service d'équilibreur de charge est « not_ready » ou s'il n'existe aucune sortie, faites entrer le nœud Edge en mode de maintenance, puis quittez le mode de maintenance.
  • Pour l'équilibreur de charge distribué :
  1. Obtenez un état détaillé en appelant la NSX API suivante.

    GET /policy/api/v1/infra/lb-services/<LBService>/detailed-status?source=realtime
  2. Dans la sortie de l'API, recherchez l'hôte ESXi signalant une valeur non nulle instance_number avec l'état NOT_READY ou CONFLICT.
  3. Sur le nœud hôte ESXi, appelez la commande CLI NSX suivante.

    get load-balancer <lb-uuid> status

    Si le message « LSP en conflit » est signalé, vérifiez si ce LSP est associé à un autre service d'équilibreur de charge et si ce conflit est acceptable.

    Si « LSP non prêt » est signalé, vérifiez l'état de ce LSP en appelant la commande CLI NSX suivante.

    get logical-switch-port status

État de DLB inactif

Critique

À partir de NSX-T Data Center 3.1.2.

Lorsque l'événement est détecté : « Le service d'équilibreur de charge distribué {entity_id} est inactif. »

Lorsque l'événement est résolu : « Le service d'équilibreur de charge distribué {entity_id} est actif. »

  1. Sur le nœud hôte ESXi, appelez la commande CLI NSX suivante.

    get load-balancer <lb-uuid> status
  2. Si le rapport indique « LSP en conflit », vérifiez si ce LSP est associé à un autre service d'équilibreur de charge et si ce conflit est acceptable. Si le rapport indique « LSP non prêt » , vérifiez l'état de ce LSP en appelant la commande CLI NSX suivante.

    get logical-switch-port status

Capacité Edge d'équilibrage de charge en cours d'utilisation élevée

Critique

À partir de NSX-T Data Center 3.1.2.

Lorsqu'un événement est détecté : « L'utilisation du service d'équilibreur de charge dans le nœud Edge {entity_id} est élevée. Le seuil est {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du service d'équilibreur de charge dans le nœud Edge {entity_id} est suffisamment faible. Le seuil est {system_usage_threshold} %. »

Déployez un nouveau nœud Edge et déplacez le service d'équilibreur de charge des nœuds Edge existants vers le nœud Edge qui vient d'être déployé.

Capacité de membre du pool d'équilibrage de charge en cours d'utilisation très élevée

Critique

À partir de NSX-T Data Center 3.1.2.

Lorsqu'un événement est détecté : « L'utilisation des membres du pool dans le nœud Edge {entity_id} est très élevée. Le seuil est {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation des membres du pool dans le nœud Edge {entity_id} est suffisamment faible. Le seuil est {system_usage_threshold} %. »

Déployez un nouveau nœud Edge et déplacez le service d'équilibreur de charge des nœuds Edge existants vers le nœud Edge qui vient d'être déployé.

Événements de santé du gestionnaire

Les événements de santé de NSX Manager proviennent du cluster de nœuds de NSX Manager.

Nom de l'événement Gravité Message d'alerte Action recommandée
Adresse IP dupliquée Moyenne

L'adresse IP du nœud de gestionnaire est utilisée par un autre périphérique.

Lorsque l'événement est détecté : « L'adresse IP {duplicate_ip_address} du nœud de gestionnaire {entity_id} est actuellement utilisée par un autre périphérique du réseau. »

Lorsque l'événement est détecté : « Le nœud de gestionnaire {entity_id} semble ne plus utiliser {duplicate_ip_address}. »

  1. Déterminez le périphérique qui utilise l'adresse IP du gestionnaire et attribuez-lui une nouvelle adresse IP.
    Note : La reconfiguration du gestionnaire pour utiliser une nouvelle adresse IP n'est pas prise en charge.
  2. Vérifiez que le pool d'adresses IP statiques/serveur DHCP est correctement configuré.
  3. Corrigez l'adresse IP du périphérique si elle est attribuée manuellement.
Utilisation très élevée du CPU de Manager Critique

L'utilisation du CPU du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud de gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud de gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %. »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud de gestionnaire.

Pensez à ajuster la taille du format du dispositif de gestionnaire.

Utilisation élevée du CPU de Manager Moyenne

À partir de NSX-T Data Center 3.0.1.

L'utilisation du CPU du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation du CPU sur le nœud de gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du CPU sur le nœud de gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %. »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud de gestionnaire.

Pensez à ajuster la taille du format du dispositif de gestionnaire.

Utilisation très élevée de la mémoire de Manager Critique

À partir de NSX-T Data Center 3.0.1.

L'utilisation de la mémoire du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud de gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud de gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %. »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud de gestionnaire.

Pensez à ajuster la taille du format du dispositif de gestionnaire.

Utilisation élevée de la mémoire de Manager Moyenne

L'utilisation de la mémoire du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation de la mémoire sur le nœud de gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire sur le nœud de gestionnaire {entity_id} a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %. »

Vérifiez la configuration, les services en cours d'exécution et le dimensionnement de ce nœud de gestionnaire.

Pensez à ajuster la taille du format du dispositif de gestionnaire.

Utilisation très élevée du disque de Manager Critique

L'utilisation du disque du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque {disk_partition_name} du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque {disk_partition_name} du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %. »

Examinez la partition ayant une utilisation élevée et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.
Utilisation élevée du disque de Manager Moyenne

L'utilisation du disque du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque {disk_partition_name} du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque {disk_partition_name} du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %. »

Examinez la partition ayant une utilisation élevée et vérifiez si des fichiers volumineux inattendus peuvent être supprimés.
Utilisation très élevée du disque de configuration de gestionnaire Critique

L'utilisation du disque de configuration du nœud de gestionnaire est très élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque /config du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold} %. Cela peut indiquer une utilisation élevée du disque par le service de banque de données NSX dans le répertoire /config/corfu. »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque /config du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de {system_usage_threshold} %. »

Examinez la partition /config et vérifiez s'il existe des fichiers volumineux inattendus pouvant être supprimés.
Utilisation élevée du disque de configuration de gestionnaire Moyenne

L'utilisation du disque de configuration du nœud de gestionnaire est élevée.

Lorsque l'événement est détecté : « L'utilisation du disque pour la partition de disque /config du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold} %. Cela peut indiquer une utilisation croissante du disque par le service de banque de données NSX dans le répertoire /config/corfu. »

Lorsque l'événement est résolu : « L'utilisation du disque pour la partition de disque /config du nœud de gestionnaire a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil élevée de {system_usage_threshold} %. »

Examinez la partition /config et vérifiez s'il existe des fichiers volumineux inattendus pouvant être supprimés.

Utilisation élevée du disque de base de données d'opérations

Moyenne

L'utilisation du disque pour la partition /nonconfig de disque du nœud de gestionnaire a atteint {system_resource_usage}%, ce qui est supérieur ou égal à la valeur de seuil élevée de {system_usage_threshold}%. Cela peut indiquer une utilisation croissante du disque par le service de banque de données NSX dans le répertoire /nonconfig/corfu.

Exécutez l'outil suivant et contactez GSS si des problèmes sont signalés /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig.

Utilisation très élevée du disque de base de données d'opérations Critique

L'utilisation du disque pour la partition /nonconfig de disque du nœud de gestionnaire a atteint {system_resource_usage}%, ce qui est supérieur ou égal à la valeur de seuil très élevée de {system_usage_threshold}%. Cela peut indiquer une utilisation croissante du disque par le service de banque de données NSX dans le répertoire /nonconfig/corfu.

Exécutez l'outil suivant et contactez GSS si des problèmes sont signalés /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig.

Événements de NCP

Les événements de NSX Container Plug-in (NCP) proviennent des nœuds ESXi et KVM.

Nom de l'événement Gravité Message d'alerte Action recommandée
Plug-in NCP inactif Critique

Le nœud de gestionnaire a détecté que NCP est inactif ou défectueux.

Lorsque l'événement est détecté : « Le nœud de gestionnaire a détecté que NCP est inactif ou défectueux. »

Lorsque l'événement est résolu : « Le nœud de gestionnaire a détecté que le NCP est de nouveau actif ou sain. »

Pour rechercher les clusters qui rencontrent des problèmes, appelez NSX API : GET /api/v1/systemhealth/container-cluster/ncp/status pour extraire tous les états des clusters et déterminer le nom de tous les clusters qui signalent INACTIF ou INCONNU.

Accédez à la page Inventaire > Conteneur > Clusters de l'interface utilisateur de NSX pour rechercher les noms de clusters qui ont signalé l'état INACTIF ou INCONNU et cliquez sur l'onglet Nœuds qui répertorie tous les membres de cluster Kubernetes et PAS.

Pour le cluster Kubernetes :
  1. Vérifiez la réactivité de l'espace NCP en recherchant le nœud master K8s à partir de tous les membres du cluster et connectez-vous au nœud master.

    Appelez ensuite la commande kubectl kubectl get pods --all-namespaces. En cas de problème avec l'espace NCP, utilisez la commande kubectl logs pour vérifier le problème et corriger l'erreur.

  2. Vérifiez la connexion entre NCP et Kubernetes API Server.
    L'interface de ligne de commande NSX peut être utilisée à l'intérieur de l'espace NCP pour vérifier cet état de connexion en appelant les commandes suivantes de la VM maître.
    kubectl exec -it <NCP-Pod-Name> -n nsx-system bash
    nsxcli
    get ncp-k8s-api-server status
    En cas de problème avec la connexion, vérifiez les configurations réseau et NCP.
  3. Vérifiez la connexion entre NCP et NSX Manager.
    L'interface de ligne de commande NSX peut être utilisée à l'intérieur de l'espace NCP pour vérifier cet état de connexion en appelant la commande suivante de la VM maître.
    kubectl exec -it <NCP-Pod-Name> -n nsx-system bash nsxcli get ncp-nsx status
    En cas de problème avec la connexion, vérifiez les configurations réseau et NCP.
Pour le cluster PAS :
  1. Vérifiez les connexions réseau entre les machines virtuelles et corrigez les problèmes réseau.
  2. Vérifiez l'état des nœuds et des services et corrigez ceux qui sont bloqués.

    Appelez les commandes bosh vms et bosh instances -p pour vérifier l'état des nœuds et des services.

Événements de santé des agents de nœud

Les événements de santé d'agent de nœud proviennent des nœuds ESXi et KVM.

Nom de l'événement Gravité Message d'alerte Action recommandée
Agents de nœud inactifs Élevé

Les agents exécutés à l'intérieur de la VM du nœud semblent être inactifs.

Lorsque l'événement est détecté : « Les agents exécutés à l'intérieur de la VM du nœud semblent être inactifs. »

Lorsque l'événement est résolu : « Les agents à l'intérieur de la VM de nœud sont en cours d'exécution. »

Pour ESX :

  1. Si Vmk50 est manquant, reportez-vous à l'article 67432 de la base de connaissances.
  2. Si Hyperbus 4094 est manquant : le redémarrage de NSX-journal cfgagent ou de la VM de l'hôte du conteneur peut aider.
  3. Si la VIF de l'hôte du conteneur est bloquée, vérifiez la connexion au contrôleur pour vous assurer que toutes les configurations sont envoyées.
  4. Si nsx-cfgagent s'est arrêté, redémarrez nsx-cfgagent.

Pour KVM :

  1. Si l'espace de noms Hyperbus est manquant, le redémarrage de nsx-opsagent peut aider à le recréer.
  2. Si l'interface Hyperbus est manquante dans l'espace de noms Hyperbus, le redémarrage de nsx-opsagent peut aider.
  3. Si nsx-agent s'est arrêté, redémarrez nsx-agent.

Pour ESX et KVM :

  1. Si le module node-agent est manquant : vérifiez si le module node-agent a été correctement installé sur la VM de l'hôte du conteneur.
  2. Si l'interface du node-agent sur la VM de l'hôte du conteneur est inactive : vérifiez l'état de l'interface eth1 sur la VM de l'hôte du conteneur.

Événements de NSX Federation

Les événements de NSX Federationproviennent des nœuds NSX Manager, NSX Edge et de passerelle publique.

Nom de l'événement Gravité Message d'alerte Action recommandée

Erreur de synchronisation LM-LM

Élevé

À partir de NSX-T Data Center 3.0.1.

La synchronisation entre {site_name}({site_id} et {remote_site_name}({remote_site_id} a échoué pendant plus de 5 minutes.

  1. Appelez la commande CLI NSX get site-replicator remote-sites pour obtenir l'état de la connexion entre les emplacements distants. Si un emplacement distant est connecté mais pas synchronisé, il est possible qu'il soit toujours en cours de résolution principale. Dans ce cas, attendez environ 10 secondes et essayez à nouveau d'appeler l'interface de ligne de commande pour vérifier l'état de l'emplacement distant. Si un emplacement est déconnecté, essayez l'étape suivante.

  2. Vérifiez la connectivité à partir du gestionnaire local (LM) dans l'emplacement {site_name}{site_id} sur les LM dans l'emplacement {remote_site_name}{remote_site_id}) via une commande ping. Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité WAN. S'il n'y a aucun problème de connectivité réseau physique, essayez l'étape suivante.

  3. Consultez le fichier /var/log/cloudnet/nsx-ccp.log sur les nœuds de gestionnaire dans le cluster local à l'emplacement {site_name}({site_id} qui a déclenché l'alarme pour déterminer s'il existe des erreurs de communication entre sites. De plus, recherchez également les erreurs journalisées par le sous-composant nsx-appl-proxy dans /var/log/syslog.

Avertissement de synchronisation LM-LM Moyenne

À partir de NSX-T Data Center 3.0.1.

La synchronisation entre {site_name}({site_id} et {remote_site_name}({remote_site_id} a échoué.

Canal de contrôle vers le nœud de transport inactif pendant trop longtemps

  1. Appelez la commande CLI NSX get site-replicator remote-sites pour obtenir l'état de la connexion entre les emplacements distants. Si un emplacement distant est connecté mais pas synchronisé, il est possible qu'il soit toujours en cours de résolution principale. Dans ce cas, attendez environ 10 secondes et essayez à nouveau d'appeler l'interface de ligne de commande pour vérifier l'état de l'emplacement distant. Si un emplacement est déconnecté, essayez l'étape suivante.

  2. À l'aide d'une commande ping, vérifiez la connectivité du gestionnaire local (LM) dans l'emplacement {site_name}{site_id} aux LM dans l'emplacement {remote_site_name}{remote_site_id}). Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité WAN. S'il n'y a aucun problème de connectivité réseau physique, essayez l'étape suivante.

  3. Consultez le fichier /var/log/cloudnet/nsx-ccp.log sur les nœuds de gestionnaire dans le cluster local à l'emplacement {site_name}({site_id} qui a déclenché l'alarme, pour déterminer s'il existe des erreurs de communication entre sites. De plus, recherchez également les erreurs journalisées par le sous-composant nsx-appl-proxy dans /var/log/syslog.

RTEP BGP inactif Élevé

À partir de NSX-T Data Center 3.0.1.

La session RTEP BGP de l'adresse IP source {bgp_source_ip} vers l'adresse IP du voisin {bgp_neighbor_ip} de l'emplacement distant {remote_site_name} est inactive. Motif : {failure_reason}.

  1. Appelez la commande CLI NSX get logical-routers sur le nœud Edge concerné.

  2. Basculez sur le contexte REMOTE_TUNNEL_VRF
  3. Appelez la commande get bgp neighbor de l'interface de ligne de commande NSX pour vérifier le voisin BGP.
  4. Vous pouvez également appeler la NSX API GET /api/v1/transport-nodes/<transport-node-id>/inter-site/bgp/summary pour obtenir l'état du voisin BGP.
  5. Appelez la commande CLI NSX get interfaces et vérifiez si l'adresse IP RTEP adéquate est attribuée à l'interface avec le nom remote-tunnel-endpoint.
  6. . Vérifiez si le test ping fonctionne correctement entre l'adresse IP RTEP attribuée {bgp_source_ip} et l'adresse IP du voisin {bgp_neighbor_ip} de l'emplacement distant {remote_site_name}.
  7. Recherchez les erreurs liées à BGP dans /var/log/syslog.
  8. Appelez NSX API GET ou PUT /api/v1/transport-nodes/<transport-node-id> pour obtenir/mettre à jour la configuration remote_tunnel_endpoint sur le nœud Edge. Cette action mettra à jour l'adresse IP RTEP attribuée au nœud Edge concerné.

Événements de gestion des mots de passe

Les événements de gestion des mots de passe proviennent des nœuds NSX Manager, NSX Edge et de passerelle publique.

Nom de l'événement Gravité Message d'alerte Action recommandée
Mot de passe expiré Critique

Le mot de passe utilisateur a expiré.

Lorsque l'événement est détecté : « Le mot de passe de l'utilisateur {username} a expiré. »

Lorsque l'événement est résolu : « Le mot de passe de l'utilisateur {username} a été modifié ou n'est plus expiré. »

Le mot de passe de l'utilisateur {username} doit maintenant être modifié pour accéder au système. Par exemple, pour appliquer un nouveau mot de passe à un utilisateur, appelez la NSX API suivante avec un mot de passe valide dans le corps de la demande :

PUT /api/v1/node/users/<userid>

<userid> est l'ID de l'utilisateur. Si le mot de passe de l'utilisateur Admin (avec <userid> 10 000) a expiré, l'administrateur doit se connecter au système via SSH (si activé) ou à la console pour modifier le mot de passe. En entrant le mot de passe actuel expiré, l'administrateur est invité à entrer un nouveau mot de passe.

Mot de passe sur le point d'expirer Élevé

Le mot de passe utilisateur est sur le point d'expirer.

Lorsque l'événement est détecté : « Le mot de passe de l'utilisateur {username} est sur le point d'expirer dans {password_expiration_days} jours. »

Lorsque l'événement est résolu : « Le mot de passe de l'utilisateur {username} a été modifié ou n'est plus sur le point d'expirer. »

Assurez-vous que le mot de passe de l'utilisateur identifié par {username} est modifié immédiatement. Par exemple, pour appliquer un nouveau mot de passe à un utilisateur, appelez la NSX API suivante avec un mot de passe valide dans le corps de la demande :

PUT /api/v1/node/users/<userid>

<userid> est l'ID de l'utilisateur.

Expiration du mot de passe approchant Moyenne

Le mot de passe de l'utilisateur arrive à expiration.

Lorsque l'événement est détecté : « Le mot de passe de l'utilisateur {username} est sur le point d'expirer dans {password_expiration_days} jours. »

Lorsque l'événement est résolu : « Le mot de passe de l'utilisateur {username} a été modifié ou n'est plus sur le point d'expirer. »

Le mot de passe de l'utilisateur identifié par {username} doit bientôt être modifié. Par exemple, pour appliquer un nouveau mot de passe à un utilisateur, appelez la NSX API suivante avec un mot de passe valide dans le corps de la demande :

PUT /api/v1/node/users/<userid>

<userid> est l'ID de l'utilisateur.

Événements de routage

Nom de l'événement Gravité Message d'alerte Action recommandée
BGP inactif Élevé

Le voisin BGP est inactif.

Lorsque l'événement est détecté : « Dans le routeur {entity_id}, le voisin BGP {bgp_neighbor_ip} est inactif, motif : {failure_reason}. »

Lorsque l'événement est résolu : « Dans le routeur {entity_id}, le voisin BGP {bgp_neighbor_ip} est actif. »

  1. Connectez-vous via SSH au nœud Edge.
  2. Appelez la commande d'interface de ligne de commande NSX : get logical-routers
  3. Basculez vers le routeur de service {sr_id}.
  4. Vérifiez /var/log/syslog pour voir s'il existe des erreurs liées à la connectivité de BGP.

Bidirectional Forwarding Detection (BFD) inactif sur l'interface externe

Élevé

La session BFD est inactive.

Lorsque l'événement est détecté : « Dans le routeur {entity_id}, la session BFD pour l'homologue {peer_address} est inactive. »

Lorsque l'événement est résolu : « Dans le routeur {entity_id}, la session BFD pour l'homologue {peer_address} est active. »

  1. Connectez-vous via SSH au nœud Edge.
  2. Appelez la commande d'interface de ligne de commande NSX : get logical-routers
  3. Basculez vers le routeur de service {sr_id}.
  4. Vérifiez la connectivité en appelant la commande d'interface de ligne de commande NSX : ping <peer_address>.
Routage inactif Élevé

Toutes les sessions BGP/BFD sont inactives.

Lorsque l'événement est détecté : « Toutes les sessions BGP/BFD sont inactives. »

Lorsque l'événement est résolu : « Au moins une session BGP/BFD est activée ».

  1. Appelez la commande get logical-routers de l'interface de ligne de commande NSX pour obtenir le routeur de service de niveau 0.
  2. Passez au VRF du routeur de service de niveau 0, puis appelez les commandes d'interface de ligne de commande NSX suivantes :
    • Vérifier la connectivité : ping <BFD peer IP address>
    • Vérifier la santé de BFD :
      get bfd-config 
      get bfd-sessions
    • Vérifier la santé de BGP : get bgp neighbor summary
      get bfd neconfig 
      get bfd-sessions
    Vérifiez /var/log/syslog pour voir s'il existe des erreurs liées à la connectivité de BGP.
Routage statique supprimé Élevé

Itinéraire statique supprimé.

Lorsque l'événement est détecté : « Dans le routeur {entity_id}, la route statique {static_address} a été supprimée, car BFD était inactif. »

Lorsque l'événement est résolu : « Dans le routeur {entity_id}, la route statique {static_address} a été ajoutée de nouveau en tant que BFD récupéré. »

  1. Connectez-vous via SSH au nœud Edge.
  2. Appelez la commande d'interface de ligne de commande NSX : get logical-routers
  3. Basculez vers le routeur de service {sr_id}.
  4. Vérifiez la connectivité en appelant la commande d'interface de ligne de commande NSX :
    get bgp neighbor summary
  5. Vérifiez également la configuration dans NSX et l'homologue BFD pour vous assurer que les temporisateurs n'ont pas été modifiés.

Santé du nœud de transport

Les événements de santé du nœud de transport proviennent des nœuds KVM et ESXi.

Nom de l'événement Gravité Message d'alerte Action recommandée
Membre LAG inactif Moyenne

Le membre de rapports LACP est inactif.

Lorsque l'événement est détecté : « Le membre de rapports LACP est inactif. ».

Lorsque l'événement est résolu : « Le membre de rapports LACP est actif. »

Vérifiez l'état de la connexion des membres LAG sur les hôtes.
  1. Dans l'interface utilisateur de NSX, accédez à Infrastructure > Nœuds > Nœuds de transport > Nœuds de transport hôtes.
  2. Dans la liste Nœuds de transport hôtes, vérifiez la colonne État du nœud.

    Recherchez le nœud de transport dont l'état du nœud est dégradé ou inactif.

  3. Sélectionnez <transport node> > Surveiller.

    Recherchez la liaison (liaison montante) signalée comme dégradée ou inactive.

  4. Vérifiez les informations de l'état du membre LACP en vous connectant à l'hôte échoué et en exécutant la commande appropriée :
    • ESXi : esxcli network vswitch dvs vmware lacp status get
    • KVM : ovs-appctl bond/show et ovs-appctl lacp/show
Liaison montante N-VDS inactive Moyenne

La liaison montante diminue.

Lorsque l'événement est détecté : « La liaison montante diminue. »

Lorsque l'événement est résolu : « La liaison montante augmente. »

Vérifiez l'état des liaisons montantes sur les hôtes dans les cartes réseau physiques.
  1. Dans l'interface utilisateur de NSX, accédez à Infrastructure > Nœuds > Nœuds de transport > Nœuds de transport hôtes.
  2. Dans la liste Nœuds de transport hôtes, vérifiez la colonne État du nœud.

    Recherchez le nœud de transport dont l'état du nœud est dégradé ou inactif.

  3. Sélectionnez <transport node> > Surveiller.

    Vérifiez les détails de l'état de la liaison (liaison montante) qui est signalée comme dégradée ou inactive.

    Pour éviter un état dégradé, assurez-vous que toutes les interfaces de liaison montante sont connectées et actives, qu'elles soient utilisées ou non.

Événements VPN

Les événements VPN proviennent des nœuds NSX Edge et de passerelle publique.

Nom de l'événement Gravité Message d'alerte Action recommandée
Session basée sur la stratégie IPsec inactive Moyenne

La session VPN IPsec basée sur une stratégie est inactive.

Lorsque l'événement est détecté : « La session VPN IPsec basée sur une stratégie {entity_id} est inactive. Motif : {session_down_reason}. »

Lorsque l'événement est résolu : « La session VPN IPsec basée sur une stratégie {entity_id} est active ».

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif de l'inactivité de la session.

Session basée sur une route IPsec inactive Moyenne

La session VPN IPsec basée sur une route est inactive.

Lorsque l'événement est détecté : « La session VPN IPsec basée sur une route {entity_id} est inactive. Motif : {session_down_reason}. »

Lorsque l'événement est résolu : « La session VPN IPsec basée sur une route {entity_id} est active ».

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif de l'inactivité de la session.

Tunnel IPsec basé sur une stratégie inactif Moyenne

Les tunnels VPN IPsec basés sur une stratégie sont inactifs.

Lorsque l'événement est détecté : « Un ou plusieurs tunnels VPN IPsec basés sur une stratégie dans la session {entity_id} sont inactifs. »

Lorsque l'événement est résolu : « Tous les tunnels VPN IPsec basés sur une stratégie dans la session {entity_id} sont actifs. »

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif de l'inactivité du tunnel.

Tunnel IPsec basé sur une route inactif Moyenne

Les tunnels VPN IPsec basés sur une route sont inactifs.

Lorsque l'événement est détecté : « Un ou plusieurs tunnels VPN IPsec basés sur une route dans la session {entity_id} sont inactifs. »

Lorsque l'événement est résolu : « Tous les tunnels VPN IPsec basés sur une route dans la session {entity_id} sont actifs. »

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif de l'inactivité du tunnel.

Session L2VPN inactive Moyenne

La session L2VPN est inactive.

Lorsque l'événement est détecté : « La session L2VPN {entity_id} est inactive. »

Lorsque l'événement est résolu : « La session L2VPN {entity_id} est active. »

Vérifiez la configuration de la session VPN IPsec et résolvez les erreurs en fonction du motif.

Événements liés au pare-feu d'identité

Nom de l'événement Gravité Message d'alerte Action recommandée
Connectivité au serveur LDAP perdue

Critique

La connectivité au serveur LDAP est perdue.

Lorsque l'événement est détecté : échec de la connexion au serveur LDAP.

Lorsque l'événement est détecté : correctement connecté au serveur LDAP.

Suivez les étapes décrites ci-dessous pour vérifier la connectivité du serveur LDAP :

  1. Le serveur LDAP est accessible à partir des nœuds NSX.
  2. Les détails du serveur LDAP sont correctement configurés dans NSX.
  3. Le serveur LDAP s'exécute correctement.
  4. Aucun pare-feu ne bloque l'accès entre le serveur LDAP et les nœuds NSX.

Après avoir résolu le problème de connexion, utilisez « TESTER LA CONNEXION » dans l'interface utilisateur du serveur LDAP pour tester la connexion au serveur LDAP.

Erreur lors de la synchronisation Delta

Critique

Erreur détectée lors de la synchronisation delta avec le domaine AD

Lorsque l'événement est détecté : la synchronisation delta s'est terminée avec une erreur.

Lorsque l'événement est détecté : la synchronisation delta s'est terminée sans erreur.

Si l'alarme
Connectivité au serveur LDAP perdue
est déclenchée, résolvez cette alarme.

Si la connexion au serveur LDAP est active, suivez le message d'erreur dans le journal pour vérifier les modifications associées dans le serveur AD.