You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 25, 2022. It is now read-only.
Describe the bug
Using the windows input operator, it has been noticed that with the introduction of Windows 2022, it has recently failed to receive some of the fields in a windows event log. Particularly level, message, opcode, keywords, etc. What appears to be the issue is that the input operator is attempting to parse out the XML format with a header of RenderingInfo. Unfortunately that RenderingInfo header only applies to events that have been collected by the Windows Event Collector, otherwise it simply does not exist in the XML of the log. For some unknown reason, it does not have this effect on previous versions of Windows server. Nonetheless, versions of this cannot be viewed.
Steps to reproduce
Setup Input operator to read from applications channel in windows event log
Send an event log to the windows event log
attempt to read the newly sent logs using the windows Input operator
What did you expect to see?
I expected to see the full response of the windows event log, including all fields included in this xml format which is specified here
// EventXML is the rendered xml of an event.
type EventXML struct {
EventID EventID `xml:"System>EventID"`
Provider Provider `xml:"System>Provider"`
Computer string `xml:"System>Computer"`
Channel string `xml:"System>Channel"`
RecordID uint64 `xml:"System>EventRecordID"`
TimeCreated TimeCreated `xml:"System>TimeCreated"`
Message string `xml:"RenderingInfo>Message"`
Level string `xml:"RenderingInfo>Level"`
Task string `xml:"RenderingInfo>Task"`
Opcode string `xml:"RenderingInfo>Opcode"`
Keywords []string `xml:"RenderingInfo>Keywords>Keyword"`
}
Proposed Fix
The intended fix for this issue is to change the field header RenderingInfo and instead will be parsing from the EventData header field. As shown in fluentd mapping you can see that is the field they are using to parse out message data from. You can also see in the windows event log itself, that the RenderingInfo field does not exist unless it calls upon the service
Describe the bug
Using the
windows input operator
, it has been noticed that with the introduction of Windows 2022, it has recently failed to receive some of the fields in a windows event log. Particularlylevel
,message
,opcode
,keywords
, etc. What appears to be the issue is that the input operator is attempting to parse out the XML format with a header ofRenderingInfo
. Unfortunately thatRenderingInfo
header only applies to events that have been collected by the Windows Event Collector, otherwise it simply does not exist in theXML
of the log. For some unknown reason, it does not have this effect on previous versions of Windows server. Nonetheless, versions of this cannot be viewed.Steps to reproduce
applications
channel in windows event logWhat did you expect to see?
I expected to see the full response of the windows event log, including all fields included in this xml format which is specified here
What did you see instead?
Input operator failed to retrieve
message
,level
,opcode
, andkeywords
What version did you use?
Version: v0.29.1
What config did you use?
Config is based upon the logs receiver that was attempted to be added to collector-contrib here
Config:
Environment
OS: (Windows 2022)
Compiler(if manually compiled): (go1.18 windows/amd64)
Proposed Fix
The intended fix for this issue is to change the field header
RenderingInfo
and instead will be parsing from theEventData
header field. As shown in fluentd mapping you can see that is the field they are using to parse out message data from. You can also see in the windows event log itself, that theRenderingInfo
field does not exist unless it calls upon the serviceTherefore, it makes sense to switch the xml header from
RenderingInfo
toEventData
Additional context
This issue is currently blocking an additional PR that implements this input operator as a logs receiver here
The text was updated successfully, but these errors were encountered: