NXLog User Guide

102. Resolving Common Issues

102.1. "Nxlog failed to start"

You may receive this error message in the log file when NXLog fails to start (line break added):

nxlog failed to start: Invalid keyword: ÿþ# at \
C:\Program Files (x86)\nxlog\conf\nxlog.conf:1

This issue occurs because the NXLog configuration file has been saved in either UTF-16 text encoding, or UTF-8 text encoding with a BOM header.

Open the configuration file in a text editor and save it using ASCII encoding or plain UTF-8.

Tip	On Windows, you can use Notepad to correct the text encoding of this file.

102.2. "Permission denied"

When configured to read from a file in the /var/log directory, NXLog may log the following error:

ERROR failed to open /var/log/messages;Permission denied

This error occurs because NXLog does not have permission to read the file with the configured User and Group). See Reading Rsyslog Log Files for more information about using NXLog to read from files in /var/log.

102.3. Log Entries are Concatenated with Logstash

If you are using Logstash and find that log entries are concatenated, make sure that you are using the json_lines codec in your Logstash server configuration.

The default json codec in Logstash sometimes fails to parse log entries passed from NXLog. Switch to the json_lines codec for better reliability.

102.4. Log File is in Use by Another Application

When trying to view the NXLog’s internal log file on Windows, you may receive an error message indicating that the log file is in use by another application and cannot be accessed.

To resolve this issue, either:

open the log file with an application that does not use exclusive locking (such as Notepad), or
stop NXLog before opening the log file.

102.5. "Connection refused" with im_tcp or im_ssl

When using the im_tcp and im_ssl modules to transfer data over the network, firewalls and other network issues can prevent successful connections. This can result in Connection refused errors.

To resolve this issue:

check that no firewall, gateway, or other network issue is blocking the connection; and
verify that the system can resolve the host name used in the Host directive of the configuration file.

102.6. "Missing logdata"

Sometimes NXLog will try to evaluate a directive, but the required log data is not available in the current context. This will cause any dependent operations to fail, the directive to terminate, and the following error to be logged:

missing logdata, assignment possibly after drop()

This error will occur when attempting to access a field, either:

after running the drop() procedure, or
from the Exec directive of a Schedule block.

In both cases, the log data is not available in the current context. Data from a dropped event is no longer available, and log data will never be available to a scheduled Exec directive, because its execution is not triggered by a log message.

An attempt to access a field can occur directly (with a field assignment) or indirectly (by calling a function or procedure that accesses log data).

Example 426. Assignment After drop()

With this configuration, NXLog drops the message if the $raw_event field matches the keyword. However, the next statement tries to access a field from the message, even though it may have been dropped.

nxlog.conf (Incorrect)


  1
2
3
4
5
6
7
8
9
10
11

  <Input in>
    Module  im_udp
    Port    514
    <Exec>
        if $raw_event =~ /keyword/
        {
            drop();
            $EventTime = now();
        }
    </Exec>
</Input>

If the message is not found, then the second statement fails and NXLog generates the following error:

missing logdata, assignment possibly after drop()

To resolve this issue, use a conditional statement to only reference fields that are available. Or use the dropped() function, which will return TRUE if the current event has already been dropped.

Example 427. Correctly Using drop()

This configuration only attempts to do the field assignment if the regular expression does not match.

nxlog.conf


  1
2
3
4
5
6
7
8
9
10

  <Input in>
    Module  im_udp
    Port    514
    <Exec>
        if $raw_event =~ /keyword/
            drop();
        else
            $EventTime = now();
    </Exec>
</Input>

102.7. Windows EventLog Error: "ignoring source"

When NXLog is set up to access the Windows EventLog, the permissions may not be sufficient. In this case, the NXLog log files show errors such as:

2013-01-10 13:43:30 WARNING ignoring source as it cannot be subscribed to (error code: 5)

If this occurs, use the wevutil utility to grant the new user access to the Windows EventLog. See this TechNet article for more details about the procedure: Giving Non Administrators permission to read Event Logs Windows 2003 and Windows 2008.

102.8. Processing Stops if an Output Fails

NXLog can send one log stream to multiple outputs. This can be configured by either using the same input in multiple routes or using multiple outputs in the same route (see Routes). By default, when one of the outputs fails NXLog will stop sending logs to all outputs. This is caused by NXLog’s flow control mechanism, which is designed to prevent messages from being lost. Flow control pauses an Input or Processor module when the next module in the route is not ready to accept data.

In some cases, it is preferred for NXLog to continue sending logs to the remaining active output and discard logs for the failed output. The simplest solution is to disable flow control. This can be done globally with the global FlowControl directive, or for the corresponding Input (and Processor, if any) modules only, with the module FlowControl directive. Note that with flow control disabled, an Input or Processor module will continue to process logs even if the next module’s buffers are full (and the logs will be dropped).

To retain the improved message durability provided by flow control, it is possible to instead explicitly specify when to drop logs by using a separate route for each output that may fail. Add a pm_buffer module instance to that route, and configure the buffer to drop logs when it reaches a certain size. The output that follows the buffer can fail without causing any Input or Processor module before the buffer to pause processing. See Using Buffers for examples.