ADC

Journaux

Les journaux font référence aux données générées par le logiciel et contiennent des informations sur les modèles d’utilisation, les activités et les opérations au sein d’un système d’exploitation, d’une application, d’un serveur ou d’un autre appareil. Les fichiers qui stockent ces journaux sont appelés fichiers journaux. Les fichiers journaux constituent la principale source de données d’observabilité du réseau.

Cette rubrique couvre les sujets suivants :

Journaux d’audit

L’audit est un examen méthodique ou un examen d’un état ou d’une situation. La fonction de journalisation des audits vous permet de consigner les états de NetScaler et les informations d’état collectées par différents modules. Les informations du journal peuvent se trouver dans le noyau et dans les démons de niveau utilisateur.

Vous pouvez configurer NetScaler pour stocker les informations du journal localement sur NetScaler ou les exporter vers un serveur distant, ou les deux. Pour plus d’informations sur les journaux d’audit, consultez la section Journalisation d’audit.

Configurer des journaux d’audit

Pour plus d’informations sur la configuration de NetScaler pour la journalisation d’audit, consultez la section Configuration de l’appliance NetScaler pour la journalisation d’audit.

Exemple de journal d’audit

Voici un exemple de journal d’audit :

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-->

L’image suivante représente un journal d’audit :

Format du journal d'audit

Exporter des journaux d’audit

Vous pouvez exporter les journaux d’audit et les événements de NetScaler vers des plateformes d’agrégation de journaux standard telles que Splunk et obtenir des insights pertinents. Pour plus d’informations, consultez Exporter les journaux d’audit et les événements directement à partir de NetScaler vers Splunk.

Journaux de gestion

Les journaux de gestion sont des journaux générés par les processus qui s’exécutent sur le cœur de gestion NetScaler. (Par exemple, bash, httpd). Les messages contenus dans les fichiers journaux suivants sont exportés avec les journaux de gestion :

  • Logs du shell ou de la plateforme

    • bash.log : le fichier journal est créé par le processus bash. Il enregistre les commandes traitées par le shell bash.
    • sh.log : le fichier journal est créé par le processus sh. Il enregistre les commandes traitées par le shell sh.

Journaux d’accès

  • auth.log : le fichier journal enregistre toutes les activités SSHd et Console.

  • nsvpn.log : le fichier journal enregistre des informations détaillées sur les activités et les événements du réseau privé virtuel (VPN).

  • httpaccess.log : le fichier journal enregistre toute activité HTTP dirigée vers l’adresse IP de gestion enregistrée. Ce fichier journal inclut généralement l’accès à l’interface graphique NetScaler, à l’API NITRO et à l’accès VPN.

  • httperror.log : le fichier journal enregistre toute activité HTTP dirigée vers l’adresse IP de gestion et entraînant une erreur due à un délai d’expiration (par exemple, le délai maximal PHP atteint) ou à une erreur de programmation dans le programme principal. Les redémarrages périodiques d’Apache sont également journalisés dans ce fichier.

  • httpaccess-vpn.log : Le fichier journal contient les données des points de terminaison du portail de passerelle transmises par Apache auxquelles les utilisateurs accèdent, ainsi que la date et l’heure.

  • httperror-vpn.log : Le fichier journal contient les données des points de terminaison du portail de passerelle transmises par Apache auxquelles les utilisateurs accèdent, ainsi que la date et l’heure.

Journaux de gestion NetScaler

  • notice.log : le fichier journal est un flux de données syslog qui enregistre les messages syslog générés conformément au flux de données « notice » de syslogd.

  • ns.log : le fichier journal contient le journal système NetScaler. Les journaux générés par plusieurs modules de NetScaler (par exemple, équilibrage de charge, SSL, pare-feu d’applications) sont écrits dans ce fichier. Lors de l’export, seul le contenu de ns.log qui est écrit par les processus de gestion est exporté. Les journaux écrits par les processus NSPPE ne sont pas exportés.

Les journaux de gestion sont enregistrés dans les fichiers journaux respectifs par l’exécution de syslogd sur NetScaler. Ces fichiers sont générés par divers processus exécutés sur le cœur de gestion. Les journaux de gestion sont exportés périodiquement, généralement toutes les 60 secondes.

Configurer l’exportation des journaux de gestion

Vous pouvez configurer l’exportation des journaux de gestion à l’aide de l’une des méthodes suivantes :

  • Configurer l’exportation des journaux de gestion vers un serveur syslog
  • Configurer l’exportation des journaux de gestion vers un serveur HTTP ou un point de terminaison HEC tel que Splunk

Configuration de l’exportation des journaux de gestion vers le serveur Syslog

Pour configurer l’exportation des journaux de gestion, vous devez suivre les étapes suivantes :

  1. Créez une action syslog d’audit sur NetScaler à l’aide de l’option journal de gestion.
  2. Créez une stratégie d’audit Syslog avec l’action Syslog.
  3. Liez la stratégie d’audit Syslog à l’entité globale du système pour permettre la journalisation de tous les événements système NetScaler.
Configurer l’action d’audit Syslog

Pour configurer l’action d’audit Syslog sur NetScaler à l’aide de l’interface de ligne de commande, exécutez la commande suivante :

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

Exemple :

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

Dans cette configuration :

  • name: nom de l’action Syslog
  • serverIP: adresse IP du serveur Syslog.
  • serverPort: port sur lequel le serveur Syslog accepte les connexions.
  • logLevel: niveau du journal d’audit.
  • managementlog: types de journaux de gestion que vous devez exporter.
  • managementloglevel: niveaux de journal de gestion que vous souhaitez définir pour l’exportation.
  • transport: type de transport utilisé pour envoyer les journaux d’audit au serveur Syslog.

Remarque :

Lorsque les journaux de gestion sont activés, la configuration syslogAction ne prend en charge que l’adresse IP du serveur et la configuration des ports. Les configurations de nom de serveur virtuel d’équilibrage de charge et de service basé sur le domaine (DBS) ne sont pas prises en charge.

Pour les journaux de gestion de l’équilibrage de charge exportés sur plusieurs serveurs syslog externes, vous pouvez utiliser l’exemple de configuration suivant :

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

Dans syslogAction, configurez les éléments suivants :

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

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

Pour configurer l’action d’audit Syslog sur NetScaler à l’aide de l’interface graphique, effectuez les étapes suivantes :

  1. Accédez à l’onglet Système > Audit > Syslog > Serveur et cliquez sur Ajouter.
  2. Sur la page Créer un serveur d’audit, fournissez les informations suivantes :
    1. Entrez un nom pour le serveur Syslog.
    2. Sélectionnez IP du serveur dans la liste des types de serveurs et entrez l’adresse IP et le port du serveur Syslog.
    3. Choisissez les niveaux de journalisation requis dans les sections Niveaux de journalisation, Journaux de gestion et Niveaux de journalisation de gestion.
  3. Cliquez sur Créer.
Configurer la stratégie d’audit Syslog

Pour configurer une stratégie d’audit syslog à l’aide de l’interface de ligne de commande, exécutez la commande suivante :

add audit syslogPolicy <name> TRUE <syslogAction>

Exemple :

add audit syslogPolicy test-policy TRUE test

Pour configurer une stratégie d’audit Syslog à l’aide de l’interface graphique, effectuez les étapes suivantes :

  1. Accédez à l’onglet Système > Audit > Syslog > Politiques et cliquez sur Ajouter.
  2. Sur la page Créer une stratégie Syslog d’audit, entrez un nom, sélectionnez Stratégie avancée, puis sélectionnez le serveur Syslog d’audit que vous avez créé dans la liste des serveurs.
Stratégie relative aux journaux d’audit Bind

Pour lier la stratégie du journal d’audit Syslog au point de liaison à l’aide de l’interface de ligne de commande SYSTEM_GLOBAL, exécutez la commande suivante :

bind audit syslogGlobal <policyname> -globalBindType SYSTEM_GLOBAL

Exemple :

bind audit syslogGlobal test-policy -globalBindType SYSTEM_GLOBAL

Pour lier globalement la stratégie du journal d’audit Syslog à l’aide de l’interface graphique, exécutez la commande suivante :

  1. Accédez à l’onglet Système > Audit > Syslog > Stratégies et sélectionnez la stratégie d’audit syslog que vous avez créée.
  2. Cliquez avec le bouton droit sur la stratégie d’audit Syslog sélectionnée, puis cliquez sur Advanced Policy Global Bindings.
  3. Sélectionnez la stratégie d’audit Syslog que vous avez créée dans la liste Sélectionner une stratégie.
  4. Entrez la priorité dans le champ Priorité.
  5. Sélectionnez SYSTEM_GLOBAL dans le champ Type de liaison global et cliquez sur Lier.
  6. Sur la page Audit Syslog, sélectionnez la stratégie d’audit Syslog et cliquez sur Terminé.

Une fois la configuration réussie, les journaux de gestion sont envoyés sous forme de charges utiles syslog au serveur syslog externe.

Configurer l’exportation des journaux de gestion vers Splunk configuré en tant que serveur HTTP

Vous pouvez configurer Splunk en tant que serveur HTTP. Dans la configuration du serveur HTTP, vous pouvez utiliser le collecteur d’événements HTTP pour envoyer des journaux de gestion via HTTP (ou HTTPS) directement à la plateforme Splunk depuis votre NetScaler. Pour plus d’informations, consultez Exporter les journaux de gestion vers Splunk configuré en tant que serveur HTTP.

Exemple de journal de gestion

Voici un exemple de journal de gestion :

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-->

L’image suivante représente un journal de gestion :

Format du journal de gestion

Voici un exemple de journalbash :

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-->

Voici un exemple de journalhttpaccess :

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-->

Voici un exemple de journalhttperror :

[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-->

Voici un exemple de journalauth :

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-->

Voici un exemple de fichier nsvpn.log :

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-->

Voici un exemple de journalhttperror-vpn :

[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-->

Voici un exemple de journalhttpaccess-vpn :

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-->

Exporter des journaux de gestion

Vous pouvez exporter des journaux de gestion depuis NetScaler vers des plateformes d’agrégation de journaux standard telles que Splunk. Pour plus d’informations, consultez Exporter les journaux de gestion directement depuis NetScaler vers Splunk.

Résoudre les problèmes liés aux journaux de gestion

Même après avoir configuré l’exportation des journaux de gestion, certains problèmes peuvent empêcher l’exportation des journaux de gestion vers les points de terminaison d’observabilité. Cette section fournit des conseils pour résoudre les problèmes liés aux scénarios suivants :

Les journaux de gestion ne sont pas exportés vers le serveur syslog

Lorsque les journaux de gestion ne sont pas exportés vers le serveur syslog, procédez comme suit :

  1. Vérifiez si vous avez activé certains journaux de gestion sur l’action syslog.

    Scénario

    John, un administrateur système, a exécuté la commande show syslogaction ns-mgmt-logs-act. Dans le résultat, il a trouvé Managementlog: NONE et Managementloglevel: NONE, ce qui a confirmé que les journaux de gestion n’étaient pas activés.

    Afficher la sortie de la commande syslogaction

    Pour résoudre ce problème, il a activé les journaux de gestion et les niveaux de journaux de gestion en exécutant la commande suivante :

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

    Après l’activation, il a exécuté la commande show syslogaction ns-mgmt-logs-act et a vérifié que les journaux de gestion étaient activés, comme indiqué dans le résultat suivant.

    Afficher la sortie de la commande syslogaction activée

  2. Vérifiez si les journaux configurés sont générés localement. Par exemple, si vous avez configuré des journaux de gestion avec la gravité INFO, vérifiez si /var/log/ns.log contient des journaux de gestion (lignes qui ne contiennent pas « -PPE- ») générés avec la gravité INFO. Voici quelques scénarios :

    Scénario 1

    Cassidy, un administrateur système, a ajouté l’action suivante pour activer uniquement les journaux d’avertissement NSMGMT et a constaté que les journaux n’étaient pas générés.

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

    Cassidy a examiné les fichiers journaux locaux ns.log et notice.log et a constaté qu’aucun message de niveau d’avertissement n’avait été généré.

    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-->
    

    Scénario 2

    John, administrateur système, a ajouté l’action suivante qui a activé tous les journaux de gestion pour tous les niveaux.

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

    Les journaux étaient générés localement dans le bash.log et, par conséquent, la même chose apparaissait également à leur point de terminaison d’observabilité.

    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. Vérifiez et confirmez les points suivants :

    • Si vous utilisez le protocole de transport approprié
    • Si vous utilisez l’adresse IP ou le nom de domaine appropriés
    • Si vous utilisez la configuration d’équilibrage de charge appropriée
    • Si le nom de domaine est résolu
    • Si le service ou le serveur virtuel est opérationnel
  4. Vérifiez et confirmez que la stratégie est créée avec la règle « vraie » et liée au système global. Si la liaison n’est pas présente, les journaux ne sont pas exportés.

    Scénario

    Cassidy, un administrateur système, a exécuté la commande show syslogglobal et a remarqué que la stratégie n’était pas liée au système global.

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

    Cassidy a exécuté la commande suivante pour lier la stratégie au système global :

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

    Après la liaison, la commande show syslogglobal affichait les détails de la liaison.

    > sh syslogglobal
    1)      Policy Name: ns-mgmt-logs-pol
            Priority: 1
            GlobalType: SYSTEM_GLOBAL
    Done
    <!--NeedCopy-->
    
  5. Exécutez nstrace pour vérifier la présence d’anomalies dans le flux UDP ou TCP. Vérifiez si le point de terminaison est configuré pour utiliser TLS ou SSL mais que NetScaler envoie en réalité des données non chiffrées ou inversement.

Les journaux de gestion ne sont pas visibles sur Splunk (HEC)

Lorsque les journaux de gestion ne sont pas exportés vers Splunk (HEC), effectuez les opérations suivantes :

  1. Vérifiez si vous avez activé les journaux de gestion sur un profil de série chronologique. Pour vérifier, exécutez la commande show analyticsprofile <profilename>et examinez la sortie.

    Scénario

    Cassidy, une administratrice système, s’est rendu compte qu’elle avait besoin du format JSON et non du format syslog. Elle a donc supprimé toutes les configurations de gestion syslog et ajouté des configurations analytiques. Cependant, elle a constaté que les journaux NetScaler n’étaient pas envoyés. Une fois la commande show analyticsprofile <name> exécutée, en voyant Managementlog: NONE dans la sortie elle s’est rendu compte qu’elle avait oublié d’activer les journaux de gestion sur le profil d’analyse.

    Pour résoudre le problème, elle a donc activé les journaux de gestion à l’aide de set analytics profile <name> -managementlog ACCESS. Grâce à cette solution, elle a pu constater que les journaux étaient bien envoyés par NetScaler et que la commande show analyticsprofile <name> affichait Managementlog: ACCESS.

    Journal d'analyse Profile Management défini sur aucun

  2. Vérifiez si les journaux configurés sont bien générés localement. Par exemple, si vous avez configuré les journaux de gestion NSMGMT, vous pouvez vérifier si /var/log/ns.log affiche les journaux de gestion (lignes ne contenant pas « -PPE- ») générés.

  3. Vérifiez et confirmez les points suivants :

    • Si vous utilisez le profil approprié. Vous devez utiliser un profil de série chronologique
    • Si le service est résolu et opérationnel
    • Si les métadonnées (-analyticsEndpointMetadata) sont correctement configurées dans un fichier JSON valide et également si tous les champs qu’il contient sont présents dans les journaux exportés vers Splunk
    • Si le jeton d’authentification Splunk est approprié. Comme le jeton d’authentification n’est pas affiché, vous devez vous assurer qu’il est correctement saisi dans le format -analyticsAuthToken ‘Splunk <token>’
  4. Exécutez nstrace pour vérifier la présence d’anomalies dans le flux TCP ou HTTP. Vérifiez si le point de terminaison est configuré pour utiliser TLS ou SSL mais que NetScaler envoie des données non chiffrées ou inversement. Vous pouvez également vérifier si le fichier JSON exporté n’est pas correctement formaté.

Conseils de dépannage courants lorsque les journaux de gestion ne sont visibles sur aucun point de terminaison d’observabilité

Si les conseils fournis dans les sections Journaux de gestion non exportés vers le serveur syslog et Journaux de gestion non visibles sur Splunk (HEC) ne vous permettent pas de résoudre le problème, procédez comme suit :

  1. Consultez les fichiers journaux suivants relatifs au processus d’exportation des journaux de gestion. Les fichiers journaux suivants peuvent vous donner une idée du problème :

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

    Scénario : Cassidy, une administratrice système, a détecté des erreurs de rupture de tuyau dans export_mgmtlog_status.log et a constaté que le collecteur envoyait des réinitialisations en raison de problèmes de pare-feu, ayant été corrigés de son côté.

    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. Vérifiez si le fichier de configuration /nsconfig/mgmtlogcfg.json est correctement généré et s’il semble contenir une configuration Syslog ou JSON.

    Par exemple, lorsque syslog et JSON sont configurés, le fichier /nsconfig/mgmtlogcfg.jsonse présente comme indiqué ci-dessous. Le champ “syslog” confirme que syslog est configuré, tandis que le champ “json” confirme que json est configuré.

    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. Assurez-vous de consulter l’index et l’horodatage appropriés.

    Scénario

    Cassidy, une administratrice système, s’est rendu compte qu’elle avait configuré l’index syslog nommé ns-mgmt-log-syslog-index au lieu de ns-mgmt-log-json-index sur Splunk, ce qui a ensuite été rectifié.

    Affichage de l'index et du profil analytique appropriés

  4. Dans les déploiements de clusters, si les nœuds non CCO ne génèrent pas de journaux, essayez d’exécuter la commande force cluster sync.

  5. Profils réseau : il est également possible d’utiliser des profils réseau. Pour syslog, assurez-vous d’avoir défini « -netprofile » dans l’action syslog. Si vous équilibrez la charge des journaux syslog ou si vous les exportez au format JSON, assurez-vous d’avoir défini le profil réseau sur le service.

  6. Partitions : la fonctionnalité de journalisation de gestion n’est pas prise en charge pour les partitions autres que celles par défaut.

  7. Horodatages : les journaux de gestion générés par les processus sont exportés périodiquement. Par conséquent, l’heure à laquelle vous recevez le journal de gestion peut ne pas être la même que l’heure à laquelle il a été généré. En outre, le format de date peut ne pas être conforme à celui configuré dans l’action syslog, car la journalisation syslog de gestion suit le format RFC-5424.