Les composants NSX-T Data Center écrivent dans des fichiers journaux dans le répertoire /var/log. Sur les dispositifs NSX-T et les hôtes KVM, les messages Syslog NSX sont conformes à RFC 5424. Sur les hôtes ESXi, les messages Syslog sont conformes à RFC 3164.

Affichage des journaux

Sur les dispositifs NSX-T, les messages Syslog se trouvent dans /var/log/syslog. Sur les hôtes KVM, les messages Syslog se trouvent dans /var/log/vmware/nsx-syslog.

Sur les dispositifs NSX-T, vous pouvez exécuter la commande CLI NSX-T suivante pour afficher les journaux : 
get log-file <auth.log | controller | controller-error | http.log | kern.log | manager.log | node-mgmt.log | policy.log | syslog> [follow]
Les fichiers journaux sont les suivants :
Nom Description
auth.log Journal des autorisations
controller Journal du contrôleur
controller-error Journal des erreurs du contrôleur
http.log Journal des services HTTP
kern.log Journal du noyau
manager.log Journal de Manager Service
node-mgmt.log Journal de gestion des nœuds
nsx-audit-write.log Journal d'écriture d'audit NSX
nsx-audit.log Journal d'audit NSX
policy.log Journal du service de stratégie
syslog Journal système

Sur les hyperviseurs, vous pouvez utiliser des commandes Linux telles que tac, tail, grep et more pour afficher les journaux.

Chaque message Syslog comporte des informations sur le composant (comp) et le sous-composant (subcomp) pour faciliter l'identification de la source du message.

NSX-T Data Center émet des journaux avec l'installation local6, qui a une valeur numérique de 22.

Le journal d'audit fait partie de Syslog. Un message de journal d'audit peut être identifié par la chaîne audit="true" dans le champ structured-data. Vous pouvez configurer un serveur de journalisation externe pour qu'il reçoive des messages de journal. Vous pouvez également accéder aux journaux d'audit à l'aide de l'API /api/v1/administration/audit-logs. Le fichier nsx-audit.log contient des messages Syslog avec audit="true" dans le champ structured-data. Le fichier nsx-audit-write.log contient des messages Syslog avec audit="true" et update="true" dans le champ structured-data.

Chaque message de journal Syslog et d'audit contient un horodatage généré par un serveur NTP s'il est configuré, ou par l'horloge système. Exemple de message de journal d'audit : 
<182>1 2020-05-05T00:29:02.900Z nsx-manager1 NSX 14389 - [nsx@6876 audit="true" comp="nsx-manager" level="INFO" reqId="fe75651d-c3e7-4680-8753-9ae9d92d7f0c" subcomp="policy" username="admin"] UserName="admin", ModuleName="AAA", Operation="GetCurrentUserInfo", Operation status="success"
Un appel d'API peut provenir de NSX Manager, d'un client d'API de stratégie ou d'un nœud NSX. Tous les appels d'API sont soumis à authentification et à autorisation, et génèrent des journaux d'audit. Cette journalisation est activée par défaut et ne peut pas être désactivée. Un journal d'audit qui est associé à un appel d'API comporte les informations suivantes :
  • Un paramètre d'identifiant d'entité entId pour identifier l'objet de l'API.
  • Un paramètre d'identifiant de demande req-id pour identifier un appel d'API spécifique.
  • Un paramètre d'identifiant de demande externe ereqId si l'appel d'API contient l'en-tête X-NSX-EREQID:<string>.
  • Un paramètre d'utilisateur externe euser si l'appel d'API contient l'en-tête X-NSX-EUSER:<string>.
Un message de journal d'audit d'un appel d'API de gestionnaire ou de stratégie aura les champs supplémentaires suivants. Notez que les journaux d'audit de l'API de nœud (NAPI) et de la CLI ne comportent pas ces champs.
  • Un indicateur update qui indique si l'opération de l'API est une opération de lecture (GET) ou d'écriture (PUT/POST/DELETE/...).
  • Champ operation name qui affiche le nom de l'opération de l'API.
  • Champ operation status qui indique si l'opération de l'API a réussi ou échoué.
  • Champ new value qui affiche toutes les valeurs de paramètre de la demande d'API.

NSX-T n'a pas le concept d'un mode privilégié. Les appels d'API de toutes les sources et tous les utilisateurs sont contrôlés.

Exemple de messages Syslog de connexion et de déconnexion indiquant la réussite de l'ouverture de session, l'échec de la connexion et la connexion à partir de 2 périphériques différents (notez les différentes adresses IP) : 
2020-07-07T16:33:20.339Z svc.nsxmanager NSX 1513 SYSTEM [nsx@6876 audit="true" comp="nsx-manager" level="INFO" subcomp="http"] UserName="[email protected]", ModuleName="ACCESS_CONTROL", Operation="LOGIN", Operation status="success"

2020-07-07T16:33:58.779Z svc.nsxmanager NSX 1513 SYSTEM [nsx@6876 audit="true" comp="nsx-manager" level="INFO" subcomp="http"] UserName="admin", ModuleName="ACCESS_CONTROL", Operation="LOGOUT", Operation status="success"

2020-07-07T16:50:21.301Z svc.nsxmanager NSX 1513 SYSTEM [nsx@6876 audit="true" comp="nsx-manager" level="INFO" subcomp="http"] UserName="[email protected]", ModuleName="ACCESS_CONTROL", Operation="LOGIN", Operation status="success"

2020-07-07T16:43:20.339Z svc.nsxmanager NSX 1513 SYSTEM [nsx@6876 audit="true" comp="nsx-manager" level="INFO" subcomp="http"] UserName="[email protected]", ModuleName="ACCESS_CONTROL", Operation="LOGIN", Operation status="failure"
Exemple de message Syslog d'un appel d'API de stratégie : 
<182>1 2020-07-06T18:09:14.210Z svc.nsxmanager NSX 2326 FABRIC [nsx@6876 audit="true" comp="nsx-manager" entId="68d5a9d0-4691-4c9c-94ed-64fd1c96150f" level="INFO" reqId="4c2335aa-c973-4f74-983f-331a4f7041ca" subcomp="manager" update="true" username="admin"] UserName="admin", ModuleName="TransportZone", Operation="CreateTransportZone", Operation status="success", New value=[{"transport_type":"OVERLAY","host_switch_name":"nsxvswitch","host_switch_mode":"STANDARD","nested_nsx":false,"is_default":false,"display_name":"1-transportzone-1307","_protection":"UNKNOWN"}]
Exemple de messages Syslog d'accès à la CLI : 
2020-07-07T16:36:41.783Z svc.nsxmanager NSX 21018 - [nsx@6876 comp="nsx-manager" subcomp="cli" username="admin" level="INFO"] NSX CLI started (Manager, Policy, Controller) for user: admin
2020-07-07T16:36:53.469Z svc.nsxmanager NSX 21018 - [nsx@6876 comp="nsx-manager" subcomp="cli" username="admin" level="INFO"] NSX CLI stopped for user: admin
Exemple de message Syslog lorsqu'un utilisateur exécute une commande de CLI (dans cet exemple, set user admin password-expiration 100) : 
<182>1 2020-07-22T20:51:49.017Z manager2 NSX 1864 - [nsx@6876 comp="nsx-manager" subcomp="cli" username="admin" level="INFO" audit="true"] CMD: set user admin password-expiration 100 (duration: 2.185s), Operation status: CMD_EXECUTED
Exemple de message Syslog d'un appel NAPI : 
<182>1 2020-07-21T21:01:38.803Z manager2 NSX 4690 - [nsx@6876 comp="nsx-manager" subcomp="node-mgmt" username="admin" level="INFO" audit="true"] admin 'GET /api/v1/node/services/syslog/exporters' 200 731 "" "PostmanRuntime/7.26.1" 0.004588
Exemple de message Syslog d'une commande de CLI : 
<182>1 2020-07-21T20:54:40.018Z manager2 NSX 16915 - [nsx@6876 comp="nsx-manager" subcomp="cli" username="admin" level="INFO" audit="true"] CMD: set logging-server 1.1.1.1 proto udp level info (duration: 4.356s), Operation status: CMD_EXECUTED

RFC 5424 et RFC 3164 définissent les niveaux de gravité suivants :

Niveau de gravité Description
0 Urgence : le système est inutilisable
1 Alerte : une mesure doit être prise immédiatement
2 Critique : conditions critiques
3 Erreur : conditions d'erreur
4 Avertissement : conditions d'avertissement
5 Avis : condition normale mais significative
6 Informatif : messages informatifs
7 Débogage : messages de niveau de débogage

Tous les journaux avec la gravité urgence, alerte, critique ou erreur contiennent un code d'erreur unique dans la partie de données structurée du message de journal. Le code d'erreur se compose d'une chaîne et d'un nombre décimal. La chaîne représente un module spécifique.

Formats de message de journal

Pour plus d'informations sur la norme RFC 5424, reportez-vous à https://tools.ietf.org/html/rfc5424. Pour plus d'informations sur la norme RFC 3164, reportez-vous à https://tools.ietf.org/html/rfc3164.

La norme RFC 5424 définit le format suivant pour les messages de journal : 

<facility * 8 + severity> version UTC-TZ hostname APP-NAME procid MSGID [structured-data] msg
Exemple de message de journal : 
<187>1 2016-03-15T22:53:00.114Z nsx-manager NSX - SYSTEM [nsx@6876 comp="nsx-manager" errorCode="MP4039" subcomp="manager"] Connection verification failed for broker '10.160.108.196'. Marking broker unhealthy.

Codes d'erreur

Pour obtenir une liste de codes d'erreur, reportez-vous à l'article 71077 de la base de connaissances Codes d'erreur de NSX-T Data Center 2.x.