NXlog CE Seems to be Dropping many messages related to Microsoft DNS Debug log.


#1 BenC

I have NXLog CE latest version monitoring both Windows Event Logs and the DNS Debug log file on Server 2012 R2 and sending to TCP GELF format to a Graylog server.

I'm seeing periodic significant discrepancies between the actual amount of logs generated vs the logs that are being sent and received in my central logging platform (Graylog). from 10,000 messages per minute to 150 messages per minute, when it happens. I have verified this by getting a local copy of the dnsdebug log and checking the amount of lives vs running a query for the same time period in Graylog.

I see this drops specifically against the DNS_Debug file not against the Windows EVTX file, they come through at a normal rate.

Does anyone see anything wrong with the configuration below?

Are there Debug sources for NXlog that can be reviewed to see if internal errors are being generated?

I'm also seeing NXlog send messages with blank short_message and full_message.

Example {"version":"1.1","_EventReceivedTime":"2018-08-16 16:36:51","_SourceModuleName":"DNS_Debug","_SourceModuleType":"im_file","host":"<Hostname>","short_message":"","full_message":"","timestamp":1534401411,"level":6}

This generates errors on the Graylog as well as an invalid input against a mandatory field in the GELF specification.

In terms of volume we're talking approximately 500,000 messages per 30mins.

Version : nxlog-ce-2.10.2102.msi

NB: We had to use [Exec $ShortMessage = $raw_event;] because by default the short_message field was coming through as 64 character truncated, which appears to be a default configuration.

Any help community would be greatly appreciated.

Next course of action is to set the internal logging to debug and check out what is happening.


Title: nxlog_winsrv

Version: 0.1

OS: Server 2012R2

For any concerns please contact [REDACTED]

#define ROOT C:\Program Files\nxlog define ROOT C:\Program Files (x86)\nxlog

Moduledir %ROOT%\modules CacheDir %ROOT%\data Pidfile %ROOT%\data\nxlog.pid SpoolDir %ROOT%\data LogFile %ROOT%\data\nxlog.log <Extension gelf> Module xm_gelf </Extension> <Extension _json> Module xm_json </Extension> <Input evtx_in> Module im_msvistalog Query <QueryList>
<Query Id="0">
<Select Path="Setup"></Select>
<Select Path="System">
</Select>
<Select Path="Security">*</Select>
</Query>
</QueryList> </Input> <Input dnsDebug_in> Module im_file File "C:\dns_debug.txt" SavePos TRUE Exec $ShortMessage = $raw_event; </Input>

<Output default_out> Module om_tcp Host [HOSTNAME} Port [Host_Port] OutputType GELF_TCP </Output>

<Route default_route> Path evtx_in, dnsDebug_in => default_out </Route>

#2 Zhengshi Nxlog ✓
#1 BenC
I have NXLog CE latest version monitoring both Windows Event Logs and the DNS Debug log file on Server 2012 R2 and sending to TCP GELF format to a Graylog server. I'm seeing periodic significant discrepancies between the actual amount of logs generated vs the logs that are being sent and received in my central logging platform (Graylog). from 10,000 messages per minute to 150 messages per minute, when it happens. I have verified this by getting a local copy of the dnsdebug log and checking the amount of lives vs running a query for the same time period in Graylog. I see this drops specifically against the DNS_Debug file not against the Windows EVTX file, they come through at a normal rate. Does anyone see anything wrong with the configuration below? Are there Debug sources for NXlog that can be reviewed to see if internal errors are being generated? I'm also seeing NXlog send messages with blank short_message and full_message. Example {"version":"1.1","_EventReceivedTime":"2018-08-16 16:36:51","_SourceModuleName":"DNS_Debug","_SourceModuleType":"im_file","host":"<Hostname>","short_message":"","full_message":"","timestamp":1534401411,"level":6} This generates errors on the Graylog as well as an invalid input against a mandatory field in the GELF specification. In terms of volume we're talking approximately 500,000 messages per 30mins. Version : nxlog-ce-2.10.2102.msi NB: We had to use [Exec $ShortMessage = $raw_event;] because by default the short_message field was coming through as 64 character truncated, which appears to be a default configuration. Any help community would be greatly appreciated. Next course of action is to set the internal logging to debug and check out what is happening. Title: nxlog_winsrv Version: 0.1 OS: Server 2012R2 For any concerns please contact [REDACTED] #define ROOT C:\Program Files\nxlog define ROOT C:\Program Files (x86)\nxlog Moduledir %ROOT%\modules CacheDir %ROOT%\data Pidfile %ROOT%\data\nxlog.pid SpoolDir %ROOT%\data LogFile %ROOT%\data\nxlog.log <Extension gelf> Module xm_gelf </Extension> <Extension _json> Module xm_json </Extension> <Input evtx_in> Module im_msvistalog Query <QueryList> <Query Id="0"> <Select Path="Setup"></Select> <Select Path="System"></Select> <Select Path="Security">*</Select> </Query> </QueryList> </Input> <Input dnsDebug_in> Module im_file File "C:\dns_debug.txt" SavePos TRUE Exec $ShortMessage = $raw_event; </Input> <Output default_out> Module om_tcp Host [HOSTNAME} Port [Host_Port] OutputType GELF_TCP </Output> <Route default_route> Path evtx_in, dnsDebug_in => default_out </Route>

Got a few things going on so will break it up a bit. :)

Are there Debug sources for NXlog that can be reviewed to see if internal errors are being generated?

Yes! Please use LogLevel DEBUG to enable debug logging. Note that this will produce a lot of output.
https://nxlog.co/docs/nxlog-ce/nxlog-reference-manual.html#config_global_loglevel

NB: We had to use [Exec $ShortMessage = $raw_event;] because by default the short_message field was coming through as 64 character truncated, which appears to be a default configuration.

64 is the default ShortMessageLength, though this can be adjusted. This field is a requirement of the GELF specifications. The fields being blank are another issue...
https://nxlog.co/docs/nxlog-ce/nxlog-reference-manual.html#xm_gelf_config

Blank fields/missing entries.
I am a big fan of adding om_file and a new route when troubleshooting. I would write output to a temporary file and compare it against the input or graylog.
You can also use something like exec log_info($raw_event); to print as the events are being processed if you want, though depending on number of events, the om_file is probably better option for you.