NSX-Komponenten schreiben in Protokolldateien des Verzeichnisses /var/log. Auf NSX-Anwendungen sind die NSX-Syslog-Meldungen mit RFC 5424 konform. Auf ESXi-Hosts sind die Syslog-Meldungen mit RFC 3164 konform.

Anzeigen von Protokollen

Auf NSX-Appliances befinden sich die Syslog-Meldungen im Verzeichnis /var/log/syslog.

Auf NSX-Appliances können Sie den folgenden NSX-CLI-Befehl zum Anzeigen der Protokolle ausführen: 
get log-file <auth.log | controller | controller-error | http.log | kern.log | manager.log | node-mgmt.log | policy.log | syslog> [follow]
Die Protokolldateien lauten:
Name Beschreibung
auth.log Autorisierungsprotokoll
controller Controller-Protokoll
controller-error Controller-Fehlerprotokoll
http.log HTTP-Dienstprotokoll
kern.log Kernel-Protokoll
manager.log Manager-Dienstprotokoll
node-mgmt.log Knotenverwaltungsprotokoll
nsx-audit-write.log Beschreibbares NSX-Überwachungsprotokoll
nsx-audit.log NSX-Überwachungsprotokoll
policy.log Richtliniendienstprotokoll
syslog Systemprotokoll

Auf Hypervisoren können Sie Linux-Befehle wie z. B. tac, tail, grep oder more verwenden, um die Protokolle anzuzeigen.

Jede Syslog-Meldung enthält Komponentendetails (comp) und Unterkomponentendetails (subcomp), die es erleichtern, die Quelle der Meldung zu identifizieren.

NSX erzeugt Protokolle mit Facility local6 mit einem numerischen Wert von 22.

Das Überwachungsprotokoll ist Teil eines Syslog. Eine Überwachungsprotokollmeldung kann durch die Zeichenfolge audit="true" im Feld structured-data identifiziert werden. Sie können einen externen Protokollserver für den Empfang von Protokollmeldungen konfigurieren. Sie können auch mithilfe der /api/v1/administration/audit-logs-API auf Überwachungsprotokolle zugreifen. Die Datei nsx-audit.log enthält Syslog-Meldungen mit audit="true" im Feld structured-data. Die Datei nsx-audit-write.log enthält Syslog-Meldungen mit sowohl audit="true" als auch update="true" im Feld structured-data.

Jede Syslog- und Überwachungsprotokollmeldung enthält eine von einem NTP-Server (bei entsprechender Konfiguration) oder durch die Systemuhr erstellten Zeitstempel. Ein Beispiel für eine Überwachungsprotokollmeldung: 
<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"
Beispiel für eine Syslog-Meldung: 
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}
Ein API-Aufruf kann von NSX Manager, einem Policy API Client oder einem NSX-Knoten stammen. Alle API-Aufrufe unterliegen der Authentifizierung und Autorisierung und generieren Überwachungsprotokolle. Diese Protokollierung ist standardmäßig aktiviert und kann nicht deaktiviert werden. Ein Eintrag im Überwachungsprotokoll, der einem API-Aufruf zugeordnet ist, enthält die folgende Informationen:
  • Den Parameter entId mit einer Element-ID zur Identifizierung des Objekts der-API.
  • Den Parameter req-id mit einer Anforderungs-ID zur Identifizierung eines bestimmten API-Aufrufs.
  • Den Parameter ereqId mit einer ID, die auf eine externe Anforderung verweist, wenn der API-Aufruf den Header X-NSX-EREQID:<string> enthält.
  • Den Parameter euser der auf einen externen Benutzer verweist, wenn der API-Aufruf den Header X-NSX-EUSER:<string> enthält.
Eine Überwachungsprotokollmeldung von einer Richtlinie oder einem Manager-API-Aufruf verfügt über die folgenden zusätzlichen Felder. Beachten Sie, dass die Überwachungsprotokolle für Knoten-API (Node-API, N-API) und CLI nicht über diese Felder verfügen.
  • Ein update Flag, das anzeigt, ob es sich bei dem AIP-Vorgang um einen Lesevorgang (GET) oder Schreibvorgang (PUT/POST/DELETE/...) handelt.
  • Ein Feld operation name, das den Status des API-Vorgangs zeigt.
  • Ein Feld operation status, das zeigt, ob der API-Vorgang erfolgreich war oder fehlgeschlagen ist.
  • Ein Feld new value, das alle Parameterwerte der API-Anfrage anzeigt.

NSX weist nicht das Konzept eines privilegierten Modus auf. Für API-Aufrufe von allen Quellen und Benutzern erfolgt eine Überwachung.

Ein Beispiel für das Syslog-Nachrichten zu An- und Abmeldungen, die erfolgreiche und fehlgeschlagene Anmeldungen sowie Anmeldungen von 2 verschiedenen Geräten (Achtung: verschiedene IP-Adressen) anzeigt: 
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"
Ein Beispiel für eine Syslog-Meldung zu einem Richtlinien-API-Aufruf: 
<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"}]
Ein Beispiel für Syslog-Meldungen zu einem CLI-Zugriff: 
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
Ein Beispiel für eine Syslog-Meldung, wenn ein Benutzer einen CLI-Befehl ausführt (in diesem Beispiel 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
Ein Beispiel für eine Syslog-Meldung zu einem N-API-Aufruf: 
<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
Ein Beispiel für eine Syslog-Meldung zu einem CLI-Befehl: 
<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 und RFC 3164 definieren die folgenden Schweregrade:

Schweregrad Beschreibung
0 Notfall: Das System steht nicht zur Verfügung
1 Ernste Warnung: Es muss sofort reagiert werden
2 Kritisch: Kritische Bedingungen
3 Fehler: Fehlerbedingungen
4 Warnung: Warnbedingungen
5 Hinweis: Normale, aber signifikante Bedingung
6 Information: Informationsmeldungen
7 Debug: Meldungen auf Debug-Ebene

Alle Protokolle mit dem Schweregrad „Notfall“, „Ernste Warnung“, „Kritisch“ und „Fehler“ enthalten einen eindeutigen Fehlercode im Abschnitt der strukturierten Daten der Protokollmeldung. Der Fehlercode besteht aus einer Zeichenfolge und einer Dezimalzahl. Die Zeichenfolge steht für ein bestimmtes Modul.

Fehler beim Zugriff auf eine Protokolldatei oder einen Remote-Protokollserver

Wenn NSX in einer Protokolldatei nicht auf Nachrichten zugreifen oder diese in die Datei schreiben kann, wird ein Alarm generiert. Dies sind die möglichen Fehler:

  • Eine lokale Protokolldatei fehlt.
  • Die Berechtigung oder die Zuständigkeitseinstellung einer lokalen Protokolldatei verhindert, dass NSX in die Datei schreiben kann.
  • NSX kann keine Protokollmeldungen an einen Remote-Protokollserver eines Drittanbieters senden. Beachten Sie, dass kein Alarm ausgelöst wird, wenn NSX keine Protokolle an den Aria Operations for Logs-Agenten sendet.

Der Alarm kann über das Alarm-Framework aufgelöst werden.

Protokollmeldungsformate

Weitere Informationen zu RFC 5424 finden Sie unter https://tools.ietf.org/html/rfc5424. Weitere Informationen zu RFC 3164 finden Sie unter https://tools.ietf.org/html/rfc3164.

RFC 5424 legt für Protokollmeldungen das folgende Format fest: 

<facility * 8 + severity> version UTC-TZ hostname APP-NAME procid MSGID [structured-data] msg
Beispiel für eine Protokollmeldung: 
<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.

Fehlercodes

Eine Liste der Fehlercodes finden Sie im Knowledgebase-Artikel 71077 Fehlercodes für NSX-T Data Center 2.x.