[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.