[reciever/windowseventlog] Parse additional fields

[BinaryFissionGames]

Component(s)

receiver/windowseventlog

Is your feature request related to a problem? Please describe.

There are additional fields on the windows event XML schema that are useful to users, but we don't collect into the structured output of the receiver. It would be good to capture some of these fields.

Describe the solution you'd like

Add the following fields to the parsed output of the windows event log receiver:

1. Security (see: SystemPropertiesType Schema)
   a. This field may contain the UserID of the user that triggered the action, which would be useful for auditing purposes
2. Execution (see: SystemPropertiesType Schema)
   a. This field gives useful information about the process that triggered the event log when present.

Additionally, it'd be useful to scrape the UserData field. Unfortunately, the schema here is more free-form, which makes it more difficult to map to the key:value structure we have.

One idea could be some recursive structure like:

{
  tag: string
  attributes: map[string]string
  charData: string
  children: []XmlElement 
}: XMLElement

A structure like this could properly represent arbitrary XML, I believe.

Another idea would be to just keep the original XML for this field and store it on the log as unparsed text.

---

I have also considered adding the xml namespaces (the xmlns attribute on the root tag) as an additional field, but it seems like this tag is always the same and doesn't seem to really add any information to a parsed log.

Describe alternatives you've considered

One alternative idea would be to use the raw flag, in addition to some XML parsing step. Currently, I don't think there's an XML parser operator, or a converter for OTTL, and I think that could lead to an "unwieldy" representation of the log.

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/windowseventlog: @djaglowski @armstrmi @pjanotti

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[djaglowski]

@pjanotti, any recommendations on this? Thanks.

[pjanotti]

@djaglowski we should add the 2 properties mentioned by @BinaryFissionGames. Since they are structured it should be simple to add them. The event data is typically more useful if the publisher metadata is missing, if the metadata is available its contents are typically rendered in the message text. I will start with the 2 mentioned here since they look more straightforward to implement and will look at the event data later.

[BinaryFissionGames]

@pjanotti I can take on adding these properties, if it's something you won't be getting to soon.

[pjanotti]

@BinaryFissionGames please, go ahead and add these properties. There is always more stuff to do ;)

[BinaryFissionGames]

@pjanotti Threw up a PR for Execution and Security, when you're ready to take a look.

I did try sketching out a solution for UserData here, which is what I outlined above; Not sure how much I like the resultant structure, but also not sure how else to map XML -> JSON without potential key collisions.
https://github.com/observIQ/opentelemetry-collector-contrib/compare/c72e2ed..observIQ:opentelemetry-collector-contrib:feat/windows-evlog/userdata-parsing?expand=1

[pjanotti]

@BinaryFissionGames I didn't look yet at your sketch for UserData. I'm going to open a PR to collect EventData even if the Name attribute is not present. I will take a look at you proposal for UserData after that.

[BinaryFissionGames]

I opened #28621 as a draft PR so that the UserData stuff is easier to comment on when you get around to taking a look.

[BinaryFissionGames]

@pjanotti Any chance you'll be able to take a look at #28621 soon? Even just high-level feedback on the structure (if there's a better way to represent it) would be much appreciated!

[pjanotti]

Hi @BinaryFissionGames - sorry, I have been pretty busy. I can take a look next Monday. Please, ping me if I don't! ✅ Done.

[pjanotti]

A general assumption on my part is that even if we are capturing the rendered message we still want to capture the structured XML data. Here is what I mean: if the provider manifest is properly installed we current capture the message for an event with UserData, e.g: Starting session 1 - ‎2023‎-‎11‎-‎03T15:24:28.469392300Z.. However, we still want to capture the structured XML Data so it becomes easier to query and independent of the message (especially regarding the fact that the message can be localized). XML corresponding to the event above:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
  <Provider Name="Microsoft-Windows-RestartManager" Guid="{0888e5ef-9b98-4695-979d-e92ce4247224}" /> 
  <EventID>10000</EventID> 
  <Version>0</Version> 
  <Level>4</Level> 
  <Task>0</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2023-11-03T15:24:28.4700739Z" /> 
  <EventRecordID>404448</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="35952" ThreadID="27360" /> 
  <Channel>Application</Channel> 
  <Computer>MyComputer</Computer> 
  <Security UserID="S-1-5-XXXXXXXXXXXXXXXXXXX" /> 
  </System>
  <UserData>
   <RmSessionEvent xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/">
     <RmSessionId>1</RmSessionId> 
     <UTCStartTime>2023-11-03T15:24:28.4693923Z</UTCStartTime> 
    </RmSessionEvent>
   </UserData>
</Event>

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/windowseventlog: @djaglowski @armstrmi @pjanotti

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.