Les composants NSX écrivent dans des fichiers journaux dans le répertoire /var/log. Sur les dispositifs NSX, les messages Syslog de NSX sont conformes à RFC 5424. Sur les hôtes ESXi, les messages Syslog sont conformes à RFC 3164.
Affichage des journaux
Sur les dispositifs NSX, les messages Syslog se trouvent dans /var/log/syslog.
get log-file <auth.log | controller | controller-error | http.log | kern.log | manager.log | node-mgmt.log | policy.log | syslog> [follow]
| 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 é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 journaux externe pour recevoir des messages de journaux. 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.
<182>1 2020-05-05T00:29:02.900Z nsx-manager1 NSX 147324 - [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"
2023-01-25T21:58:42.173Z w4-mydevice-220.eng.vmware.com NSX 1463241016 - [nsx@6876 comp="nsx-controller" level="INFO" subcomp="corfu-cluster"] Received maintenance mode status: {da3a0242-bf6d-ee98-224c-b9799cb5e29f=MAINTENANCE_MODE_OFF}
- 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 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 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.
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"
<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"}]
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
<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
<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
<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.
Échec de l'accès à un fichier journal ou à un serveur de journalisation distant
Si NSX ne parvient pas à accéder aux messages ou à les écrire dans un fichier journal, une alarme est générée. Les erreurs possibles sont :
- Un fichier journal local est manquant.
- Le paramètre d'autorisation ou de propriété d'un fichier journal local empêche NSX d'écrire dans le fichier.
- NSX ne peut pas envoyer de messages de journal à un serveur de journalisation distant tiers. Notez qu'aucune alarme n'est déclenchée si NSX ne parvient pas à envoyer des journaux à l'agent Aria Operations for Logs.
L'alarme peut être résolue à l'aide de la structure d'alarme.
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
<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.
