5
responses
responses
cybergoof
The article on structured logging (https://nxlog.co/why-use-structured-logging) shows how you should use structured logging so that changes in log format is minimized. The example of the sysmon event, process creates, shows what I think is a bug in NXLog.
The ProcessID in the "Message" is the ProcessID (25848) of the new process that sysmon sees created. However, in the structured NXLog key/values, the ProcessID is that of sysmon itself (1680)
The only way to get the ProcessID of the process sysmon observed created, is to use regular expressions. Can you verify that this is a bug in NXLog?
Comments (4)
But, in sysmon, the desired ProcessID is in the <EventData> key. In the JSON created by NXLOG, if they were created under a "EventData":{} object. This would solve the namespace collision problem.
NXLog stores the data internally in a flat list of key-value pairs, not JSON. Nested values are not supported (i.e. such structure needs to be flattened). Having support for such complex structure would have some benefits and would also bring some more problems with the added complexity.
Thanks for the response. I would suggest making this a future feature. It seems elastic.co's new BEATS log forwarder handles the sysmon ProcessID correctly.
Is it conceivable that to avoid naming conflicts all newly in the message field captured names could get a (configurable) prefix (for example prefix "Message." like "Message.ProcessId" or prefix "EventData." like "EventData.ProcessId")?