While NXLog is a tool for processing log data from other systems, it will also generate log messages about its own operations. These messages are essential for troubleshooting problems, and should be checked first if NXLog is not functioning as expected.
Internal logs are written to the file set by the LogFile directive. If this directive is not specified in the configuration, add it to enable logging to file.
|Some Windows applications (WordPad, for example) cannot open the log file while the NXLog process is running because of exclusive file locking. Use a viewer that does not lock the file, like Notepad.|
By default, internal logs are generated with a log level of INFO. To get more detailed information about NXLog’s operations, set the LogLevel directive to DEBUG. Because this can produce an extreme amount of logs, you should only enable this for troubleshooting.
NXLog can also write internal log data into a normal route using the im_internal module. Internal log messages can then be forwarded like any other log source.
|Local logging is more fault-tolerant than routed logging, and is therefore recommended for troubleshooting.|
|It is not possible to use a log level higher than INFO with the im_internal module. DEBUG level messages can only be written to the local log file.|
When running in the foreground, NXLog prints internal logs to the standard output and standard error streams, which are both visible in the terminal.
nxlog -f to run NXLog in the foreground.
It may be helpful to add extra logging statements to your configuration using the log_info() procedure. Anything that is printed with log_info() or related procedures will appear in the configured log file, on the standard output and standard error streams, and in the im_internal log source (DEBUG level messages are not available via the im_internal module).
In this example, log messages are accepted over UDP on port 514. If "keyword" is found in the unparsed message, an INFO level message will be generated.