Catalogue d'événements

É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

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 NSX et NSX API`GET /api/v1/alarms` ont cessé de signaler de nouvelles alarmes ; cependant, 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 d'alarmes important 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, recherchez 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}`.

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 NSX et NSX APIGET /api/v1/alarms ont cessé de signaler de nouvelles alarmes ; cependant, 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 d'alarmes important 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, recherchez 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 de santé du journal d'audit

Les événements de santé du journal d'audit proviennent des nœuds de NSX Manager et de gestionnaire global.

Nom de l'événement	Gravité	Message d'alerte	Action recommandée
Sant du journal d'audit	Critique	Au moins un des fichiers journaux surveillés n'est pas accessible en écriture. Lorsque l'événement est détecté : « Au moins un des fichiers journaux surveillés dispose d'autorisations en lecture seule ou dispose d'une propriété d'utilisateur/de groupe incorrecte ; ou rsyslog.log est manquant sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public. » Lorsque l'événement est résolu : « Tous les fichiers journaux surveillés disposent des autorisations de fichier et de la propriété correctes ; rsyslog.log existe sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public. »	Sur tous les dispositifs NSX, par exemple, les nœuds de gestionnaire et les nœuds Edge, assurez-vous que l'autorisation pour le répertoire /var/log est 775 et que la propriété est root:syslog. Sur les nœuds de gestionnaire et de gestionnaire global, vérifiez que l'autorisation de fichier pour auth.log, nsx-audit.log, nsx-audit-write.log, rsyslog.log et syslog.log sous /var/log est 640 et que la propriété est syslog:admin. Sur les nœuds Edge et de passerelle de cloud public, assurez-vous que l'autorisation de fichier pour rsyslog.log et syslog.log sous /var/log est 640 et que la propriété est syslog:admin. Sur les nœuds d'hôtes ESXi, vérifiez que l'autorisation de fichier pour auth.log, nsx-syslog.log et syslog.log sous /var/log est 755 et que la propriété est root:root. Sur les nœuds d'hôtes KVM, vérifiez que l'autorisation de fichier pour auth.log et syslog.log sous /var/log est 775 et que la propriété est root:syslog. 6. Si l'un de ces fichiers dispose d'autorisations ou de propriétés incorrectes, appelez les commandes chmod <mode> <path> et chown <user>:<group> <path>. 7. Si rsyslog.log est manquant sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public, appelez la commande de l'interface de ligne de commande NSX restart service syslog qui redémarre le service de journalisation et régénère /var/log/rsyslog.log.
Erreur de serveur de journalisation distant	Critique	Messages de journal non livrables en raison d'une configuration incorrecte du serveur de journalisation distant. Lorsque l'événement est détecté : « Les messages de journal du serveur de journalisation `{hostname_or_ip_address_with_port}` (`{entity_id}`) ne peuvent pas être distribués probablement en raison d'un nom de domaine complet non résolu, d'un certificat TLS non valide ou d'une règle iptables de dispositif NSX manquante. » Lorsque l'événement est résolu : « La configuration du serveur de journalisation `{hostname_or_ip_address_with_port}` (`{entity_id}`) s'affiche correctement. »	Assurez-vous que `{hostname_or_ip_address_with_port}` est le nom d'hôte ou l'adresse IP et le port corrects. Si le serveur de journalisation est spécifié à l'aide d'un nom de domaine complet, assurez-vous que le nom de domaine complet peut être résolu à partir du dispositif NSX à l'aide de la commande de l'interface de ligne de commande NSX nslookup <fqdn>. Si elle ne peut pas être résolue, vérifiez que le nom de domaine complet correct est spécifié et que le serveur DNS du réseau dispose de l'entrée requise pour le nom de domaine complet. Si le serveur de journalisation est configuré pour utiliser TLS, vérifiez que le certificat spécifié est valide. Par exemple, assurez-vous que le serveur de journalisation utilise réellement le certificat ou vérifiez que le certificat n'a pas expiré à l'aide de la commande openssl openssl x509 -in <cert-file-path> -noout -dates. Les dispositifs NSX utilisent des règles iptables pour autoriser explicitement le trafic sortant. Vérifiez que la règle iptables pour le serveur de journalisation est correctement configurée en appelant la commande verify logging-servers de l'interface de ligne de commande NSX qui reconfigure les règles iptables du serveur de journalisation si nécessaire. Si, pour une raison quelconque, le serveur de journalisation est mal configuré, il doit être supprimé à l'aide de la commande del logging-server <hostname-or-ip-address[:port]> proto <proto> level <level> de l'interface de ligne de commande NSX et rajouté avec la configuration appropriée. Pour en savoir plus sur la façon de configurer des dispositifs et des hyperviseurs NSX-T Data Center pour envoyer des messages de journal à un serveur de journalisation distant, reportez-vous à la section Configurer la journalisation à distance. Si le serveur de journaux distant ne reçoit pas les journaux, reportez-vous à la section Résolution des problèmes de Syslog.

Nom de l'événement

Gravité

Message d'alerte

Action recommandée

Sant du journal d'audit

Critique

Au moins un des fichiers journaux surveillés n'est pas accessible en écriture.

Lorsque l'événement est détecté : « Au moins un des fichiers journaux surveillés dispose d'autorisations en lecture seule ou dispose d'une propriété d'utilisateur/de groupe incorrecte ; ou rsyslog.log est manquant sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public. »

Lorsque l'événement est résolu : « Tous les fichiers journaux surveillés disposent des autorisations de fichier et de la propriété correctes ; rsyslog.log existe sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public. »

Sur tous les dispositifs NSX, par exemple, les nœuds de gestionnaire et les nœuds Edge, assurez-vous que l'autorisation pour le répertoire /var/log est 775 et que la propriété est root:syslog.
Sur les nœuds de gestionnaire et de gestionnaire global, vérifiez que l'autorisation de fichier pour auth.log, nsx-audit.log, nsx-audit-write.log, rsyslog.log et syslog.log sous /var/log est 640 et que la propriété est syslog:admin.
Sur les nœuds Edge et de passerelle de cloud public, assurez-vous que l'autorisation de fichier pour rsyslog.log et syslog.log sous /var/log est 640 et que la propriété est syslog:admin.
Sur les nœuds d'hôtes ESXi, vérifiez que l'autorisation de fichier pour auth.log, nsx-syslog.log et syslog.log sous /var/log est 755 et que la propriété est root:root.
Sur les nœuds d'hôtes KVM, vérifiez que l'autorisation de fichier pour auth.log et syslog.log sous /var/log est 775 et que la propriété est root:syslog. 6. Si l'un de ces fichiers dispose d'autorisations ou de propriétés incorrectes, appelez les commandes chmod <mode> <path> et chown <user>:<group> <path>. 7. Si rsyslog.log est manquant sur les nœuds de gestionnaire, de gestionnaire global, de dispositif Edge ou de passerelle de cloud public, appelez la commande de l'interface de ligne de commande NSX restart service syslog qui redémarre le service de journalisation et régénère /var/log/rsyslog.log.

Erreur de serveur de journalisation distant

Critique

Messages de journal non livrables en raison d'une configuration incorrecte du serveur de journalisation distant.

Lorsque l'événement est détecté : « Les messages de journal du serveur de journalisation {hostname_or_ip_address_with_port} ({entity_id}) ne peuvent pas être distribués probablement en raison d'un nom de domaine complet non résolu, d'un certificat TLS non valide ou d'une règle iptables de dispositif NSX manquante. »

Lorsque l'événement est résolu : « La configuration du serveur de journalisation {hostname_or_ip_address_with_port} ({entity_id}) s'affiche correctement. »

Assurez-vous que {hostname_or_ip_address_with_port} est le nom d'hôte ou l'adresse IP et le port corrects.
Si le serveur de journalisation est spécifié à l'aide d'un nom de domaine complet, assurez-vous que le nom de domaine complet peut être résolu à partir du dispositif NSX à l'aide de la commande de l'interface de ligne de commande NSX nslookup <fqdn>. Si elle ne peut pas être résolue, vérifiez que le nom de domaine complet correct est spécifié et que le serveur DNS du réseau dispose de l'entrée requise pour le nom de domaine complet.
Si le serveur de journalisation est configuré pour utiliser TLS, vérifiez que le certificat spécifié est valide. Par exemple, assurez-vous que le serveur de journalisation utilise réellement le certificat ou vérifiez que le certificat n'a pas expiré à l'aide de la commande openssl openssl x509 -in <cert-file-path> -noout -dates.
Les dispositifs NSX utilisent des règles iptables pour autoriser explicitement le trafic sortant. Vérifiez que la règle iptables pour le serveur de journalisation est correctement configurée en appelant la commande verify logging-servers de l'interface de ligne de commande NSX qui reconfigure les règles iptables du serveur de journalisation si nécessaire.
Si, pour une raison quelconque, le serveur de journalisation est mal configuré, il doit être supprimé à l'aide de la commande del logging-server <hostname-or-ip-address[:port]> proto <proto> level <level> de l'interface de ligne de commande NSX et rajouté avec la configuration appropriée.

Pour en savoir plus sur la façon de configurer des dispositifs et des hyperviseurs NSX-T Data Center pour envoyer des messages de journal à un serveur de journalisation distant, reportez-vous à la section Configurer la journalisation à distance.

Si le serveur de journaux distant ne reçoit pas les journaux, reportez-vous à la section Résolution des problèmes de Syslog.

É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	Une capacité maximale a été dépassée. Lorsque l'événement est détecté : « Le nombre d'objets définis dans le système pour `{capacity_display_name}` a atteint `{capacity_usage_count}`, ce qui est égal ou supérieur au nombre maximal de `{max_supported_capacity_count}` pris en charge. » Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour `{capacity_display_name}` a atteint `{capacity_usage_count}` et est inférieur au nombre maximal de `{max_supported_capacity_count}` pris en charge. »	Assurez-vous que le nombre d'objets NSX créés est compris dans les limites prises en charge par NSX. S'il existe des objets inutilisés, supprimez-les à l'aide de l'interface utilisateur ou de de l'API NSX respective du système. Envisagez d'augmenter le format de tous les nœuds de gestionnaire et/ou des nœuds Edge. Notez que le format de chaque type de nœud doit être le même. Dans le cas contraire, les limites de capacité du format le plus bas déployé sont utilisées.
Seuil de capacité maximal	Élevé	Un seuil de capacité maximale a été dépassé. Lorsque l'événement est détecté : « Le nombre d'objets définis dans le système pour `{capacity_display_name}` a atteint {capacity_usage_count}, ce qui est égal ou supérieur au seuil de capacité maximal de `{max_supported_capacity_count}` %. » Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour `{capacity_display_name}` a atteint `{capacity_usage_count}` et est inférieur au seuil de capacité maximal `{max_supported_capacity_count}` %. »	Accédez à la page de capacité dans l'interface utilisateur de NSX et vérifiez l'utilisation actuelle par rapport aux limites de seuil. Si l'utilisation actuelle est attendue, envisagez d'augmenter les valeurs de seuil maximales. Si l'utilisation actuelle est inattendue, vérifiez les stratégies de réseau configurées pour diminuer l'utilisation sous le seuil maximal.
Seuil de capacité minimal	Moyenne	Un seuil de capacité minimale a été dépassé. Lorsque l'événement est détecté : « Le nombre d'objets définis dans le système pour `{capacity_display_name}` a atteint `{capacity_usage_count}`, ce qui est égal ou supérieur au seuil de capacité minimal de `{max_supported_capacity_count}` %. » Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour `{capacity_display_name}` a atteint `{capacity_usage_count}` et est inférieur au seuil de capacité minimal de `{max_supported_capacity_count}` %. »	Accédez à la page de capacité dans l'interface utilisateur de NSX et vérifiez l'utilisation actuelle par rapport aux limites de seuil. Si l'utilisation actuelle est attendue, envisagez d'augmenter les valeurs de seuil minimales. Si l'utilisation actuelle est inattendue, vérifiez les stratégies de réseau configurées pour diminuer l'utilisation sous le seuil minimal.

Nom de l'événement

Gravité

Message d'alerte

Action recommandée

Capacité maximale

Critique

Une capacité maximale a été dépassée.

Lorsque l'événement est détecté : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, ce qui est égal ou supérieur au nombre maximal de {max_supported_capacity_count} pris en charge. »

Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count} et est inférieur au nombre maximal de {max_supported_capacity_count} pris en charge. »

Assurez-vous que le nombre d'objets NSX créés est compris dans les limites prises en charge par NSX. S'il existe des objets inutilisés, supprimez-les à l'aide de l'interface utilisateur ou de de l'API NSX respective du système.
Envisagez d'augmenter le format de tous les nœuds de gestionnaire et/ou des nœuds Edge. Notez que le format de chaque type de nœud doit être le même. Dans le cas contraire, les limites de capacité du format le plus bas déployé sont utilisées.

Seuil de capacité maximal

Élevé

Un seuil de capacité maximale a été dépassé.

Lorsque l'événement est détecté : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, ce qui est égal ou supérieur au seuil de capacité maximal de {max_supported_capacity_count} %. »

Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count} et est inférieur au seuil de capacité maximal {max_supported_capacity_count} %. »

Accédez à la page de capacité dans l'interface utilisateur de NSX et vérifiez l'utilisation actuelle par rapport aux limites de seuil. Si l'utilisation actuelle est attendue, envisagez d'augmenter les valeurs de seuil maximales. Si l'utilisation actuelle est inattendue, vérifiez les stratégies de réseau configurées pour diminuer l'utilisation sous le seuil maximal.

Seuil de capacité minimal

Moyenne

Un seuil de capacité minimale a été dépassé.

Lorsque l'événement est détecté : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count}, ce qui est égal ou supérieur au seuil de capacité minimal de {max_supported_capacity_count} %. »

Lorsque l'événement est résolu : « Le nombre d'objets définis dans le système pour {capacity_display_name} a atteint {capacity_usage_count} et est inférieur au seuil de capacité minimal de {max_supported_capacity_count} %. »

Accédez à la page de capacité dans l'interface utilisateur de NSX et vérifiez l'utilisation actuelle par rapport aux limites de seuil. Si l'utilisation actuelle est attendue, envisagez d'augmenter les valeurs de seuil minimales. Si l'utilisation actuelle est inattendue, vérifiez les stratégies de réseau configurées pour diminuer l'utilisation sous le seuil minimal.

É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

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>` où <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}`
Le certificat est 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>` où <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>` où <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}`

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>

où <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}

Le certificat est 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>

où <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>

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

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.

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 de DFW	Critique	L'utilisation du CPU de DFW 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 : « 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}` %. »	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 de DFW	Critique	L'utilisation de la mémoire de DFW 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.

Nom de l'événement

Gravité

Message d'alerte

Action recommandée

Utilisation très élevée du CPU de DFW

Critique

L'utilisation du CPU de DFW 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 : « 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} %. »

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 de DFW

Critique

L'utilisation de la mémoire de DFW 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 d'IDS/IPS distribué

Des événements IDS/IPS distribués 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 moteur NSX IDPS	Critique	L'utilisation du CPU du moteur NSX-IDPS a dépassé 95 % ou plus. Lorsque l'événement est détecté : « L'utilisation du CPU du moteur NSX-IDPS a atteint `{system_resource_usage}` %, ce qui est supérieur ou égal à la valeur de seuil très élevée de 95 %. » Lorsque l'événement est résolu : « L'utilisation du CPU du moteur NSX-IDPS a atteint `{system_resource_usage}` %, ce qui est inférieur à la valeur de seuil très élevée de 95 %. »	Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.
Moteur NSX IDPS inactif	Critique	NSX IDPS est activé via la stratégie NSX et les règles IDPS sont configurées, mais le moteur NSX-IDPS est inactif. Lorsque l'événement est détecté : « NSX IDPS est activé via la stratégie NSX et les règles IDPS sont configurées, mais le moteur NSX-IDPS est inactif. » Lorsque l'événement est résolu : « NSX IDPS est dans l'un des cas ci-dessous. 1. NSX IDPS est désactivé via la stratégie NSX. 2. Le moteur NSX IDPS est activé, le moteur NSX IDPS et vdpi sont actifs, et NSX IDPS a été activé et les règles IDPS sont configurées via la stratégie NSX. »	Vérifiez /var/log/nsx-idps/nsx-idps.log et /var/log/nsx-syslog.log pour voir si des erreurs sont signalées. Appelez la commande de l'interface de ligne de commande NSX suivante pour vérifier si NSX IDPS distribué est dans un état désactivé. get ids engine status Si c'est le cas, appelez la commande de l'interface de ligne de commande NSX suivante pour démarrer le service. /etc/init.d/nsx-idps start Appelez la commande de l'interface de ligne de commande NSX suivante pour vérifier si nsx-vdpi est en cours d'exécution. /etc/init.d/nsx-vdpi status Si ce n'est pas le cas, appelez la commande de l'interface de ligne de commande NSX suivante pour démarrer le service. /etc/init.d/nsx-vdpi start
Utilisation très élevée de la mémoire du moteur NSX IDPS	Critique	L'utilisation de la mémoire du moteur NSX-IDPS atteint 95% ou plus. Lorsque l'événement est détecté : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint `{system_resource_usage}` %, ce qui est supérieur ou égal à la valeur de seuil très élevée de 95 %. » Lorsque l'événement est résolu : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint `{system_resource_usage}` %, ce qui est inférieur à la valeur de seuil très élevée de 95 %. »	Pensez à rééquilibrer les charges de travail de VM sur cet hôte vers d'autres hôtes.

Nom de l'événement

Gravité

Message d'alerte

Action recommandée

Utilisation très élevée du CPU du moteur NSX IDPS

Critique

L'utilisation du CPU du moteur NSX-IDPS a dépassé 95 % ou plus.

Lorsque l'événement est détecté : « L'utilisation du CPU du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de 95 %. »

Lorsque l'événement est résolu : « L'utilisation du CPU du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de 95 %. »

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

Moteur NSX IDPS inactif

Critique

NSX IDPS est activé via la stratégie NSX et les règles IDPS sont configurées, mais le moteur NSX-IDPS est inactif.

Lorsque l'événement est détecté : « NSX IDPS est activé via la stratégie NSX et les règles IDPS sont configurées, mais le moteur NSX-IDPS est inactif. »

Lorsque l'événement est résolu : « NSX IDPS est dans l'un des cas ci-dessous. 1. NSX IDPS est désactivé via la stratégie NSX. 2. Le moteur NSX IDPS est activé, le moteur NSX IDPS et vdpi sont actifs, et NSX IDPS a été activé et les règles IDPS sont configurées via la stratégie NSX. »

Vérifiez /var/log/nsx-idps/nsx-idps.log et /var/log/nsx-syslog.log pour voir si des erreurs sont signalées.
Appelez la commande de l'interface de ligne de commande NSX suivante pour vérifier si NSX IDPS distribué est dans un état désactivé.
get ids engine status
Si c'est le cas, appelez la commande de l'interface de ligne de commande NSX suivante pour démarrer le service.
/etc/init.d/nsx-idps start
Appelez la commande de l'interface de ligne de commande NSX suivante pour vérifier si nsx-vdpi est en cours d'exécution.
/etc/init.d/nsx-vdpi status
Si ce n'est pas le cas, appelez la commande de l'interface de ligne de commande NSX suivante pour démarrer le service.
/etc/init.d/nsx-vdpi start

Utilisation très élevée de la mémoire du moteur NSX IDPS

Critique

L'utilisation de la mémoire du moteur NSX-IDPS atteint 95% ou plus.

Lorsque l'événement est détecté : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est supérieur ou égal à la valeur de seuil très élevée de 95 %. »

Lorsque l'événement est résolu : « L'utilisation de la mémoire du moteur NSX-IDPS a atteint {system_resource_usage} %, ce qui est inférieur à la valeur de seuil très élevée de 95 %. »

Pensez à rééquilibrer les charges de travail de VM 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. »	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. Vérifiez /var/log/syslog pour voir si des erreurs sont signalées. Collectez un bundle de support et contactez l'équipe du support NSX.
Redirecteur désactivé Note : Alarme abandonnée à partir de NSX-T Data Center 3.2.	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é. »	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é. 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é.

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

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.
Vérifiez /var/log/syslog pour voir si des erreurs sont signalées.
Collectez un bundle de support et contactez l'équipe du support NSX.

Redirecteur désactivé

Note : Alarme abandonnée à partir de NSX-T Data Center 3.2.

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

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

Des événements Edge se produisent en cas de discordance entre NSX et le dispositif Edge pour certaines valeurs de configuration du nœud de transport Edge.

Nom de l'événement	Gravité	Message d'alerte	Action recommandée
Incompatibilité des paramètres de nœud Edge	Critique	Incompatibilité des paramètres de nœud Edge. Lorsque l'événement est détecté : « La configuration des paramètres du nœud Edge `{entity_id}` ne correspond pas à celle de l'intention de stratégie. La configuration du nœud Edge visible par l'utilisateur sur l'interface utilisateur ou l'API n'est pas la même que celle réalisée. Les modifications réalisées du nœud Edge apportées par l'utilisateur en dehors de NSX Manager sont affichées dans les détails de cette alarme et toutes les modifications apportées à l'interface utilisateur ou à l'API remplaceront la configuration réalisée. Les champs qui diffèrent pour le nœud Edge sont répertoriés dans les données d'exécution. » Lorsque l'événement est résolu : « Les paramètres du nœud Edge `{entity_id}` nœud sont désormais cohérents avec l'intention de stratégie. »	Vérifiez les paramètres de ce nœud de transport Edge `{entity_id}`. Effectuez l'une des actions suivantes pour résoudre l'alarme. Mettez à jour manuellement l'intention de stratégie du paramètre de nœud de transport Edge à l'aide de l'API `PUT https://<manager-ip>/api/v1/transport-nodes/<tn-id>`. Acceptez les paramètres d'intention ou de nœud Edge réalisés pour ce nœud de transport Edge via le programme de résolution de nœud de transport Edge. Acceptez la configuration des paramètres du nœud Edge à l'aide de l'API d'actualisation `POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=refresh_node_configuration&resource_type=EdgeNode`.
Incompatibilité des paramètres vSphere de la VM Edge	Critique	Incompatibilité des paramètres vSphere de la VM Edge. Lorsque l'événement est détecté : « La configuration du nœud Edge `{entity_id}` sur vSphere ne correspond pas à celle de l'intention de stratégie. » La configuration du nœud Edge visible par l'utilisateur sur l'interface utilisateur ou l'API n'est pas la même que celle réalisée. Les modifications réalisées du nœud Edge apportées par l'utilisateur en dehors de NSX Manager sont affichées dans les détails de cette alarme et toutes les modifications apportées à l'interface utilisateur ou à l'API remplaceront la configuration réalisée. Les champs qui diffèrent pour le nœud Edge sont répertoriés dans les données d'exécution. » Lorsque l'événement est résolu : « Les paramètres vSphere de la VM du nœud Edge `{entity_id}` sont désormais cohérents avec l'intention de stratégie. »	Vérifiez la configuration vSphere de ce nœud de transport Edge `{entity_id}`. Effectuez l'une des actions suivantes pour résoudre l'alarme. Acceptez l'intention ou la configuration du nœud Edge réalisée par vSphere pour ce nœud de transport Edge via le programme de résolution de nœud de transport Edge. Résolvez l'alarme en acceptant la configuration du nœud Edge réalisée par vSphere à l'aide de l'API d'actualisation `POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=refresh_node_configuration&resource_type=EdgeNode`.
Les paramètres de nœud Edge et les paramètres vSphere sont modifiés	Critique	Les paramètres du nœud Edge et les paramètres vSphere sont modifiés. Lorsque l'événement est détecté : « Les paramètres du nœud Edge `{entity_id}` et la configuration de vSphere sont modifiés et ne correspondent pas à la configuration de l'intention de stratégie. La configuration du nœud Edge visible par l'utilisateur sur l'interface utilisateur ou l'API n'est pas la même que celle réalisée. Les modifications réalisées du nœud Edge apportées par l'utilisateur en dehors de NSX Manager sont affichées dans les détails de cette alarme et toutes les modifications apportées à l'interface utilisateur ou à l'API remplaceront la configuration réalisée. Les champs qui diffèrent pour les paramètres du nœud Edge et la configuration de vSphere sont répertoriés dans les données d'exécution. » Lorsque l'événement est résolu : « Les paramètres du nœud Edge `{entity_id}` et les paramètres de vSphere sont désormais cohérents avec l'intention de stratégie. »	Vérifiez les paramètres du nœud et la configuration vSphere de ce nœud de transport Edge `{entity_id}`. Effectuez l'une des actions suivantes pour résoudre l'alarme. Mettez à jour manuellement l'intention de stratégie du paramètre de nœud de transport Edge à l'aide de l'API `PUT https://<manager-ip>/api/v1/transport-nodes/<tn-id>`. Acceptez l'intention ou la configuration du nœud Edge réalisée par vSphere ou les paramètres du nœud Edge réalisés pour ce nœud de transport Edge via le programme de résolution de nœud de transport Edge. Acceptez les paramètres du nœud Edge et la configuration réalisée par vSphere à l'aide de l'API d'actualisation P`OST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=refresh_node_configuration&resource_type=EdgeNode`.
Incompatibilité d'emplacement de vSphere Edge	Élevé	Incompatibilité d'emplacement de vSphere Edge. Lorsque l'événement est détecté : « Le nœud Edge `{entity_id}` a été déplacé à l'aide de vMotion. La configuration du nœud Edge `{entity_id}` sur vSphere ne correspond pas à la configuration de l'intention de stratégie. La configuration du nœud Edge visible par l'utilisateur sur l'interface utilisateur ou l'API n'est pas la même que celle réalisée. Les modifications réalisées du nœud Edge effectuées par l'utilisateur en dehors de NSX Manager sont affichées dans les détails de cette alarme. Les champs qui diffèrent pour le nœud Edge sont répertoriés dans les données d'exécution. » Lorsque l'événement est résolu : « Les paramètres vSphere du nœud Edge `{entity_id}` sont désormais cohérents avec l'intention de stratégie. »	Vérifiez la configuration vSphere de ce nœud de transport Edge `{entity_id}`. Effectuez l'une des actions suivantes pour résoudre l'alarme. Acceptez la configuration réalisée par vSphere du nœud Edge à l'aide de l'API d'actualisation `POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=refresh_node_configuration&resource_type=EdgeNode`. Si vous souhaitez revenir à l'emplacement précédent, utilisez l'API de redéploiement NSX `POST https://<manager-ip>/api/v1/transport-nodes/<tn-id>?action=redeploy`. L'utilisation de vMotion pour revenir à l'hôte d'origine n'est pas prise en charge.

É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é	Échec de la configuration du chemin de données du nœud Edge. 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.
CPU du chemin de données Edge très élevé	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 de l'interface de ligne de commande 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 de l'interface de ligne de commande 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.
Cryptodrv de chemin de données Edge inactif	Critique	Le pilote de cryptographie du nœud Edge est inactif Lorsque l'événement est détecté : « Le pilote de cryptographie du nœud Edge `{edge_crypto_drv_name}` est inactif. » Lorsque l'événement est résolu : « Le pilote de cryptographie du nœud Edge `{edge_crypto_drv_name}` est actif. »	Mettez à niveau le nœud Edge si nécessaire.
Pool de mémoire du chemin de données Edge é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é. »	Connectez-vous en tant qu'utilisateur racine et appelez la commande suivante pour vérifier si l'utilisation du cache neigh est normale. edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show Si elle est normale, appelez la commande suivante pour augmenter la taille de la table ARP. edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries
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	Moyenne	La carte réseau du nœud Edge n'a temporairement plus de tampons d'anneau de réception. 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}`. Le nombre de paquets manqués est `{rx_misses}` et le nombre de paquets traités est `{rx_processed}`. » 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. »	Exécutez la commande get dataplane cpu stats de l'interface de ligne de commande NSX sur le nœud Edge et vérifiez : Si l'utilisation du CPU est élevée, c'est-à-dire > 90 %, effectuez une capture de paquets sur l'interface à l'aide de la commande start capture interface <interface-name> direction input ou start capture interface <interface-name> direction input core <core-id> (pour capturer des paquets entrants sur un cœur spécifique dont l'utilisation est élevée). Analysez ensuite la capture pour vérifier si une majorité de paquets fragmentés ou de paquets ipsec est présente. Si c'est le cas, il s'agit du comportement attendu. Autrement, le chemin de données est probablement occupé avec d'autres opérations. Si cette alarme dure plus de 2 à 3 minutes, contactez le support VMware. 2. Si l'utilisation du CPU n'est pas élevée, c'est-à-dire < 90 %, vérifiez si le pps de réception est élevé à l'aide de la commande get dataplane cpu stats (pour vous assurer que le débit du trafic augmente). Augmentez ensuite la taille de l'anneau de 1 024 à l'aide de la commande set dataplane ring-size rx <ring-size>. Note : L'augmentation continue de la taille de l'anneau selon un facteur de 1 024 peut entraîner des problèmes de performances. Si, même après l'augmentation de la taille de l'anneau, le problème persiste, cela indique que le dispositif Edge a besoin d'un déploiement de format plus important pour prendre en charge le trafic. Si l'alarme continue de se bloquer, c'est-à-dire qu'elle se déclenche et se résout très bientôt, cela est dû à un trafic en rafale. Dans ce cas, vérifiez le pps de réception comme décrit ci-dessus. S'il n'est pas élevé pendant la période d'activité de l'alarme, contactez le support VMware. Si pps est élevé, cela confirme le trafic en rafale. Envisagez de supprimer l'alarme. Note : Il n'existe pas de référence permettant de définir une valeur pps comme élevée. Cela dépend de l'infrastructure et du type de trafic. La comparaison peut être effectuée en notant les moments où l'alarme est inactive et active.
Mémoire tampon de transmission insuffisante de la carte réseau Edge	Critique	La carte réseau du nœud Edge ne dispose temporairement plus de tampons d'anneau de transmission. Lorsque l'événement est détecté : « La mémoire tampon d'anneau de transmission 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}`. Le nombre de paquets manqués est `{tx_misses}` et le nombre de paquets traités est `{tx_processed}`. » Lorsque l'événement est résolu : « L'utilisation de la mémoire tampon de l'anneau de transmission de la carte réseau Edge `{edge_nic_name}` sur le nœud Edge `{entity_id}` ne dépasse plus. »	Si un grand nombre de machines virtuelles sont prises en charge avec Edge par l'hyperviseur, il se peut que la VM Edge n'ait pas le temps de s'exécuter. Par conséquent, les paquets peuvent ne pas être récupérés par l'hyperviseur. Envisagez ensuite de migrer la machine virtuelle Edge vers un hôte avec moins de machines virtuelles. Augmentez la taille de l'anneau de 1 024 à l'aide de la commande set dataplane ring-size tx <ring-size>. Si, même après l'augmentation de la taille de l'anneau, le problème persiste, contactez le support VMware, car la mémoire tampon d'anneau de transmission côté ESX peut avoir une valeur inférieure. S'il n'y a aucun problème du côté ESX, cela indique que le dispositif Edge doit être mis à l'échelle pour un déploiement de format plus important afin d'intégrer le trafic. Si l'alarme continue de se bloquer, c'est-à-dire qu'elle se déclenche et se résout très bientôt, cela est dû à un trafic en rafale. Dans ce cas, vérifiez le pps transmis à l'aide de la commande get dataplane cpu stats. S'il n'est pas élevé pendant la période d'activité de l'alarme, contactez le support VMware. Si pps est élevé, cela confirme le trafic en rafale. Envisagez de supprimer l'alarme. Note : Il n'existe pas de référence permettant de définir une valeur pps comme élevée. Cela dépend de l'infrastructure et du type de trafic. La comparaison peut être effectuée en notant les moments où l'alarme est inactive et active.
Erreur de stockage	Critique	À partir de NSX-T Data Center 3.0.1. Lorsque l'événement est détecté : « Les partitions de disque suivantes sur le nœud Edge sont en lecture seule : `{disk_partition_name}`. » Lorsque l'événement est résolu : « Les partitions de disque suivantes sur le nœud Edge ont été récupérées 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. Contactez GSS pour plus d'informations.
Débit de la carte réseau du chemin de données Edge élevé	Moyenne	Le débit de la carte réseau du chemin de données du nœud Edge est élevé. Lorsque l'événement est détecté : « Le débit de la carte réseau du chemin de données pour `{edge_nic_name}` sur le nœud Edge `{entity-id}` a atteint `{nic_throughput}` %, ce qui est supérieur ou égal à la valeur de seuil élevée de `{nic_throughput_threshold}` %. » Lorsque l'événement est résolu : « Le débit de la carte réseau du chemin de données pour `{edge_nic_name}` sur le nœud Edge `{entity-id}` a atteint `{nic_throughput}` %, ce qui est inférieur à la valeur de seuil élevée de `{nic_throughput_threshold}` %. »	Examinez les niveaux de débit du trafic sur la carte réseau et déterminez si des modifications de configuration sont nécessaires. Exécutez la commande suivante pour surveiller le débit. get dataplane throughput <seconds>
Débit de la carte réseau du chemin de données Edge très élevé	Critique	Le débit de la carte réseau du chemin de données du nœud Edge est très élevé. Lorsque l'événement est détecté : « Le débit de la carte réseau du chemin de données pour `{edge_nic_name}` sur le nœud Edge `{entity-id}` a atteint `{nic_throughput}` %, ce qui est supérieur ou égal à la valeur de seuil très élevée de `{nic_throughput_threshold}` %. » Lorsque l'événement est résolu : « Le débit de la carte réseau du chemin de données pour `{edge_nic_name}` sur le nœud Edge `{entity-id}` a atteint `{nic_throughput}` %, ce qui est inférieur à la valeur de seuil très élevée de `{nic_throughput_threshold}` %. »	Examinez les niveaux de débit du trafic sur la carte réseau et déterminez si des modifications de configuration sont nécessaires. Appelez la commande de l'interface de ligne de commande NSX suivante pour surveiller le débit. get dataplane throughput <seconds>
Domaine de pannes inactif	Critique	Tous les membres du domaine de pannes sont inactifs. Lorsque l'événement est détecté : « Tous les membres du domaine de pannes `{transport_node_id}` sont inactifs. » Lorsque l'événement est résolu : « Tous les membres du domaine de pannes `{transport_node_id}` sont accessibles. »	Sur le nœud Edge identifié par `{transport_node_id}`, vérifiez la connectivité aux plans de gestion et de contrôle en appelez la commande de l'interface de ligne de commande NSX suivante. get managers et get controllers Appelez la commande de l'interface de ligne de commande NSX suivante pour vérifier l'état de l'interface de gestion. get interface eth0 Appelez l'interface de ligne de commande NSX suivante pour vérifier l'état des services de base, tels que dataplane/local-controller/nestdb/routeur, etc. get services Inspectez le fichier /var/log/syslog pour localiser l'erreur suspecte. redémarrez le nœud Edge.
Thread de chemin de données bloqué	Critique	Le thread de chemin de données du nœud Edge est dans une condition de blocage. Lorsque l'événement est détecté : « Le thread du chemin de données du nœud Edge `{edge_thread_name}` est bloqué. » Lorsque l'événement est résolu : « Le thread du chemin de données du nœud Edge `{edge_thread_name}` n'est pas bloqué. »	Redémarrez le service de plan de données en appelant la commande de l'interface de ligne de commande NSX suivante. restart service dataplane

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

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}` %. »	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 Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale. 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}` %. »	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 Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale. 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} %. »	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 Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale. 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}` %. »	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 Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale. 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}` %. »	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 Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale. 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}` %. »	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 Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale. 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. »	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 Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale. 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. »	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 Vérifiez que le flux de trafic passant par la passerelle n'est pas une attaque DOS ou une rafale anormale. 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. »	Appelez la commande get logical-router <service_router_id> de l'interface de ligne de commande NSX pour obtenir l'ID VRF du routeur de service de niveau 0. Basculez vers le contexte VRF en appelant vrf <vrf-id>, puis appelez get high-availability status pour déterminer le service inactif.
Basculement de la passerelle de niveau 1	Élevé	Une passerelle de niveau 1 a basculé. Lorsque l'événement est détecté : « La passerelle de niveau 1 `{entity_id}` bascule de `{previous_gateway_state}` vers `{current_gateway_state}`, service-router `{service_router_id}`. » Lorsque l'événement est résolu : « La passerelle de niveau 1 `{entity-id}` est maintenant active. »	Appelez la commande get logical-router <service_router_id> de l'interface de ligne de commande NSX pour obtenir l'ID VRF du routeur de service de niveau 1. Basculez vers le contexte VRF en appelant vrf <vrf-id>, puis appelez get high-availability status pour déterminer le service inactif.

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

Appelez la commande get logical-router <service_router_id> de l'interface de ligne de commande NSX pour obtenir l'ID VRF du routeur de service de niveau 0.
Basculez vers le contexte VRF en appelant vrf <vrf-id>, puis appelez get high-availability status pour déterminer le service inactif.

Basculement de la passerelle de niveau 1

Élevé

Une passerelle de niveau 1 a basculé.

Lorsque l'événement est détecté : « La passerelle de niveau 1 {entity_id} bascule de {previous_gateway_state} vers {current_gateway_state}, service-router {service_router_id}. »

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

Appelez la commande get logical-router <service_router_id> de l'interface de ligne de commande NSX pour obtenir l'ID VRF du routeur de service de niveau 1.
Basculez vers le contexte VRF en appelant vrf <vrf-id>, puis appelez get high-availability status pour déterminer le service inactif.

É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é : « La connectivité au serveur LDAP `{ldap_server}` est perdue. » Lorsque l'événement est détecté : « La connectivité au serveur LDAP `{ldap_server}` est restaurée. »	Suivez les étapes décrites ci-dessous pour vérifier la connectivité du serveur LDAP : Le serveur LDAP est accessible à partir des nœuds NSX. Les détails du serveur LDAP sont correctement configurés dans NSX. Le serveur LDAP s'exécute correctement. Aucun pare-feu ne bloque l'accès entre le serveur LDAP et les nœuds NSX. Une fois le problème résolu, utilisez TEST CONNECTION dans l'interface utilisateur NSX sous Annuaire AD de pare-feu d'identité pour tester la connexion.
Erreur lors de la synchronisation Delta	Critique	Des erreurs se sont produites lors de l'exécution de la synchronisation Delta. Lorsque l'événement est détecté : « Des erreurs se sont produites lors de l'exécution de la synchronisation delta avec `{directory_domain}`. » Lorsque l'événement est détecté : « Aucune erreur ne s'est produite lors de l'exécution de la synchronisation delta avec `{directory_domain}`. »	Vérifiez s'il existe des alarmes de connectivité au serveur LDAP perdu. Recherchez les détails de l'erreur dans /var/log/syslog. Autour de l'heure du déclenchement de l'alarme, recherchez le texte : Une erreur s'est produite lors de la synchronisation des objets LDAP. Vérifiez auprès de l'administrateur AD si des modifications récentes apportées à AD peuvent provoquer les erreurs. Si les erreurs persistent, collectez le bundle de support technique et contactez le support VMware.

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é : « La connectivité au serveur LDAP {ldap_server} est perdue. »

Lorsque l'événement est détecté : « La connectivité au serveur LDAP {ldap_server} est restaurée. »

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

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

Une fois le problème résolu, utilisez TEST CONNECTION dans l'interface utilisateur NSX sous Annuaire AD de pare-feu d'identité pour tester la connexion.

Erreur lors de la synchronisation Delta

Critique

Des erreurs se sont produites lors de l'exécution de la synchronisation Delta.

Lorsque l'événement est détecté : « Des erreurs se sont produites lors de l'exécution de la synchronisation delta avec {directory_domain}. »

Lorsque l'événement est détecté : « Aucune erreur ne s'est produite lors de l'exécution de la synchronisation delta avec {directory_domain}. »

Vérifiez s'il existe des alarmes de connectivité au serveur LDAP perdu.
Recherchez les détails de l'erreur dans /var/log/syslog. Autour de l'heure du déclenchement de l'alarme, recherchez le texte : Une erreur s'est produite lors de la synchronisation des objets LDAP.
Vérifiez auprès de l'administrateur AD si des modifications récentes apportées à AD peuvent provoquer les erreurs.
Si les erreurs persistent, collectez le bundle de support technique et contactez le support VMware.

É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. »	Appelez la commande de l'interface de ligne de commande NSX suivante pour obtenir tous les ports de tunnel. get tunnel-ports Ensuite, vérifiez les statistiques de chaque tunnel en appelant la commande de l'interface de ligne de commande NSX suivante pour vérifier s'il existe des abandons. get tunnel-port <UUID> stats Recherchez également dans /var/log/syslog s'il existe des erreurs liées au tunnel.

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

Appelez la commande de l'interface de ligne de commande NSX suivante pour obtenir tous les ports de tunnel.
get tunnel-ports
Ensuite, vérifiez les statistiques de chaque tunnel en appelant la commande de l'interface de ligne de commande NSX suivante pour vérifier s'il existe des abandons.
get tunnel-port <UUID> stats
Recherchez également dans /var/log/syslog s'il existe des erreurs liées au tunnel.

É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. »	Redémarrez le service de messagerie s'il n'est pas en cours d'exécution dans le nœud NSX Intelligence. 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	La connexion du service de contrôleur à la connexion du nœud de transport est inactive. Lorsque l'événement est détecté : « Le service de contrôleur sur le nœud Edge `{appliance_address}` (`{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 sur le nœud de gestionnaire `{appliance_address}` (`{central_control_plane_id}`) rétablit la connexion au nœud de transport `{entity_id}`. »	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. 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/. 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	Le service de contrôleur pour la connexion du nœud de transport est inactif pendant trop longtemps. Lorsque l'événement est détecté : « Le service de contrôleur sur le nœud Edge `{appliance_address}` (`{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 sur le nœud de gestionnaire `{appliance_address}` (`{central_control_plane_id}`) rétablit la connexion au nœud de transport `{entity_id}`. »	Vérifiez la connectivité à partir du service de contrôleur `{central_control_plane_id}` et de l'interface du nœud de transport `{entity_id}` à l'aide d'un test ping et de traceroute. Cela peut être effectué sur l'interface de ligne de commande d'administration du nœud NSX Manager. Le test ping ne doit pas voir d'abandons et doit avoir des valeurs de latence cohérentes. VMware recommande des valeurs de latence de 150 ms ou moins. Accédez à Système > Infrastructure > Nœuds > Nœuds de transport `{entity_id}` sur l'interface utilisateur de NSX pour vérifier si les connexions TCP entre le service de contrôleur sur le nœud de gestionnaire `{appliance_address}` (`{central_control_plane_id}`) et le nœud de transport `{entity_id}` est établi. Si ce n'est pas le cas, vérifiez les règles de pare-feu sur le réseau et les hôtes 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 notre outil ports et protocoles disponible ici : https://ports.vmware.com/.
Canal de contrôle vers le nœud de gestionnaire inactif	Moyenne	La connexion du plan de contrôle du nœud de transport au nœud de gestionnaire est inactive. Lorsque l'événement est détecté : « La connexion du plan de contrôle du nœud de transport `{entity_id}` au nœud de gestionnaire `{appliance_address}` est inactive pendant au moins `{timeout_in_minutes}` minutes du point de vue du nœud de transport. » Lorsque l'événement est résolu : « Le nœud de transport `{entity_id}` restaure la connexion du plan de contrôle au nœud de gestionnaire `{appliance_address}`. »	Vérifiez la connectivité entre le nœud de transport `{entity_id}` et l'interface du nœud de gestionnaire `{appliance_address}` via un test ping. Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité réseau. Vérifiez si les connexions TCP sont établies à l'aide de la sortie netstat pour déterminer si le service de contrôleur sur le nœud de gestionnaire `{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 notre outil ports et protocoles disponible ici : https://ports.vmware.com/. 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 : Remarque : cette alarme n'est pas critique et doit être résolue. GSS n'a pas besoin d'être contacté pour la notification de cette alarme, sauf si l'alarme reste non résolue pendant une période prolongée.
Canal de contrôle vers le nœud de gestionnaire inactif pendant trop longtemps	Critique	La connexion du plan de contrôle du nœud de transport au nœud de gestionnaire est inactive pendant un long moment. Lorsque l'événement est détecté : « La connexion du plan de contrôle du nœud de transport `{entity_id}` au nœud de gestionnaire `{appliance_address}` est inactive pendant au moins `{timeout_in_minutes}` minutes du point de vue du nœud de transport. » Lorsque l'événement est résolu : « Le nœud de transport `{entity_id}` restaure la connexion du plan de contrôle au nœud de gestionnaire `{appliance_address}`. »	Vérifiez la connectivité entre le nœud de transport `{entity_id}` et l'interface du nœud de gestionnaire `{appliance_address}` via un test ping. Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité réseau. Vérifiez si les connexions TCP sont établies à l'aide de la sortie netstat pour déterminer si le service de contrôleur sur le nœud de gestionnaire `{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 notre outil ports et protocoles disponible ici : https://ports.vmware.com/. 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é.
Canal de gestion vers le nœud de transport inactif	Moyenne	Le canal de gestion vers le nœud de transport est inactif. Lorsque l'événement est détecté : « Le canal de gestion vers le nœud de transport `{transport_node_name}` (`{transport_node_address}`) est inactif pendant 5 minutes. » Lorsque l'événement est résolu : « Le canal de gestion vers le nœud de transport `{transport_node_name}` (`{transport_node_address}`) est actif. »	Assurez-vous qu'il existe une connectivité réseau entre les nœuds de gestionnaire et le nœud de transport `{transport_node_name}` (`{transport_node_address}`) et qu'aucun pare-feu ne bloque le trafic entre les nœuds. Sur les nœuds de transport Windows, assurez-vous que le service nsx-proxy est en cours d'exécution sur le nœud de transport en appelant la commande suivante dans Windows PowerShell. C:NSX\nsx-proxy\nsx-proxy.ps1 status S'il n'est pas en cours d'exécution, redémarrez-le en appelant la commande suivante. C:NSX\nsx-proxy\nsx-proxy.ps1 restart Sur tous les autres nœuds de transport, assurez-vous que le service nsx-proxy est en cours d'exécution sur le nœud de transport en appelant la commande suivante. /etc/init.d/nsx-proxy status S'il n'est pas en cours d'exécution, redémarrez-le en appelant la commande suivante /etc/init.d/nsx-proxy restart.
Canal de gestion vers le nœud de transport inactif pendant longtemps	Critique	Le canal de gestion vers le nœud de transport est inactif pendant trop longtemps. Lorsque l'événement est détecté : « Le canal de gestion vers le nœud de transport `{transport_node_name}` (`{transport_node_address}`) est inactif pendant 15 minutes. » Lorsque l'événement est résolu : « Le canal de gestion vers le nœud de transport `{transport_node_name}` (`{transport_node_address}`) est actif. »	Assurez-vous qu'il existe une connectivité réseau entre les nœuds de gestionnaire et le nœud de transport `{transport_node_name}` (`{transport_node_address}`) et qu'aucun pare-feu ne bloque le trafic entre les nœuds. Sur les nœuds de transport Windows, assurez-vous que le service nsx-proxy est en cours d'exécution sur le nœud de transport en appelant la commande suivante dans Windows PowerShell. C:NSX\nsx-proxy\nsx-proxy.ps1 status S'il n'est pas en cours d'exécution, redémarrez-le en appelant la commande suivante. C:NSX\nsx-proxy\nsx-proxy.ps1 restart Sur tous les autres nœuds de transport, assurez-vous que le service nsx-proxy est en cours d'exécution sur le nœud de transport en appelant la commande suivante. /etc/init.d/nsx-proxy status S'il n'est pas en cours d'exécution, redémarrez-le en appelant la commande suivante /etc/init.d/nsx-proxy restart.
Latence du cluster de gestionnaire	Moyenne	La latence réseau moyenne entre les nœuds de gestionnaire est élevée. Lorsque l'événement est détecté : « La latence réseau moyenne entre les nœuds de gestionnaire `{manager_node_id}` (`{appliance_address}`) et `{remote_manager_node_id}` (`{remote_appliance_address}`) est supérieure à 10 ms au cours des 5 dernières minutes. » Lorsque l'événement est résolu : « La latence réseau moyenne entre les nœuds de gestionnaire `{manager_node_id}` (`{appliance_address}`) et `{remote_manager_node_id}` (`{remote_appliance_address`}) est inférieure à 10 ms. »	Assurez-vous qu'aucune règle de pare-feu ne bloque le trafic ping entre les nœuds de gestionnaire. S'il existe d'autres serveurs et applications à bande passante élevée partageant le réseau local, envisagez de les déplacer vers un autre réseau.
Canal de contrôle de gestionnaire inactif	Critique	Le canal entre le gestionnaire et le contrôleur est inactif. Lorsque l'événement est détecté : « La communication entre la fonction de gestion et la fonction de contrôle a échoué sur le nœud de gestionnaire {manager_node_name} (`{appliance_address}`). » Lorsque l'événement est résolu : « La communication entre la fonction de gestion et la fonction de contrôle a été restaurée sur le nœud de gestionnaire {manager_node_name} (`{appliance_address}`). »	Sur le nœud de gestionnaire `{manager_node_name}` (`{appliance_address}`), appelez les deux commandes de l'interface de ligne de commande NSX suivantes : restart service mgmt-plane-bus restart service manager
Échec de la recherche du nom de domaine complet du gestionnaire	Critique	Échec de la recherche DNS pour le nom de domaine complet du nœud de gestionnaire. Lorsque l'événement est détecté : « Échec de la recherche DNS pour le nœud de gestionnaire `{entity_id}` avec le nom de domaine complet `{appliance_fqdn}` et l'indicateur publish_fqdns a été défini. » Lorsque l'événement est résolu : « La recherche du nom de domaine complet a réussi pour le nœud de gestionnaire `{entity_id}` avec le nom de domaine complet `{appliance_fqdn}` ou l'indicateur publish_fqdns a été effacé. »	Attribuez des noms de domaine complets corrects à tous les nœuds de gestionnaire et vérifiez que la configuration DNS est correcte pour la recherche réussie de tous les noms de domaine complets des nœuds de gestionnaire. Vous pouvez également désactiver l'utilisation des noms de domaine complets en appelez NSX API suivante avec publish_fqdns défini sur false dans le corps de la demande. `PUT /api/v1/configs/management` Ensuite, les appels depuis les nœuds de transport et depuis Fédération vers les nœuds de gestionnaire dans ce cluster utiliseront uniquement des adresses IP.
Échec de la recherche inversée du nom de domaine complet du gestionnaire	Critique	Échec de la recherche DNS inversée pour l'adresse IP du nœud de gestionnaire. Lorsque l'événement est détecté : « Échec de la recherche DNS inverse pour le nœud de gestionnaire `{entity_id}` avec l'adresse IP `{appliance_address}` et l'indicateur publish_fqdns a été défini. » Lorsque l'événement est résolu : « La recherche DNS inverse a réussi pour le nœud de gestionnaire `{entity_id}` avec l'adresse IP `{appliance_fqdn}` ou l'indicateur publish_fqdns a été effacé. »	Attribuez des noms de domaine complets corrects à tous les nœuds de gestionnaire et vérifiez que la configuration DNS est correcte pour une recherche inversée réussie de l'adresse IP du nœud de gestionnaire. Vous pouvez également désactiver l'utilisation des noms de domaine complets en appelez NSX API suivante avec publish_fqdns défini sur false dans le corps de la demande. `PUT /api/v1/configs/management` Ensuite, les appels depuis les nœuds de transport et depuis Fédération vers les nœuds de gestionnaire dans ce cluster utiliseront uniquement des adresses IP.
Canal de gestion vers le nœud de gestionnaire inactif	Moyenne	Le canal de gestion vers le nœud de gestionnaire est inactif. Lorsque l'événement est détecté : « Le canal de gestion vers le nœud de gestionnaire `{manager_node_id}` (`{appliance_address}`) est inactif pendant 5 minutes. » Lorsque l'événement est résolu : « Le canal de gestion vers le nœud de gestionnaire `{manager_node_id}` (`{appliance_address}`) est actif. »	Assurez-vous qu'il existe une connectivité réseau entre le nœud de transport `{transport_node_id}` et le nœud de gestionnaire principal. Assurez-vous également qu'aucun pare-feu ne bloque le trafic entre les nœuds. Assurez-vous que le service du gestionnaire de messagerie est en cours d'exécution sur les nœuds de gestionnaire en appelant la commande suivante. /etc/init.d/messaging-manager status Si le gestionnaire de messagerie n'est pas en cours d'exécution, redémarrez-le en appelant la commande suivante. /etc/init.d/messaging-manager restart
Canal de gestion vers le nœud de gestionnaire inactif pendant longtemps	Critique	Le canal de gestion vers le nœud de gestionnaire est inactif pendant trop longtemps. Lorsque l'événement est détecté : « Le canal de gestion vers le nœud de gestionnaire `{manager_node_id}` (`{appliance_address}`) est inactif pendant 15 minutes. » Lorsque l'événement est résolu : « Le canal de gestion vers le nœud de gestionnaire `{manager_node_id}` (`{appliance_address}`) est actif. »	Assurez-vous qu'il existe une connectivité réseau entre le nœud de transport `{transport_node_id}` et le nœud de gestionnaire principal. Assurez-vous également qu'aucun pare-feu ne bloque le trafic entre les nœuds. Assurez-vous que le service du gestionnaire de messagerie est en cours d'exécution sur les nœuds de gestionnaire en appelant la commande suivante. /etc/init.d/messaging-manager status Si le gestionnaire de messagerie n'est pas en cours d'exécution, redémarrez-le en appelant la commande suivante. /etc/init.d/messaging-manager restart

É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

Nom de l'événement	Gravité	Message d'alerte	Action recommandée
État du service Edge inactif Note : Alarme abandonnée à partir de NSX-T Data Center 3.2.	Critique	Le service Edge est inactif pendant au moins une minute. Si le lien Afficher les détails de l'exécution est disponible, vous pouvez cliquer dessus pour afficher le motif de l'indisponibilité du service. 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é	Moyenne	État du service Edge modifié. Si le lien Afficher les détails de l'exécution est disponible, vous pouvez cliquer dessus pour afficher le motif de l'indisponibilité du service. 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 noyaux dans le répertoire /var/log/core. En outre, appelez la commande de l'interface de ligne de commande NSX get services pour confirmer si le service est arrêté. Si c'est le cas, exécutez start service <service-name> pour redémarrer le service.

État du service Edge inactif

Note : Alarme abandonnée à partir de NSX-T Data Center 3.2.

Critique

Le service Edge est inactif pendant au moins une minute.

Si le lien Afficher les détails de l'exécution est disponible, vous pouvez cliquer dessus pour afficher le motif de l'indisponibilité du service.

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é

Moyenne

État du service Edge modifié.

Si le lien Afficher les détails de l'exécution est disponible, vous pouvez cliquer dessus pour afficher le motif de l'indisponibilité du service.

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 noyaux dans le répertoire /var/log/core.
En outre, appelez la commande de l'interface de ligne de commande NSX get services pour confirmer si le service est arrêté.
Si c'est le cas, exécutez start service <service-name> pour redémarrer le service.

É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

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 : Dans l'interface utilisateur de NSX, accédez à Mise en réseau > Pools d'adresses IP > Pools d'adresses IP. 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. 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. Dans l'interface utilisateur de NSX, accédez à Mise en réseau > Pools d'adresses IP > Pools d'adresses IP. Sélectionnez des pools IP et cochez la colonne Adresses IP allouées pour afficher les adresses IP allouées à partir du pool 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>`

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

Dans l'interface utilisateur de NSX, accédez à Mise en réseau > Pools d'adresses IP > Pools d'adresses IP.
Sélectionnez des pools IP et cochez la colonne Adresses IP allouées pour afficher les adresses IP allouées à partir du pool 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 : Dans l'interface utilisateur de NSX, accédez à Système > Licences. Cliquez sur Ajouter et spécifiez la clé de la nouvelle licence. Supprimez la licence expirée en cochant la case et en cliquant sur Annuler l'attribution.
La licence est sur le point d'expirer	Moyenne	Une licence est sur le point d'expirer. 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 : Dans l'interface utilisateur de NSX, accédez à Système > Licences. Cliquez sur Ajouter et spécifiez la clé de la nouvelle licence. Supprimez la licence expirée en cochant la case et en cliquant sur Annuler l'attribution.

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 :

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

La licence est sur le point d'expirer

Moyenne

Une licence est sur le point d'expirer. 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 :

Dans l'interface utilisateur de NSX, accédez à Système > Licences.
Cliquez sur Ajouter et spécifiez la clé de la nouvelle licence.
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 par l'équilibrage de charge est supérieure au seuil d'utilisation du système, la charge de travail est trop élevée pour cet équilibrage 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	Le service d'équilibreur de charge centralisé est inactif. 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. »	Sur le nœud Edge actif, vérifiez l'état de l'équilibreur de charge en appelant la commande de l'interface de ligne de commande NSX suivante. get load-balancer <lb-uuid> status 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	Le pool d'équilibreurs de charge est inactif. 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. »	Consultez le pool d'équilibreur de charge pour déterminer quels membres sont inactifs. Vérifiez la connectivité réseau entre l'équilibreur de charge et les membres du pool concernés. Validez la santé de l'application de chaque membre du pool. 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 de la configuration « Nombre de reconnexions » dans le moniteur.
État de l'équilibrage de charge dégradé	Moyenne	À partir de NSX-T Data Center 3.1.2. Le service d'équilibreur de charge est dégradé. 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é : Sur le nœud Edge en veille, vérifiez l'état de l'équilibreur de charge en appelant la commande de l'interface de ligne de commande NSX suivante. get load-balancer <lb-uuid> status 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é : Obtenez un état détaillé en appelant la NSX API suivante. `GET /policy/api/v1/infra/lb-services/<LBService>/detailed-status?source=realtime` 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. 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. Le service d'équilibreur de charge distribué est inactif. 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. »	Sur le nœud hôte ESXi, appelez la commande CLI NSX suivante. get load-balancer <lb-uuid> status 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	Moyenne	À partir de NSX-T Data Center 3.1.2. L'utilisation de l'équilibreur de charge est élevée 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}` %. »	Si plusieurs instances d'équilibrage de charge ont été configurées dans ce nœud Edge, déployez un nouveau nœud Edge et déplacez certaines instances d'équilibrage de charge vers ce nouveau nœud Edge. Si une seule instance d'équilibrage de charge (petite/moyenne/etc.) a été configurée dans un nœud Edge de même taille (petit/moyen/etc), déployez un nouveau dispositif Edge de plus grande taille et déplacez l'instance d'équilibrage de charge vers ce nouveau nœud Edge.
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. L'utilisation du membre du pool d'équilibreur de charge est très élevée. 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é.
Configuration de l'équilibrage de charge non réalisée en raison d'un manque de mémoire	Moyenne	La configuration de l'équilibrage de charge n'est pas réalisée en raison d'une utilisation élevée de la mémoire sur le nœud Edge. Lorsque l'événement est détecté : « La configuration de l'équilibreur de charge `{entity_id}` n'est pas réalisée, en raison d'une utilisation élevée de la mémoire sur le nœud Edge `{transport_node_id}`. » Lorsque l'événement est résolu : « La configuration de l'équilibrage de charge `{entity_id}` est réalisée sur `{transport_node_id}`. »	Préférez définir des équilibreurs de charge de petite et moyenne taille sur des équilibreurs de charge de grande taille. Répartissez les services d'équilibreur de charge entre les nœuds Edge disponibles. Réduisez le nombre de serveurs virtuels définis.

É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 périphérique utilisant l'adresse IP attribuée au nœud de gestionnaire `{entity_id}` semble ne plus utiliser `{duplicate_ip_address}`. »	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. Vérifiez que le pool d'adresses IP statiques/serveur DHCP est correctement configuré. 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 Manager	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/configuration du 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 é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 élevée de `{system_usage_threshold}` %. »	Exécutez l'outil suivant et contactez GSS si des problèmes sont signalés /opt/vmware/tools/support/inspect_checkpoint_issues.py
Utilisation élevée du disque de configuration de Manager	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 de non-configuration du nœud de gestionnaire est élevée. Lorsque l'événement est détecté : « L'utilisation du disque pour la partition/non-config du 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. » Lorsque l'événement est résolu : « L'utilisation du disque pour la partition/non-config du disque 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}` %. »	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 de non-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/non-config du 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 élevée du disque par le service de banque de données NSX dans le répertoire /nonconfig/corfu. » Lorsque l'événement est résolu : « L'utilisation du disque pour la partition/non-config du disque 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}` %. »	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

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 trouver les clusters présentant des problèmes, effectuez l'une des actions suivantes : Utilisez l'interface utilisateur NSX et accédez à la page Alarmes. La valeur du nom de l'entité pour cette instance d'alarme identifie le nom du cluster. Pour extraire tous les états des clusters et déterminer le nom des clusters qui signalent INACTIF ou INCONNU, appelez NSX API `GET /api/v1/systemhealth/container-cluster/ncp/status`. Ensuite, sur la page Inventaire \| Conteneur \| Clusters de l'interface utilisateur NSX, recherchez le cluster par nom et cliquez sur l'onglet Nœuds qui répertorie tous les membres du cluster Kubernetes et PAS. Pour le cluster Kubernetes : Vérifiez la réactivité de l'espace NCP en recherchant le nœud K8s principal à partir de tous les membres du cluster et connectez-vous au nœud principal. 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. Vérifiez la connexion entre NCP et le serveur d'API Kubernetes. 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 principale. 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. 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 à partir de la VM principale. 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 : Vérifiez les connexions réseau entre les machines virtuelles et corrigez les problèmes réseau. 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.

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 trouver les clusters présentant des problèmes, effectuez l'une des actions suivantes :
- Utilisez l'interface utilisateur NSX et accédez à la page Alarmes. La valeur du nom de l'entité pour cette instance d'alarme identifie le nom du cluster.
- Pour extraire tous les états des clusters et déterminer le nom des clusters qui signalent INACTIF ou INCONNU, appelez NSX API GET /api/v1/systemhealth/container-cluster/ncp/status. Ensuite, sur la page Inventaire | Conteneur | Clusters de l'interface utilisateur NSX, recherchez le cluster par nom et cliquez sur l'onglet Nœuds qui répertorie tous les membres du cluster Kubernetes et PAS.

Pour le cluster Kubernetes :
1. Vérifiez la réactivité de l'espace NCP en recherchant le nœud K8s principal à partir de tous les membres du cluster et connectez-vous au nœud principal. 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 le serveur d'API Kubernetes. 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 principale.
  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 à partir de la VM principale.
  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é

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 : Si Vmk50 est manquant, reportez-vous à l'article 67432 de la base de connaissances. Si Hyperbus 4094 est manquant : le redémarrage de NSX-journal cfgagent ou de la VM de l'hôte du conteneur peut aider. 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. Si nsx-cfgagent s'est arrêté, redémarrez nsx-cfgagent. Pour KVM : Si l'espace de noms Hyperbus est manquant, le redémarrage de `nsx-opsagent` peut aider à le recréer. Si l'interface Hyperbus est manquante dans l'espace de noms Hyperbus, le redémarrage de `nsx-opsagent` peut aider. Si `nsx-agent` s'est arrêté, redémarrez `nsx-agent`. Pour ESX et KVM : 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. 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.

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 :

Si Vmk50 est manquant, reportez-vous à l'article 67432 de la base de connaissances.
Si Hyperbus 4094 est manquant : le redémarrage de NSX-journal cfgagent ou de la VM de l'hôte du conteneur peut aider.
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.
Si nsx-cfgagent s'est arrêté, redémarrez nsx-cfgagent.

Pour KVM :

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

Pour ESX et KVM :

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.
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
Avertissement de latence entre GM et GM	Moyenne	La latence entre les gestionnaires globaux est supérieure à celle attendue pendant plus de 2 minutes. Lorsque l'événement est détecté : « La latence est supérieure à celle attendue entre les gestionnaires globaux `{from_gm_path}` et `{to_gm_path}`. » Lorsque l'événement est résolu : « La latence est inférieure aux niveaux attendus entre les gestionnaires globaux `{from_gm_path}` et `{to_gm_path}`. »	Vérifiez la connectivité du gestionnaire global `{from_gm_path}`(`{site_id}`) au gestionnaire global `{to_gm_path}`(`{remote_site_id}`) via un test ping. Si la commande ping n'est pas possible, vérifiez la fragilité de la connectivité WAN.
Erreur de synchronisation entre GM et GM	Élevé	Le gestionnaire global actif vers le gestionnaire global en veille ne peut pas se synchroniser pendant plus de 5 minutes. Lorsque l'événement est détecté : « Le gestionnaire global actif `{from_gm_path}` vers le gestionnaire global en veille `{to_gm_path}` ne peut pas se synchroniser pendant plus de 5 minutes. » Lorsque l'événement est résolu : « La synchronisation du gestionnaire global actif `{from_gm_path}` en veille `{to_gm_path}` est saine. »	Vérifiez la connectivité du gestionnaire global `{from_gm_path}`(`{site_id}`) au gestionnaire global `{to_gm_path}`(`{remote_site_id}`) via un test ping.
Avertissement de synchronisation entre GM et GM	Moyenne	Le gestionnaire global actif vers le gestionnaire global en veille ne peut pas se synchroniser. Lorsque l'événement est détecté : « Gestionnaire global actif `{from_gm_path}` vers le gestionnaire global en veille `{to_gm_path}` ne peut pas se synchroniser. » Lorsque l'événement est résolu : « La synchronisation du gestionnaire global actif `{from_gm_path}` vers le gestionnaire global en veille `{to_gm_path}` est saine. »	Vérifiez la connectivité du gestionnaire global `{from_gm_path}`(`{site_id}`) au gestionnaire global `{to_gm_path}`(`{remote_site_id}`) via un test ping.
Erreur de synchronisation LM-LM	Élevé	À partir de NSX-T Data Center 3.0.1. La synchronisation entre les emplacements distants a échoué pendant plus de 5 minutes. Lorsque l'événement est détecté : « La synchronisation entre `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id`}) a échoué pendant plus de 5 minutes. » Lorsque l'événement est résolu : « Les sites distants `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) sont désormais synchronisés. »	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 train de résoudre le nœud principal. 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. À 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. 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. Échec de la synchronisation entre les emplacements distants. Lorsque l'événement est détecté : « La synchronisation entre `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) a échoué. » Lorsque l'événement est résolu : « Emplacements distants `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) sont désormais synchronisés. »	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 train de résoudre le nœud principal. 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. À 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. 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. Le voisin RTEP BGP est inactif. Lorsque l'événement est détecté : « La session BGP RTEP (point de terminaison du tunnel distant) 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. » Lorsque l'événement est résolu : « La session BGP de RTEP (point de terminaison du tunnel distant) 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. »	Appelez la commande de l'interface de ligne de commande NSX get logical-routers sur le nœud Edge concerné. Basculez sur le contexte REMOTE_TUNNEL_VRF. Appelez la commande get bgp neighbor de l'interface de ligne de commande NSX pour vérifier le voisin BGP. Vous pouvez également appeler la commande GET /api/v1/transport-nodes/<transport-node-id>/inter-site/bgp/summary NSX API pour obtenir l'état du voisin BGP. Appelez la commande de l'interface de ligne de commande NSX get interfaces et vérifiez si l'adresse IP de RTEP adéquate est attribuée à l'interface avec le nom remote-tunnel-endpoint. . 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}`. Recherchez les erreurs liées à BGP dans /var/log/syslog. Appelez l'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é.
Avertissement de synchronisation GM-LM	Moyenne	La synchronisation des données entre le gestionnaire global (GM) et le gestionnaire local (LM) a échoué. Lorsque l'événement est détecté : « La synchronisation des données entre les sites `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) a échoué pour l'`{flow_identifier}` ». Lorsque l'événement est résolu : « Les sites `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) sont désormais synchronisés pour `{flow_identifier}`. »	Vérifiez la connectivité réseau entre le site distant et le site local via un test ping. Assurez-vous que le trafic TCP/1236 du port est autorisé entre les sites locaux et distants. Assurez-vous que le service async-replicator est en cours d'exécution sur les sites locaux et distants. Appelez l'`GET /api/v1/node/services/async_replicator/status NSX API` ou la commande de l'interface de ligne de commande get service async_replicator NSX pour déterminer si le service est en cours d'exécution. Si le service n'est pas en cours d'exécution, appelez l'API `POST /api/v1/node/services/async_replicator?action=restart` NSX ou l'interface de ligne de commande restart service async_replicator NSX pour redémarrer le service. Vérifiez si des erreurs sont signalées dans le fichier /var/log/syslog.
Erreur de synchronisation GM-LM	Élevé	La synchronisation des données entre le gestionnaire global (GM) et le gestionnaire local (LM) a échoué pendant une période prolongée. Lorsque l'événement est détecté : « La synchronisation des données entre les sites `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) a échoué pour l'`{flow_identifier}` pendant une période prolongée. » Lorsque l'événement est résolu : « Les sites `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) sont désormais synchronisés pour `{flow_identifier}`. »	Vérifiez la connectivité réseau entre le site distant et le site local via un test ping. Assurez-vous que le trafic TCP/1236 du port est autorisé entre les sites locaux et distants. Assurez-vous que le service async-replicator est en cours d'exécution sur les sites locaux et distants. Appelez l'API `GET /api/v1/node/services/async_replicator/status` NSX ou la commande de l'interface de ligne de commande get service async_replicator NSX pour déterminer si le service est en cours d'exécution. Si le service n'est pas en cours d'exécution, appelez l'API `POST /api/v1/node/services/async_replicator?action=restart` NSX ou l'interface de ligne de commande restart service async_replicator NSX pour redémarrer le service. Vérifiez si des erreurs sont signalées dans le fichier /var/log/syslog. Collectez un bundle de support et contactez le support VMware.
Seuil d'occupation de la file d'attente dépassé	Moyenne	Le seuil de taille de l'occupation de la file d'attente a dépassé l'avertissement. Lorsque l'événement est détecté : « La file d'attente (`{queue_name}`) utilisée pour synchroniser les données entre les sites `{site_name}`(`{site_id}`) et `{remote_site_name}` ({remote_site_id}`) a atteint la taille` {queue_size}, qui est supérieure ou égale au seuil maximal de `{queue_size_threshold}` %. » Lorsque l'événement est résolu : « La file d'attente (`{queue_name}`) utilisée pour synchroniser les données entre les sites `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) a atteint la taille `{queue_size}`, qui est inférieure au seuil maximal de `{queue_size_threshold}` %. »	La taille de la file d'attente peut dépasser le seuil en raison d'un problème de communication avec le site distant ou un système surchargé. Vérifiez les performances du système et le fichier /var/log/async-replicator/ar.log pour voir si des erreurs sont signalées.
Avertissement de latence GM-LM	Moyenne	La latence entre le gestionnaire global et le gestionnaire local est supérieure à celle attendue pendant plus de 2 minutes. Lorsque l'événement est détecté : « la latence entre les sites `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) a atteint `{latency_value}`, ce qui est supérieur à la valeur de seuil de `{latency_threshold}`. » Lorsque l'événement est résolu : « Latence entre les sites `{site_name}`(`{site_id}`) et `{remote_site_name}`(`{remote_site_id}`) a atteint `{latency_value}` qui est inférieure à la valeur de seuil de `{latency_threshold}`. »	Vérifiez la connectivité réseau entre le site distant et le site local via un test ping. Assurez-vous que le trafic TCP/1236 du port est autorisé entre les sites locaux et distants. Vérifiez si des erreurs sont signalées dans le fichier /var/log/syslog.
Cluster dégradé	Moyenne	Le membre du groupe est inactif. Lorsque l'événement est détecté : « Le membre du groupe `{manager_node_id}` du service `{group_type}` est inactif. » Lorsque l'événement est résolu : « Le membre du groupe `{manager_node_id}` de `{group_type}` est actif. »	Appelez la commande get cluster status de l'interface de ligne de commande NSX pour afficher l'état des membres du groupe du cluster. Assurez-vous que le service pour `{group_type}` est en cours d'exécution sur le nœud. Appelez l'API `GET /api/v1/node/services/<service_name>/status` NSX ou la commande de l'interface de ligne de commande get service <service_name> NSX pour déterminer si le service est en cours d'exécution. Si le service n'est pas en cours d'exécution, appelez l'API `POST /api/v1/node/services/<service_name>?action=restart` NSX ou l'interface de ligne de commande restart service <service_name> NSX pour redémarrer le service. Vérifiez si des erreurs sont signalées dans le fichier /var/log/ du service `{group_type}`.
Cluster non disponible	Élevé	Tous les membres du groupe du service sont inactifs. Lorsque l'événement est détecté : « Tous les membres du groupe `{manager_node_ids}` du service `{group_type}` sont inactifs. » Lorsque l'événement est résolu : « Tous les membres du groupe `{manager_node_ids}` du service `{group_type}` sont actifs. »	Assurez-vous que le service pour `{group_type}` est en cours d'exécution sur le nœud. Appelez l'API `GET /api/v1/node/services/<service_name>/status` NSX ou la commande de l'interface de ligne de commande get service <service_name> NSX pour déterminer si le service est en cours d'exécution. S'il n'est pas en cours d'exécution, appelez l'API `POST /api/v1/node/services/<service_name>?action=restart` NSX ou l'interface de ligne de commande restart service <service_name> NSX pour redémarrer le service. Vérifiez si des erreurs sont signalées dans le fichier /var/log/ du service `{group_type}`.

É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

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>` où `<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>` où `<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>` où `<userid>` est l'ID de l'utilisateur.

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>

où <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>

où <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>

où <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. »	Connectez-vous via SSH au nœud Edge. Appelez la commande d'interface de ligne de commande NSX : `get logical-routers` Basculez vers le routeur de service `{sr_id}`. Vérifiez /var/log/syslog pour voir s'il existe des erreurs liées à la connectivité de BGP.
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. »	Appelez la commande get logical-routers de l'interface de ligne de commande NSX. Basculez vers le routeur de service `{sr_id}`. Appelez la commande ping {peer_address} de l'interface de ligne de commande NSX pour vérifier la connectivité.
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 ».	Appelez la commande `get logical-routers` de l'interface de ligne de commande NSX pour obtenir le routeur de service de niveau 0. 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é. »	Connectez-vous via SSH au nœud Edge. Appelez la commande d'interface de ligne de commande NSX : `get logical-routers` Basculez vers le routeur de service `{sr_id}`. Vérifiez la connectivité en appelant la commande d'interface de ligne de commande NSX : get bgp neighbor summary Vérifiez également la configuration dans NSX et l'homologue BFD pour vous assurer que les temporisateurs n'ont pas été modifiés.
Incohérence de MTU dans la zone de transport	Élevé	Incompatibilité de configuration de MTU entre les nœuds de transport (ESXi, KVM et Edge) attachés à la même zone de transport. Les valeurs MTU sur tous les commutateurs attachés à la même zone de transport qui ne sont pas cohérentes entraînent des problèmes de connectivité.	Dans l'interface utilisateur de NSX, accédez à Système > Infrastructure > Paramètres et cliquez sur Incohérent dans Vérification de la configuration MTU pour afficher plus de détails sur les discordances. Définissez la même valeur MTU sur tous les commutateurs attachés à la même zone de transport en appelant NSX API, `PUT /api/v1/host-switch-profiles/<host-switch-profile-id>` avec mtu dans le corps de la demande, ou l'API, `PUT /api/v1/global-configs/SwitchingGlobalConfig` avec physical_uplink_mtu dans le corps de la demande.
MTU du routeur global trop volumineux	Moyenne	La configuration du MTU du routeur global est supérieure au MTU des commutateurs dans la zone de transport de superposition qui se connecte au niveau 0 ou au niveau 1. La valeur MTU du routeur global doit être inférieure à la valeur MTU de tous les commutateurs d'au moins 100, car nous avons besoin d'un quota de 100 pour l'encapsulation Geneve.	Dans l'interface utilisateur de NSX, accédez à Système > Infrastructure > Paramètres et cliquez sur Incohérent dans Vérification de la configuration MTU pour afficher plus de détails sur les discordances. Définissez la valeur de MTU la plus élevée sur les commutateurs en appelant NSX API, `PUT /api/v1/host-switch-profiles/<host-switch-profile-id>` avec mtu dans le corps de la demande, ou l'API, `PUT /api/v1/global-configs/SwitchingGlobalConfig` avec physical_uplink_mtu dans le corps de la demande. Vous pouvez également définir la valeur de MTU la plus petite de la configuration du routeur global en appelant NSX API, `PUT /api/v1/global-configs/RoutingGlobalConfig` avec logical_uplink_mtu dans le corps de la demande.

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. Dans l'interface utilisateur de NSX, accédez à Infrastructure > Nœuds > Nœuds de transport > Nœuds de transport hôtes. 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. Sélectionnez <transport node> > Surveiller. Recherchez la liaison (liaison montante) signalée comme dégradée ou inactive. 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 de nœud de transport 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. Dans l'interface utilisateur de NSX, accédez à Infrastructure > Nœuds > Nœuds de transport > Nœuds de transport hôtes. 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. 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.

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.

Dans l'interface utilisateur de NSX, accédez à Infrastructure > Nœuds > Nœuds de transport > Nœuds de transport hôtes.
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.
Sélectionnez <transport node> > Surveiller.
Recherchez la liaison (liaison montante) signalée comme dégradée ou inactive.
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 de nœud de transport 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.

Dans l'interface utilisateur de NSX, accédez à Infrastructure > Nœuds > Nœuds de transport > Nœuds de transport hôtes.
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.
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.
Service IPsec inactif	Moyenne	Le service IPsec est inactif. Pour afficher le motif pour lequel le service est inactif, cliquez sur le lien Afficher les détails de l'exécution. Lorsque l'événement est détecté : « Le service IPSec `{entity_id}` est inactif. » Lorsque l'événement est résolu : « Le service IPSec `{entity_id}` est actif. »	Désactivez et activez le service IPsec à partir de l'interface utilisateur NSX Manager. Si le problème persiste, contactez le support VMware.