Event Log <EventData> Tag

[cpatterson1]

We are using the standard config:

Code: Select all

# Windows Event Log
<Input eventlog>
# Uncomment im_msvistalog for Windows Vista/2008 and later
    Module im_msvistalog
 
# Uncomment im_mseventlog for Windows XP/2000/2003
#   Module im_mseventlog
</Input>
 
<Output out>
    Module om_tcp
    Host agc3-nagtest01.agc01.com
    Port 3515
	
    Exec  $tmpmessage = $Message; delete($Message); rename_field("tmpmessage","message");
    Exec  $raw_event = to_json();
	
	# Uncomment for debug output
	# Exec file_write('%ROOT%\data\nxlog_output.log', $raw_event + "\n");
</Output>

However, we have a need to capture information in the <EventData> tags of the event logs. For example, here is the XML from Event Logs:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="[Redacted]" />
<EventID Qualifiers="0">3000</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2015-12-17T16:03:21.000000000Z" />
<EventRecordID>76342606</EventRecordID>
<Channel>[Redacted]</Channel>
<Computer>[Redacted]</Computer>
<Security />
</System>
- <EventData>
<Data>Message Processor has stopped. No messages in queue</Data>
</EventData>
</Event>

And what we get in Nagios is the following:

@timestamp 2015-12-17T16:03:22.257Z
@version 1
Channel [Redacted]
EventID 3000
EventReceivedTime 2015-12-17 11:03:22
EventTime 2015-12-17 11:03:21
EventType INFO
Hostname [Redacted]
Keywords 36028797018963970
Opcode Info
ProcessID 0
RecordNumber 76342606
Severity INFO
SeverityValue 2
SourceModuleName eventlog
SourceModuleType im_msvistalog
SourceName [Redacted]
Task 0
ThreadID 0
_id AVGwrnk4A2CkGv1VCYQ2
_index logstash-2015.12.17
_type eventlog
host 10.2.10.148
type eventlog

Is it possible to get these tags captured as well?

[jolson]

This appears to be working for me.

2015-12-17 14_53_17-Dashboard • Nagios Log Server.png

The only notable difference between our systems could be:
1. Difference in nxlog versions
2. My logs using <Data Name=X> instead of <Data>

What version of nxlog are you running on your Windows box? Be sure it's the latest (2.9.1504). If you are on the latest version already, could you help point me to an event that doesn't have the <Data Name=x> parameter?

[cpatterson1]

We were a few minor versions behind (2.9.1347) so we updated, but it did not make a difference.

The biggest difference I notice is that your Data fields have parameter names whereas ours are dumping into a generic data tag. These are logs our developers have written, we are working to see if we can adjust these to name the data fields in hopes that they pull in.

[jolson]

That sounds like a good step forward. Let me know what you find out - thanks!

[cpatterson1]

Sorry for the slow response. We are up to the latest version (1.4.0) and are seeing the same behavior. We are going to attempt to work with our internal team to see if we can come up with a solution, however if you guys can come up with a reason that Nagios is not displaying the additional information it would be greatly appreciated.

[jolson]

The reason that something like this will not work:

Code: Select all

<EventData>
<Data>Message Processor has stopped. No messages in queue</Data>
</EventData>

is due to the fact that Nagios Log Server need to associate 'fields' with 'values'. Included in the above information is the value (Message Processor has stopped. No messages in queue) but no field name - therefore the fieldname would need to be made up (which can cause a host of other complications).

A properly formatted log:

Code: Select all

<EventData>
<Data Name="Some name">Message Processor has stopped. No messages in queue</Data>
</EventData>

That way Nagios Log Server knows to use the field "Some name" and associate it with the value of "Message Processor has stopped. No messages in queue".

[cpatterson1]

That's what I was afraid of...thanks for the assistance. Hopefully we can get that fixed on our end.

[rkennedy]

I'll leave this open - let us know if you need any further assistance.

[cpatterson1]

We were able to get this fixed on our end. It was an error in the Event Source that was causing this issue.

[tmcdonald]

I'll be closing this thread now, but feel free to open another if you need anything in the future!