Audit logging

Last published : Sep 24, 2026
Important
We recommend you to update a SYSLOG or NSLOG configuration only during maintenance or downtime. If you update a configuration after creating a session, the changes are not applied to the existing session logs.
Auditing is a methodical examination or review of a condition or situation. The audit logging feature enables you to log NetScaler states and status information collected by various modules. The log information can be in the kernel and in the user-level daemons.
You can configure NetScaler to store the log information locally on NetScaler or export it to a remote server or both.

Local logging

Local logging refers to the process of storing the event data generated by NetScaler such as, errors, warnings, and system events, locally within NetScaler. This data can be used for monitoring and troubleshooting, auditing, and security analysis.
By default, NetScaler saves its logs locally in NetScaler persistent storage using the UDP protocol. The logs are stored in the ns.log file under the /var/log/ folder. Since local logging is enabled by default, you don't need to perform any additional configurations to store the logs.
Local logging provides the following advantages:
  • Accessibility: You can access the logs even if there are network issues. The logs can be accessed quickly because they are not dependent on network connections.
  • Security: The sensitive or confidential data remains within NetScaler and therefore reduces the risk of unauthorised access.
  • Compliance: Many regulatory requirements mandate the retention of log data for a certain period. So, by storing logs locally NetScaler ensures that it is compliant.

Log levels

In NetScaler, log levels categorize the severity and type of log messages generated. These levels help administrators filter and prioritize logs for monitoring, troubleshooting, and auditing. Below are the log levels supported by NetScaler:
  • ALERT - Requires immediate action to prevent further issues. These are high-priority messages.
  • CRITICAL - Indicates a critical condition that might affect the system's functionality.
  • EMERGENCY - Indicates a critical system failure that requires immediate attention. The system is likely unusable.
  • ERROR - Logs errors that have occurred but do not necessarily require immediate action.
  • INFORMATIONAL - The informational logs provide general information about NetScaler.
  • NOTICE - Provides informational messages about normal but significant events.
  • WARNING - Indicates potential issues or situations that could lead to problems if not addressed.
  • DEBUG - The debug logs provide detailed information for troubleshooting.
  • ALL - Includes all log levels except DEBUG.
  • NONE - Does not contain any log details.
Note:
Starting from NetScaler release 14.1-47.x onwards, DEBUG log level is removed from local syslog. The ALL option does not include DEBUG log level. If you want to enable DEBUG explicitly, you can use the following hidden option in the CLI: set syslogparams -loglevel -debug.
Enabling the DEBUG log level is not persistent across reboots and therefore the setting is lost after a system restart. You must re-enable the DEBUG log level manually if needed.
By default, all log levels are enabled except DEBUG. However, you can adjust the levels of logs stored in the ns.log file.
Warning
If you configure local logging for many features or set log level to store less severe logs, then the stability and performance of NetScaler might be impacted. We strongly recommend to avoid using local logging extensively. Instead, use remote logging if verbose logging is required.
To modify the default log setting, use the following command:
set syslogparams -acl ( ENABLED | DISABLED )
        -alg ( ENABLED | DISABLED )
        -appflowExport ( ENABLED | DISABLED )
        -ContentInspectionLog ( ENABLED | DISABLED )
        -dateFormat <dateFormat>
        -dns ( ENABLED | DISABLED )
        -logFacility <logFacility>
        -logLevel <logLevel> ...
        -lsn ( ENABLED | DISABLED )
        -serverIP <ip_addr|ipv6_addr|*>
        -serverPort <port>
        -sslInterception ( ENABLED | DISABLED )
        -subscriberLog ( ENABLED | DISABLED )
        -tcp ( NONE | ALL )
        -timeZone ( GMT_TIME | LOCAL_TIME )
        -urlFiltering ( ENABLED | DISABLED )
        -userDefinedAuditlog ( YES | NO )
Local logging has the following disadvantages:
  • Performance impact - Logging activities can consume system resources that can potentially impact the performance and stability of NetScaler.
  • Storage: NetScaler can store only a limited amount of log data since the local storage capacity is low compared to centralized storage.
  • Scalability - Not suitable for large-scale deployments. In large-scale deployments, centralized logging solutions are preferred for easier management and scalability.
    • Compliance challenges in large scale deployments - Many industries have regulations and compliance requirements regarding log management and retention. Managing compliance becomes more complex when logs are stored locally, as it requires ensuring that each device adheres to the necessary standards.
  • Accessibility in large scale network - Accessing logs stored locally on NetScaler might require direct access to the device. This becomes inconvenient in large networks because accessing logs from multiple devices that are distributed across a network is cumbersome.
  • Single point of failure - If there is a hardware malfunction, any logs stored locally becomes inaccessible. This creates a single point of failure for logging data, potentially leading to loss of valuable information.

Remote logging

NetScaler allows you to store the log information on an external server. You can configure NetScaler to export the logs to the external server using UDP or TCP. Depending on your requirements, you can either store the log information locally or export it to an external server, or both. For detailed information on remote logging and how to configure remote logging, see Configuring NetScaler for audit logging.

SYSLOG and NSLOG

For audit logging, you can use the SYSLOG protocol, the native NSLOG protocol, or both.
SYSLOG is a standard protocol for logging. It has two components:
  • SYSLOG auditing module: Runs on NetScaler.
  • SYSLOG server: Runs on the underlying FreeBSD operating system (OS) of NetScaler or on a remote system.
SYSLOG uses a user data protocol (UDP) for data transfer.
Similarly, the native NSLOG protocol has two components:
  • NSLOG auditing module: Runs on NetScaler.
  • NSLOG server: Runs on the underlying FreeBSD OS of NetScaler or on a remote system.
NSLOG uses TCP for data transfer.
When you run a SYSLOG or NSLOG server, it connects to NetScaler. NetScaler then starts sending all the log information to the SYSLOG or NSLOG server. And the server filters the log entries before storing them in a log file. An NSLOG or SYSLOG server receives log information from more than one NetScaler. NetScaler sends log information to more than one SYSLOG server or NSLOG server.
If multiple SYSLOG servers are configured, NetScaler sends its SYSLOG events and messages to all the configured external log servers. It results in storing redundant messages and makes monitoring difficult for system administrators. To address this issue, NetScaler offers load balancing algorithms. NetScaler can load balance the SYSLOG messages among the external log servers for better maintenance and performance. The supported load balancing algorithms include RoundRobin, LeastBandwidth, CustomLoad, LeastPackets, and AuditlogHash.
Note
NetScaler can send audit log messages up to 16 KB to an external SYSLOG server.
The log information that a SYSLOG or NSLOG server collects from a NetScaler is stored in a log file in the form of messages. These messages typically contain the following information:
  • The IP address of NetScaler that generated the log message.
  • A time stamp
  • The message type
  • The predefined log levels (Critical, Error, Notice, Warning, Informational, Debug, Alert, and Emergency)
  • The message information
To configure audit logging, you first configure the audit modules on NetScaler. NetScaler involves creating audit policies and specifying the NSLOG server or SYSLOG server information. You then install and configure the SYSLOG or the NSLOG server on the underlying FreeBSD OS of NetScaler or on a remote system.
Note
SYSLOG is an industry standard for logging program messages, and various vendors provide support. The documentation does not include SYSLOG server configuration information.
The NSLOG server has its own configuration file (auditlog.conf). You can customize logging on the NSLOG server system by making extra modifications to the configuration file (auditlog.conf).
Note
ICMP access to SYSLOG server is mandatory if SYSLOG server is used as FQDN under SYSLOG Action in the network. If ICMP access is blocked in the environment, configure it as load balanced SYSLOG server and set the value of the healthMonitor parameter in the set service command to NO. For configuring ICMP, see Load balancing SYSLOG messages across external log servers