ADC

Protokolle

Protokolle beziehen sich auf softwaregenerierte Daten, die Informationen über Nutzungsmuster, Aktivitäten und Vorgänge innerhalb eines Betriebssystems, einer Anwendung, eines Servers oder eines anderen Geräts enthalten. Die Dateien, in denen diese Protokolle gespeichert werden, werden als Protokolldateien bezeichnet. Protokolldateien sind die primäre Datenquelle für die Netzwerkbeobachtbarkeit.

Dieses Thema behandelt Folgendes:

Auditprotokolle

Auditing ist eine methodische Untersuchung oder Überprüfung eines Zustands oder einer Situation. Mit der Audit-Logging-Funktion können Sie die NetScaler-Status- und Statusinformationen protokollieren, die von verschiedenen Modulen gesammelt wurden. Die Protokollinformationen können sich im Kernel und in den Daemons auf Benutzerebene befinden.

Sie können NetScaler so konfigurieren, dass die Protokollinformationen lokal auf NetScaler gespeichert oder auf einen Remoteserver oder beides exportiert werden. Weitere Informationen zu Audit-Logs finden Sie unter Auditprotokoll.

Audit-Logs konfigurieren

Informationen zur Konfiguration von NetScaler für die Auditprotokollierung finden Sie unter Konfiguration der NetScaler-Appliance für die Auditprotokollierung.

Beispiel für ein Auditprotokoll

Im Folgenden finden Sie ein Beispiel für ein Auditprotokoll:

May 31 02:05:23 <local0.info> 10.106.44.21  05/31/2024:06:05:23 GMT HA1 0-PPE-0 : default API CMD_EXECUTED 7825 0 :  User admuser -
ADM_User NONE - Remote_ip 10.106.44.21 - Command "show ns license" - Status "Success"
<!--NeedCopy-->

Die folgende Abbildung beschreibt das Auditprotokoll:

Format des Auditprotokolls

Auditprotokolle exportieren

Sie können Auditprotokolle und Ereignisse von NetScaler auf branchenübliche Log-Aggregator-Plattformen wie Splunk exportieren, um aussagekräftige Einblicke zu erhalten. Weitere Informationen finden Sie unter Exportieren von Auditprotokollen und Ereignissen direkt von NetScaler nachSplunk.

Verwaltungsprotokolle

Verwaltungsprotokolle sind die Protokolle, die von den Prozessen generiert werden, die auf dem NetScaler Management Core ausgeführt werden. (Zum Beispiel bash, httpd). Die Meldungen, die Teil der folgenden Protokolldateien sind, werden als Teil der Verwaltungsprotokolle exportiert:

  • Shell- oder Plattformprotokolle

    • bash.log: Die Logdatei wird durch den Prozess bash erstellt. Es zeichnet die von der bash-Shell verarbeiteten Befehle auf.
    • sh.log: Die Logdatei wird durch den Prozess sh erstellt. Es zeichnet die von der sh-Shell verarbeiteten Befehle auf.

Zugriff auf Protokolle

  • auth.log: Die Logdatei zeichnet alle SSHd-Aktivitäten und Console-Aktivitäten auf.

  • nsvpn.log: Die Protokolldatei zeichnet detaillierte Informationen zu Aktivitäten und Ereignissen im Virtual Private Network (VPN) auf.

  • httpaccess.log: Die Protokolldatei zeichnet alle HTTP-Aktivitäten auf, die an die Management-IP-Adresse gerichtet sind. In der Regel umfasst diese Protokolldatei den NetScaler-GUI-Zugriff, die NITRO-API und den VPN-Zugriff.

  • httperror.log: Die Protokolldatei zeichnet alle HTTP-Aktivitäten auf, die an die Management-IP-Adresse gerichtet sind und aufgrund eines Timeouts (z. B. das maximale PHP-Timeout wurde erreicht) oder eines Programmierfehlers im Backend zu einem Fehler führen. Regelmäßige Apache-Neustarts werden ebenfalls in diese Datei protokolliert.

  • httpaccess-vpn.log: Die Protokolldatei besteht aus Gateway-Portal-Endpunktdaten, die von Apache bereitgestellt werden und auf die Benutzer zusammen mit Datum und Uhrzeit zugreifen.

  • httperror-vpn.log: Die Protokolldatei besteht aus Gateway-Portal-Endpunktdaten, die von Apache bereitgestellt werden und auf die Benutzer zusammen mit Datum und Uhrzeit zugreifen.

NetScaler-Verwaltungsprotokolle

  • notice.log: Die Protokolldatei ist ein Syslog-Datenstrom und sie zeichnet die Syslog-Datensätze auf, die gemäß dem “Hinweis” -Datenstrom von syslogd generiert werden.

  • ns.log: Die Protokolldatei enthält das NetScaler-Systemprotokoll. Die von mehreren Modulen von NetScaler generierten Protokolle (z. B. Load Balancing, SSL, App Firewall) werden in diese Datei geschrieben. Während des Exports wird nur der Inhalt von ns.log exportiert, dessen Inhalt von den Verwaltungsprozessen geschrieben wurde. Die von den NSPPE-Prozessen geschriebenen Protokolle werden nicht exportiert.

Verwaltungsprotokolle werden von syslogd, das auf NetScaler ausgeführt wird, in den entsprechenden Protokolldateien protokolliert, die von verschiedenen Prozessen generiert werden, die auf dem Management Core ausgeführt werden. Verwaltungsprotokolle werden regelmäßig exportiert, in der Regel alle 60 Sekunden.

Konfigurieren Sie den Export von Verwaltungsprotokollen

Sie können den Export von Verwaltungsprotokollen mit einer der folgenden Methoden konfigurieren:

  • Konfigurieren Sie den Export von Verwaltungsprotokollen auf einen Syslog-Server
  • Konfigurieren Sie den Export von Verwaltungsprotokollen auf einen HTTP-Server oder HEC-Endpunkt wie Splunk

Konfigurieren Sie den Export von Verwaltungsprotokollen auf den Syslog-Server

Um den Export von Verwaltungsprotokollen zu konfigurieren, müssen Sie die folgenden Schritte ausführen:

  1. Erstellen Sie eine Audit-Syslog-Aktion auf NetScaler mit der Management-Log-Option.
  2. Erstellen Sie eine Syslog-Audit-Richtlinie mit der Syslog-Aktion.
  3. Binden Sie die Syslog-Audit-Richtlinie an die globale Systementität, um die Protokollierung aller NetScaler-Systemereignisse zu ermöglichen.
Syslog-Audit-Aktion konfigurieren

Führen Sie den folgenden Befehl aus, um die Syslog-Audit-Aktion auf NetScaler mithilfe der CLI zu konfigurieren:

add audit syslogAction <name> (<serverIP> [-serverPort <port>] -logLevel <logLevel> ... [-managementlog <managementlog> ...] ... [-managementloglevel <managementloglevel> ...][-transport ( TCP | UDP )])
<!--NeedCopy-->

Beispiel:

add audit syslogAction test 10.106.186.102 -serverPort 514 -logLevel ALL -managementlog SHELL NSMGMT -managementloglevel ALL -transport TCP
<!--NeedCopy-->

In dieser Konfiguration:

  • name: Name der Syslog-Aktion
  • serverIP: IP-Adresse des Syslog-Servers.
  • serverPort: Port, auf dem der Syslog-Server Verbindungen akzeptiert.
  • logLevel: Protokollebene prüfen.
  • managementlog: Typen von Verwaltungsprotokollen, die Sie exportieren müssen.
  • managementloglevel: Management-Log-Levels, die Sie für den Export festlegen möchten.
  • transport: Der Transporttyp, der zum Senden von Audit-Logs an den Syslog-Server verwendet wird.

Hinweis:

Wenn Verwaltungsprotokolle aktiviert sind, unterstützt die syslogAction-Konfiguration nur die Server-IP-Adresse und die Portkonfiguration. Domänenbasierter Dienst (DBS) und Lastausgleichskonfigurationen für virtuelle Servernamen werden nicht unterstützt.

Für Load Balancing-Verwaltungsprotokolle, die über mehrere externe Syslog-Server exportiert werden, können Sie die folgende Beispielkonfiguration verwenden:

add service syslog_server <server_ip> UDP <port>

add service syslog_server1 1.3.4.4 UDP 514

add service syslog_server2 1.3.4.5 UDP 514

add lb vserver lb1 UDP <lb_vip> <lb_port>

bind lb vserver lb1 syslog_server1

bind lb vserver lb1 syslog_server2

Konfigurieren Sie in syslogAction Folgendes:

add syslogAction sys1 <server_ip> -serverPort <server_port> -transport UDP -loglevel <loglevel>

add syslogAction sys1 lb_vip -serverPort lb_port -transport UDP -loglevel <loglevel>

Gehen Sie wie folgt vor, um die Syslog-Auditaktion auf NetScaler mithilfe der GUI zu konfigurieren:

  1. Navigieren Sie zur Registerkarte System > Auditing > Syslog > Server und klicken Sie auf Hinzufügen.
  2. Geben Sie auf der Seite Auditing-Server erstellen die folgenden Details an:
    1. Geben Sie einen Namen für den Syslog-Server ein.
    2. Wählen Sie Server-IP aus der Liste Servertyp aus und geben Sie die IP-Adresse und den Port des Syslog-Servers ein.
    3. Wählen Sie die erforderlichen Protokollebenen aus den Abschnitten Log Levels, Management Logs und Management Log Levels aus.
  3. Klicken Sie auf Erstellen.
Syslog-Audit-Richtlinie konfigurieren

Führen Sie den folgenden Befehl aus, um eine Syslog-Audit-Richtlinie mithilfe der CLI zu konfigurieren:

add audit syslogPolicy <name> TRUE <syslogAction>

Beispiel:

add audit syslogPolicy test-policy TRUE test

Gehen Sie wie folgt vor, um eine Syslog-Audit-Richtlinie mithilfe der GUI zu konfigurieren:

  1. Navigieren Sie zur Registerkarte System > Auditing > Syslog > Richtlinien und klicken Sie auf Hinzufügen.
  2. Geben Sie auf der Seite Audit-Syslog-Richtlinie erstellen einen Namen ein, wählen Sie Erweiterte Richtlinie aus, und wählen Sie dann den von Ihnen erstellten Audit-Syslog-Server aus der Serverliste aus.
Bind-Audit-Log-Richtlinie

Führen Sie den folgenden Befehl aus, um die Syslog-Audit-Log-Richtlinie SYSTEM_GLOBAL mithilfe der CLI an den Bindpunkt zu binden:

bind audit syslogGlobal <policyname> -globalBindType SYSTEM_GLOBAL

Beispiel:

bind audit syslogGlobal test-policy -globalBindType SYSTEM_GLOBAL

Führen Sie den folgenden Befehl aus, um die Syslog-Audit-Log-Richtlinie mithilfe der GUI global zu binden:

  1. Navigieren Sie zur Registerkarte System > Auditing > Syslog > Richtlinien und wählen Sie die Syslog-Überwachungsrichtlinie aus, die Sie erstellt haben.
  2. Klicken Sie mit der rechten Maustaste auf die ausgewählte Syslog-Überwachungsrichtlinie und klicken Sie auf Advanced Policy Global Bindings.
  3. Wählen Sie die Syslog-Überwachungsrichtlinie, die Sie erstellt haben, aus der Liste Select Policy aus.
  4. Geben Sie die Priorität in das Feld Priorität ein.
  5. Wählen Sie SYSTEM_GLOBAL im Feld Globaler Bindungstyp aus und klicken Sie auf Binden.
  6. Wählen Sie auf der Seite Syslog-Überwachung die Syslog-Überwachungsrichtlinie aus und klicken Sie auf Fertig.

Sobald die Konfiguration erfolgreich ist, werden die Verwaltungsprotokolle als Syslog-Payloads an den externen Syslog-Server gesendet.

Export von Verwaltungsprotokollen nach Splunk exportieren, der als HTTP-Server konfiguriert ist

Sie können Splunk als HTTP-Server konfigurieren. In der HTTP-Serverkonfiguration können Sie den HTTP Event Collector verwenden, um Management-Logs über HTTP (oder HTTPS) direkt von Ihrem NetScaler an die Splunk-Plattform zu senden. Weitere Informationen finden Sie unter Verwaltungsprotokolle nach Splunk exportieren, das als HTTP-Server konfiguriert ist.

Beispiel für ein Verwaltungsprotokoll

Im Folgenden finden Sie ein Beispiel für ein Verwaltungsprotokoll:

10.222.4.55 10.217.11.103 [04/Oct/2023:18:38:34 +0000] [43533] "GET / HTTP/1.1" 200 20783 "Go-http-client/l.1" "Time: 38848 microsecs"

127.0.0.1 [04/0ct/2023:16:30:00 +0000] [16510] "GET / HTTP/1.1" 200 20783 “curl/7.87.0" "Time: 42015 microsecs"

[Wed Oct 04 16:00:00.093670 2023] [authz_core:error] [pid 7487] [client 127.0.0.1:16161] AH01630: client denied by server configuration: /netscaler/ns_gui/var
<!--NeedCopy-->

Die folgende Abbildung beschreibt das Verwaltungsprotokoll:

Format des Verwaltungsprotokolls

Das Folgende ist ein bash-Beispielprotokoll:

Apr 24 11:21:00 <local7.notice> ns bash[3893]: root on /dev/pts/0 shell_command="PATH=/netscaler:/bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec:/usr/local/bin:/usr/local/sbin:."
Apr 24 11:21:00 <local7.notice> ns bash[3893]: root on /dev/pts/0 shell_command="EDITOR=/usr/bin/vi"
Apr 24 11:21:00 <local7.notice> ns bash[3893]: root on /dev/pts/0 shell_command="[ -f /var/python/bin/python ]"
Apr 24 11:21:00 <local7.notice> ns bash[3893]: root on /dev/pts/0 shell_command="export PATH=$PATH:/var/python/bin"
Apr 24 11:21:00 <local7.notice> ns bash[3893]: root on /dev/pts/0 shell_command="[ -f /var/golang/bin/go ]"
Apr 24 11:21:00 <local7.notice> ns bash[3893]: root on /dev/pts/0 return_code="1"
Apr 24 11:21:00 <local7.notice> ns bash[3893]: root on /dev/pts/0 shell_command=""
Apr 24 11:21:12 <local7.notice> ns bash[3893]: root on /dev/pts/0 shell_command="cat /var/log/bash.log"
<!--NeedCopy-->

Das Folgende ist ein httpaccess-Beispielprotokoll:

10.102.201.155 -> 10.102.201.155 - - [10/Jun/2024:23:07:11 +0530] [1571] "GET /nitro/v1/config/route6?format=json&sessionid=[FILTERED] HTTP/1.1" 200 1162 "-" "-" "Time: 9797 microsecs"

10.102.201.155 -> 10.102.201.155 - - [10/Jun/2024:23:07:11 +0530] [1571] "GET /nitro/v1/config/nslicense?format=json&sessionid=[FILTERED] HTTP/1.1" 200 1118 "-" "-" "Time: 7774 microsecs"

10.102.201.155 -> 10.102.201.155 - - [10/Jun/2024:23:07:11 +0530] [1571] "GET /nitro/v1/config/appflowparam?format=json&sessionid=[FILTERED] HTTP/1.1" 200 1643 "-" "-" "Time: 8098 microsecs"

10.102.201.155 -> 10.102.201.155 - - [10/Jun/2024:23:07:12 +0530] [1571] "GET /nitro/v1/config/snmpmib?format=json&sessionid=[FILTERED] HTTP/1.1" 200 347 "-" "-" "Time: 8185 microsecs"

10.102.201.155 -> 10.102.201.155 - - [10/Jun/2024:23:11:16 +0530] [1570] "GET /nitro/v1/config/nslicense?format=json&sessionid=[FILTERED] HTTP/1.1" 200 1118 "-" "-" "Time: 23195 microsecs"

10.102.201.155 -> 10.102.201.155 - - [10/Jun/2024:23:11:17 +0530] [1570] "GET /nitro/v1/config/nslicenseserver?format=json&sessionid=[FILTERED] HTTP/1.1" 200 57 "-" "-" "Time: 8992 microsecs"
<!--NeedCopy-->

Das Folgende ist ein httperror-Beispielprotokoll:

[Mon Jun 10 15:00:01.016898 2024] [mpm_prefork:notice] [pid 47106] AH00171: Graceful restart requested, doing restart

[Mon Jun 10 15:00:01.323746 2024] [mpm_prefork:notice] [pid 47106] AH00163: Apache/2.4.56 (Unix) mod_perl/2.0.10 Perl/v5.30.2 configured -- resuming normal operations

[Mon Jun 10 15:00:01.323756 2024] [core:notice] [pid 47106] AH00094: Command line: '/bin/httpd -f /etc/httpd.conf'

[Mon Jun 10 15:30:00.211099 2024] [authz_core:error] [pid 80696] [client 127.0.0.1:31128] AH01630: client denied by server configuration: /netscaler/ns_gui/var

[Mon Jun 10 15:38:06.205307 2024] [authz_core:error] [pid 80696] [client 127.0.0.2:24903] AH01630: client denied by server configuration: /netscaler/ns_gui/var
<!--NeedCopy-->

Das Folgende ist ein auth-Beispielprotokoll:

Jun 13 12:03:33 <auth.info> ns login: login on pts/1 as root
Jun 13 12:03:33 <auth.info> ns sshd[17798]: Received disconnect from 10.102.201.155 port 33145:11: Normal Shutdown
Jun 13 12:03:33 <auth.info> ns sshd[17798]: Disconnected from user admuser 10.102.201.155 port 33145
Jun 13 12:03:33 <auth.info> ns sshd[17803]: rexec line 19: Deprecated option UsePrivilegeSeparation
Jun 13 12:03:34 <auth.info> ns sshd[17803]: Accepted keyboard-interactive/NS for admuser from 10.102.201.155 port 65127 ssh2
<!--NeedCopy-->

Das Folgende ist ein nsvpn-Beispielprotokoll:

Jun  6 09:18:16 <local1.info> ns [1289]: (0-15) extract_ldap_attribute: retrieved mail value mail@citrix.com for Complex1, length is 15
Jun  6 09:18:16 <local1.info> ns [1289]: (0-15) receive_ldap_user_search_event: extracted attribute, name: mail, value: mail@citrix.com
Jun  6 09:18:16 <local1.info> ns [1289]: (0-15) receive_ldap_user_search_event: built group string for Complex1 of:group5 group4 group3 g1
Jun  6 09:18:16 <local1.info> ns [1289]: (0-15) receive_ldap_user_search_event: User search succeeded, attempting user authentication(Bind) for <Complex1>
Jun  6 09:18:16 <local1.info> ns [1289]: (0-15) receive_ldap_user_bind_event: Got user bind event.
Jun  6 09:18:16 <local1.info> ns [1289]: (0-15) receive_ldap_user_bind_event: User authentication (Bind event) for user Complex1 succeeded
Jun  6 09:18:16 <local1.notice> ns [1289]: (0-15) send_accept: sending accept to kernel for : Complex1
Jun  6 09:18:16 <local1.info> ns [1289]: (0-15) aaad_alloc_serialize_keyValue_attrs:  2 custom attribute key_len 4  value_len 15
Jun  8 06:21:48 <local1.info> ns [1289]: (0-62) aaad_remove_user_login_failure_info:  sqlite3_step is SUCCESS
<!--NeedCopy-->

Das Folgende ist ein httperror-vpn-Beispielprotokoll:

[Thu Jun 06 17:43:38.184137 2024] [core:error] [pid 63478] (63)File name too long: [client 127.0.0.2:42117] AH00036: access to /logon/L                                                                                                                                                       ogonPoint/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                                                                                                                                                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                                                                                                                                                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                                                                                                                                                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                                                                                                                                                       aaaaaaaaaResources/List failed (filesystem path '/var/netscaler/logon/LogonPoint/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                                                                                                                                                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                                                                                                                                                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                                                                                                                                                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                                                                                                                                                       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaResources')
[Thu Jun 06 17:44:23.338278 2024] [core:info] [pid 63475] [client 127.0.0.2:65214] AH00128: File does not exist: /var/netscaler/logon/L                                                                                                                                                       ogoqqqqnPoint/Resources/List
[Thu Jun 06 17:44:41.245211 2024] [core:info] [pid 63476] [client 127.0.0.2:56821] AH00128: File does not exist: /var/netscaler/logon/L                                                                                                                                                       og@
[Tue Jun 11 10:10:55.360797 2024] [core:info] [pid 37517] [client 127.0.0.2:53996] AH00128: File does not exist: /netscaler/ns_gui/vpn/                                                                                                                                                       pluginCustomization.json
[Mon Jun 17 14:11:15.816726 2024] [core:info] [pid 63188] [client 127.0.0.2:27594] AH00128: File does not exist: /netscaler/ns_gui/vpn/                                                                                                                                                       pluginCustomization.json
<!--NeedCopy-->

Das Folgende ist ein httpaccess-vpn-Beispielprotokoll:

127.0.0.2 - - [20/Jun/2024:08:37:47 +0000] [1508] "GET /logon/LogonPoint/custom/strings.en.js?_=1718869081399 HTTP/1.1" 304 -          "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0" "Time: 529 microsecs"
127.0.0.2 - - [20/Jun/2024:08:37:47 +0000] [1508] "GET /logon/LogonPoint/plugins/ns-gateway/nsg-epa.js HTTP/1.1" 304 - "-" "Mo         zilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0" "Time: 303 microsecs"
127.0.0.2 - - [20/Jun/2024:08:37:47 +0000] [1508] "GET /logon/LogonPoint/plugins/ns-gateway/nsg-setclient.js HTTP/1.1" 304 - "         -" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0" "Time: 311 microsecs"
127.0.0.2 - - [20/Jun/2024:08:37:47 +0000] [1508] "GET /logon/LogonPoint/plugins/ns-gateway/ns-nfactor.js HTTP/1.1" 304 - "-"          "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0" "Time: 315 microsecs"
127.0.0.2 - - [20/Jun/2024:08:37:47 +0000] [1508] "GET /vpn/media/citrixgateway_logo_white.png HTTP/1.1" 304 - "-" "Mozilla/5.         0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0" "Time: 358 microsecs"
<!--NeedCopy-->

Verwaltungsprotokolle exportieren

Sie können Verwaltungsprotokolle von NetScaler auf branchenübliche Log-Aggregator-Plattformen wie Splunk exportieren. Weitere Informationen finden Sie unter Managementprotokolle direkt von NetScaler nach Splunk exportieren.

Probleme im Zusammenhang mit Verwaltungsprotokollen beheben

Selbst nachdem Sie den Export von Verwaltungsprotokollen konfiguriert haben, können einige Probleme auftreten, die verhindern, dass Verwaltungsprotokolle zu den Observability-Endpunkten exportiert werden. Dieser Abschnitt enthält Tipps zur Behebung von Problemen im Zusammenhang mit den folgenden Szenarien:

Verwaltungsprotokolle werden nicht auf den Syslog-Server exportiert

Gehen Sie wie folgt vor, wenn Verwaltungsprotokolle nicht auf den Syslog-Server exportiert werden:

  1. Überprüfen Sie, ob Sie einige Verwaltungsprotokolle für die Syslog-Aktion aktiviert haben.

    Szenario

    John, ein Systemadministrator, führte den Befehl show syslogaction ns-mgmt-logs-act aus. In der Ausgabe fand er Managementlog: NONE und Managementloglevel: NONE, was bestätigte, dass die Verwaltungsprotokolle nicht aktiviert waren.

    Syslogaction-Befehlsausgabe anzeigen

    Um dieses Problem zu beheben, aktivierte er Verwaltungsprotokolle und Verwaltungsprotokollebenen, indem er den folgenden Befehl ausführte:

    add syslogaction ns-mgmt-logs-act 9.9.9.9 -loglevel none -mgmtlogLevel all -managementlog all
    <!--NeedCopy-->
    

    Nach der Aktivierung führte er den Befehl show syslogaction ns-mgmt-logs-act aus und überprüfte, ob die Verwaltungsprotokolle aktiviert waren, wie in der folgenden Ausgabe hervorgehoben.

    Anzeige der syslogaction-Befehlsausgabe aktiviert

  2. Prüfen Sie, ob die konfigurierten Protokolle lokal generiert werden. Wenn Sie beispielsweise Verwaltungsprotokolle mit dem Schweregrad INFO konfiguriert haben, überprüfen Sie, ob /var/log/ns.log Verwaltungsprotokolle (Zeilen, die nicht ‘-PPE-‘ enthalten) enthalten, die mit dem Schweregrad INFO generiert wurden. Im Folgenden sind einige Szenarien aufgeführt:

    Szenario 1

    Cassidy, ein Systemadministrator, fügte die folgende Aktion hinzu, bei der nur NSMGMT-Warnprotokolle aktiviert waren, und stellte fest, dass die Protokolle nicht generiert wurden.

    add syslogaction ns-mgmt-logs-act 9.9.9.9 -loglevel none -mgmtlogLevel warning -managementlog NSMGMT
    <!--NeedCopy-->
    

    Cassidy sah sich die lokalen Protokolldateien ns.log und notice.log an und stellte fest, dass keine Warnmeldungen generiert wurden.

    root@ns# cat /var/log/ns.log | grep -v -e '-PPE-'
    Jun 26 05:00:00 ns newsyslog[74791]: logfile turned over due to size>100K
    rootQns# cat /var/log/notice.log | grep warn
    Jun 26 05:08:34 <local7.notice> ns bash[81962]: root on /dev/pts/5 shell_command="cat /var/log/notice.log | grep warning"
    Jun 26 05:08:40 <local7.notice> ns bash[81962]: root on /dev/pts/5 shell_command="cat /var/log/notice.log | grep warn"
    Jun 26 05:09:15 <local7.notice> ns bash[81962]: root on /dev/pts/5 shell_command="cat /var/log/notice.log | grep warn"
    <!--NeedCopy-->
    

    Szenario 2

    John, ein Systemadministrator, fügte die folgende Aktion hinzu, bei der alle Verwaltungsprotokolle für alle Ebenen aktiviert wurden.

    add syslogaction ns-mgmt-logs-act 9.9.9.9 -loglevel none -mgmtlogLevel all -managementlog all
    <!--NeedCopy-->
    

    Die Protokolle wurden lokal in bash.log generiert und daher wurden sie auch an ihrem Observability-Endpunkt angezeigt.

    root@ns# tail -f /var/log/bash.log
    Jun 26 05:16:54 <local7.notice> ns bash[4278]: root on (null) return_code="l"
    Jun 26 05:16:54 <local7.notice> ns bash[5909]: root on (null) shell_command="true"
    Jun 26 05:16:54 <local7.notice> ns bash[5909]: root on (null) shell_command="curl 10.102.154.54; sleep 0.5"
    Jun 26 05:16:54 <local7.notice> ns bash[5909]: root on (null)shell_command="curl 10.102.154.54"
    <!--NeedCopy-->
    
  3. Prüfen und bestätigen Sie Folgendes:

    • Wenn Sie das richtige Transportprotokoll verwenden
    • Wenn Sie die richtige IP-Adresse oder den richtigen Domänennamen verwenden
    • Wenn Sie die richtige Load Balancing-Konfiguration verwenden
    • Wenn der Domänenname aufgelöst ist
    • Wenn der Dienst oder der virtuelle Server aktiv ist
  4. Prüfen und bestätigen Sie, dass die Richtlinie mit der Regel “True” erstellt und an das globale System gebunden wurde. Wenn die Bindung nicht vorhanden ist, werden die Protokolle nicht exportiert.

    Szenario

    Cassidy, ein Systemadministrator, führte den Befehl show syslogglobal aus und stellte fest, dass die Richtlinie nicht an System Global gebunden war.

    > show syslogglobal
    Done
    <!--NeedCopy-->
    

    Cassidy führte den folgenden Befehl aus, um die Richtlinie an System Global zu binden:

    bind syslogGlobal -policyName ns-mgmt-logs-pol -priority 1 Done
    <!--NeedCopy-->
    

    Nach dem Binden zeigte der Befehl show syslogglobal die Bindungsdetails an.

    > sh syslogglobal
    1)      Policy Name: ns-mgmt-logs-pol
            Priority: 1
            GlobalType: SYSTEM_GLOBAL
    Done
    <!--NeedCopy-->
    
  5. Führen Sie nstrace aus, um den UDP- oder TCP-Fluss auf Auffälligkeiten zu überprüfen. Prüfen Sie, ob der Endpunkt für die Verwendung von TLS oder SSL konfiguriert ist, NetScaler jedoch tatsächlich unverschlüsselte Daten sendet oder umgekehrt.

Verwaltungsprotokolle werden auf Splunk (HEC) nicht angezeigt

Gehen Sie wie folgt vor, wenn Verwaltungsprotokolle nicht nach Splunk (HEC) exportiert werden:

  1. Prüfen Sie, ob Sie Verwaltungsprotokolle für ein Zeitreihenprofil aktiviert haben. Führen Sie zur Überprüfung den Befehl show analyticsprofile <profilename> aus und sehen Sie sich die Ausgabe an.

    Szenario

    Cassidy, eine Systemadministratorin, erkannte, dass sie eigentlich das JSON-Format und nicht das Syslog-Format benötigte. Daher entfernte sie alle Management-Syslog-Konfigurationen und fügte Analytics-Konfigurationen hinzu. Sie stellte jedoch fest, dass die Protokolle nicht aus NetScaler gingen. Als sie den Befehl show analyticsprofile <name> ausführte, sah sie Managementlog: NONE in der Ausgabe und stellte fest, dass sie vergessen hatte, Verwaltungsprotokolle für das Analyseprofil zu aktivieren.

    Um das Problem zu beheben, aktivierte sie Verwaltungsprotokolle mit set analytics profile <name> -managementlog ACCESS. Mit diesem Fix sah sie, dass die Protokolle vom NetScaler gesendet wurden und auch der Befehl show analyticsprofile <name> Managementlog: ACCESS anzeigte.

    Analytics-Profilverwaltungsprotokoll anzeigen, das auf "Ohne" gesetzt ist

  2. Prüfen Sie, ob die konfigurierten Protokolle tatsächlich lokal generiert werden. Wenn Sie beispielsweise NSMGMT-Verwaltungsprotokolle konfiguriert haben, können Sie überprüfen, ob /var/log/ns.log Verwaltungsprotokolle (Zeilen, die kein ‘-PPE-‘ enthalten) generiert hat.

  3. Prüfen und bestätigen Sie Folgendes:

    • Wenn Sie das richtige Profil verwenden. Sie müssen das Timeseries-Profil verwenden
    • Wenn der Dienst behoben ist und aktiv ist
    • Ob Metadaten (-analyticsEndpointMetadata) richtig konfiguriert sind und ein gültiges JSON sind und ob alle darin enthaltenen Felder in den nach Splunk exportierten Protokollen vorhanden sind
    • Wenn das Splunk Auth Token korrekt ist. Da das Auth-Token nicht angezeigt wird, müssen Sie sicherstellen, dass es korrekt im Format -analyticsAuthToken ‘Splunk <token>’ eingegeben wurde
  4. Führen Sie nstrace aus, um den TCP- oder HTTP-Fluss auf Auffälligkeiten zu überprüfen. Prüfen Sie, ob der Endpunkt für die Verwendung von TLS oder SSL konfiguriert ist, NetScaler jedoch unverschlüsselte Daten sendet oder umgekehrt. Sie können weiter überprüfen, ob das exportierte JSON nicht falsch formatiert ist.

Allgemeine Tipps zur Fehlerbehebung, wenn Verwaltungsprotokolle auf keinem Observability-Endpunkt angezeigt werden

Gehen Sie wie folgt vor, wenn die Tipps in den Abschnitten Verwaltungsprotokolle werden nicht auf den Syslog-Server exportiert und Verwaltungsprotokolle, die in Splunk (HEC) nicht angezeigt werden, Ihr Problem nicht lösen:

  1. Sehen Sie sich die folgenden Protokolldateien an, die sich auf den Prozess beziehen, der Verwaltungsprotokolle exportiert. Diese Protokolldateien könnten Ihnen eine Vorstellung von dem Problem geben:

    • /var/log/export_mgmtlog_status.log
    • /var/log/export_mgmtlog_cron.log

    Szenario: Cassidy, ein Systemadministrator, sah defekte Pipe-Fehler in export_mgmtlog_status.log und stellte fest, dass ihr Collector aufgrund von Firewall-Problemen Resets sendete, was auf ihrer Seite behoben wurde.

    Fri May 10 04:02:15 2024   do_logexport.py   ERROR   Traceback (most recent call last):
       File "/netscaler/do_logexport.py", line 505, in netio_send
       pe_socket.sendall(data)
      BrokenPipeError: [Errno 32] Broken pipe
    <!--NeedCopy-->
    
  2. Prüfen Sie, ob die Konfigurationsdatei /nsconfig/mgmtlogcfg.json ordnungsgemäß generiert wurde und darauf hinweist, dass sie Syslog- oder JSON-bezogene Konfigurationen enthält.

    Wenn beispielsweise sowohl Syslog als auch JSON konfiguriert sind, sieht die Datei /nsconfig/mgmtlogcfg.json wie unten dargestellt aus. Das Feld “syslog” bestätigt, dass Syslog konfiguriert ist, während das Feld “json” bestätigt, dass json konfiguriert ist.

    root@ns# cat /nsconfig/mgmtlogcfg.json
    {"syslog":{"typemask":7,"levelmask":127,"ip":"127.0.0.2","port" :5566},"json":[{"name":"ns-mgmt-log-json-profile","typemask":2,"ip":"127.0.0.2","port":5563,"metadata":"{"index":"ns-mgmt-log-syslog-index"}"}]}
    <!--NeedCopy-->
    
  3. Stellen Sie sicher, dass Sie den richtigen Index und den richtigen Zeitstempel sehen.

    Szenario

    Cassidy, eine Systemadministratorin, stellte fest, dass sie den Syslog-Index namens ns-mgmt-log-syslog-index statt ns-mgmt-log-json-index mit Splunk konfiguriert hatte, was später korrigiert wurde.

    Analytisches Profil anzeigen (korrekter Index)

  4. Versuchen Sie bei Cluster-Bereitstellungen, den Befehl force cluster sync auszuführen, wenn die Protokolle nicht von Nicht-CCO-Knoten stammen.

  5. Netzprofile: Es ist auch möglich, Netzprofile zu verwenden. Stellen Sie für Syslog sicher, dass Sie das ‘-netprofile’ für die Syslog-Aktion festgelegt haben. Wenn Sie Syslogs ausgleichen oder sie im JSON-Format exportieren, stellen Sie sicher, dass Sie das Netprofile für den Service festgelegt haben.

  6. Partitionen: Die Funktion für Verwaltungsprotokolle wird auf nicht standardmäßigen Partitionen nicht unterstützt.

  7. Zeitstempel: Die von den Prozessen generierten Verwaltungsprotokolle werden regelmäßig exportiert. Daher ist der Zeitpunkt, zu dem Sie das Verwaltungsprotokoll erhalten, möglicherweise nicht mit dem Zeitpunkt identisch, zu dem es generiert wurde. Außerdem entspricht das Datumsformat möglicherweise nicht dem für die Syslog-Aktion konfigurierten Datumsformat, da das Management-Syslog dem RFC-5424-Format folgt.