Los componentes de NSX-T Data Center escriben en los archivos de registro en el directorio /var/log. En los dispositivos de NSX-T y los hosts de KVM, los mensajes de syslog de NSX cumplen con RFC 5424. En hosts ESXi, los mensajes de syslog se ajustan a RFC 3164.

Ver registros

En NSX-T, los mensajes de syslog de dispositivos se encuentran en /var/log/syslog. En los hosts de KVM, los mensajes de syslog se encuentran en /var/log/vmware/nsx-syslog.

En los dispositivos de NSX-T, puede ejecutar el siguiente comando de la CLI de NSX-T para ver los registros:
get log-file <auth.log | controller | controller-error | http.log | kern.log | manager.log | node-mgmt.log | syslog> [follow]
Los archivos de registro son:
Nombre Descripción
auth.log Registro de autorización
controlador Registro del controlador
controller-error Registro de errores de controlador
http.log Registro del servicio HTTP
kern.log Registro del kernel
manager.log Registro del servicio de Manager
node-mgmt.log Registro de administración de nodos
nsx-audit-write.log Registro de escritura de auditoría de NSX
nsx-audit.log Registro de auditoría de NSX
syslog Registro del sistema

En los hipervisores, puede utilizar comandos de Linux como tac, tail, grep y more para ver los registros.

Cada mensaje contiene información de componentes (comp) y subcomponentes (subcomp) para ayudar a identificar el origen del mensaje.

NSX-T Data Center genera registros con el recurso local6, que tiene un valor numérico de 22.

El registro de auditoría forma parte de syslog. Los mensajes de registro de auditoría pueden identificarse mediante la cadena audit="true" en el campo structured-data. Puede configurar un servidor de registros externo para recibir mensajes de registro. También puede acceder a los registros de auditoría mediante la API /api/v1/administration/audit-logs. El archivo nsx-audit.log contiene mensajes de syslog con audit="true" en el campo structured-data. El archivo nsx-audit-write.log contiene mensajes de syslog con audit="true" y update="true" en el campo structured-data.

Cada mensaje de syslog y del registro de auditoría contiene una marca de tiempo generada por un servidor NTP, si está configurado, o el reloj del sistema. A continuación se muestra un ejemplo de un mensaje de registro de auditoría:
<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"
Una llamada de API puede provenir de NSX Manager, un cliente de API de directiva o un nodo de NSX. Todas las llamadas API están sujetas a autenticación y autorización, y generarán registros de auditoría. Este registro está habilitado de forma predeterminada y no se puede deshabilitar. Un registro de auditoría asociado con una llamada de API contiene la siguiente información:
  • Un parámetro de ID de entidad entId para identificar el objeto de la API.
  • Un parámetro de ID de solicitud req-id para identificar una llamada de API concreta.
  • Un parámetro de ID de solicitud externa ereqId si la llamada de API contiene el encabezado X-NSX-EREQID:<string>.
  • Un parámetro de usuario externo euser si la llamada de API contiene el encabezado X-NSX-EUSER:<string>.
Un mensaje de registro de auditoría de una llamada de API de Directiva o Manager tendrá los siguientes campos adicionales. Tenga en cuenta que los registros de auditoría de la API de nodos (NAPI) y la CLI no tendrán estos campos.
  • Una marca de update que muestra si la operación de la API es una operación de lectura (GET) o de escritura (PUT/POST/DELETE/...).
  • Un campo operation name que muestra el nombre de la operación de API.
  • Un campo operation status que muestra si la operación de API se realizó correctamente.
  • Un campo new value que muestra todos los valores de los parámetros de la solicitud de API.

NSX-T no tiene el concepto de un modo privilegiado. Se auditan las llamadas de API de todos los orígenes y usuarios.

A continuación se muestra un ejemplo de mensaje de syslog de inicio y cierre de sesión donde se muestra un inicio de sesión correcto, un error de inicio de sesión y los inicios de sesión de dos dispositivos diferentes (tenga en cuenta las diferentes direcciones 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"
Ejemplo de un mensaje de syslog de una llamada de API de directiva:
<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"}]
Ejemplo de un mensajes de syslog de acceso de 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
Ejemplo de un mensaje de syslog cuando un usuario ejecuta un comando de la CLI (en este ejemplo, 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
Ejemplo de un mensaje de syslog de una llamada de 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
Ejemplo de un mensaje de syslog de un comando de la 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 y RFC 3164 definen los siguientes niveles de gravedad:

Nivel de gravedad Descripción
0 Emergencia: el sistema no se puede utilizar
1 Alerta: se debe realizar una acción inmediatamente
2 Gravedad: condiciones graves
3 Error: condiciones de error
4 Advertencia: condiciones de advertencia
5 Notificación: indica una condición normal, pero importante
6 Informativo: mensajes informativos
7 Depuración: mensajes de nivel de depuración

Todos los registros con un nivel de gravedad de emergencia, alerta, gravedad o error contienen un código de error único en la parte de datos estructurados del mensaje de registro. El código de error está compuesto por una cadena y un número decimal. La cadena representa un módulo específico.

Error al acceder a un archivo de registro o a un servidor de registro remoto

Si NSX-T no puede acceder ni escribir mensajes en un archivo de registro, se generará una alarma. Los posibles errores son:

  • Falta un archivo de registro local.
  • La configuración de la propiedad o el permiso de un archivo de registro local impide que NSX-T escriba en el archivo.
  • NSX-T no puede enviar mensajes de registro a un servidor de registro remoto de terceros. Tenga en cuenta que no se activará una alarma si NSX-T no puede enviar registros al agente de Log Insight.

La alarma se puede resolver a través del marco de la alarma.

Formatos de mensajes de registro

Para obtener más información sobre RFC 5424, consulte https://tools.ietf.org/html/rfc5424. Para obtener más información sobre RFC 3164, consulte https://tools.ietf.org/html/rfc3164.

RFC 5424 define el siguiente formato para los mensajes de registro:

<facility * 8 + severity> version UTC-TZ hostname APP-NAME procid MSGID [structured-data] msg
Un mensaje de registro de ejemplo:
<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.

Códigos de error

Para obtener una lista de los códigos de error, consulte el artículo 71077 de la base de conocimientos Códigos de error de NSX-T Data Center 2.x.