[windowseventlogreceiver] EventData is not extracted correctly #24493
Comments
sumo-drosiek
added
bug
|
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
cc: @swiatekm-sumo as he modified this part of code recently |
|
This was changed to the current state on the assumption that all built-in events have named |
|
Can we use empty |
We can, but if there's more than one entry, we'll only keep the last one. In that case, I think we should have a different data structure here. |
|
Here is my original comment on this.
Should we try the slice of maps approach? |
I think it is reasonable. However it sounds like breaking change |
|
Pinging code owners for pkg/stanza: @djaglowski. See Adding Labels via Comments if you do not have permissions to add labels yourself. |
…in EventXML (Windows) (#28587) **Description:** The [XML schema for Windows events supports `Data` elements without the `Name` attribute](https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-datafieldtype-complextype), however, the current implementation doesn't capture `Data` elements without the `Name` attribute. Capturing such elements is specially important for events for which the publisher metadata is invalid. These elements contain the data that will give a user a much better chance of actually understanding the event, see [here](#21491 (comment)) for an example. I'm adding also the optional `Binary` element. Although this element typically requires knowledge of the actual data type it is representing sometimes it can be useful together with the data elements. I consider this to be a breaking change because it modifies the layout of the event generated by the package. It isn't an addition, the old representation is changed, please refer to the changes in tests to see the difference. **Link to tracking Issue:** This is the last pending item to fix #24493, #21491 ([item 5](#21491)). **Testing:** - Local run of the affected receiver and package - "Run Windows" on my fork **Documentation:** N/A --------- Co-authored-by: Daniel Jaglowski <jaglows3@gmail.com>
…in EventXML (Windows) (open-telemetry#28587) **Description:** The [XML schema for Windows events supports `Data` elements without the `Name` attribute](https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-datafieldtype-complextype), however, the current implementation doesn't capture `Data` elements without the `Name` attribute. Capturing such elements is specially important for events for which the publisher metadata is invalid. These elements contain the data that will give a user a much better chance of actually understanding the event, see [here](open-telemetry#21491 (comment)) for an example. I'm adding also the optional `Binary` element. Although this element typically requires knowledge of the actual data type it is representing sometimes it can be useful together with the data elements. I consider this to be a breaking change because it modifies the layout of the event generated by the package. It isn't an addition, the old representation is changed, please refer to the changes in tests to see the difference. **Link to tracking Issue:** This is the last pending item to fix open-telemetry#24493, open-telemetry#21491 ([item 5](open-telemetry#21491)). **Testing:** - Local run of the affected receiver and package - "Run Windows" on my fork **Documentation:** N/A --------- Co-authored-by: Daniel Jaglowski <jaglows3@gmail.com>
…in EventXML (Windows) (open-telemetry#28587) **Description:** The [XML schema for Windows events supports `Data` elements without the `Name` attribute](https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-datafieldtype-complextype), however, the current implementation doesn't capture `Data` elements without the `Name` attribute. Capturing such elements is specially important for events for which the publisher metadata is invalid. These elements contain the data that will give a user a much better chance of actually understanding the event, see [here](open-telemetry#21491 (comment)) for an example. I'm adding also the optional `Binary` element. Although this element typically requires knowledge of the actual data type it is representing sometimes it can be useful together with the data elements. I consider this to be a breaking change because it modifies the layout of the event generated by the package. It isn't an addition, the old representation is changed, please refer to the changes in tests to see the difference. **Link to tracking Issue:** This is the last pending item to fix open-telemetry#24493, open-telemetry#21491 ([item 5](open-telemetry#21491)). **Testing:** - Local run of the affected receiver and package - "Run Windows" on my fork **Documentation:** N/A --------- Co-authored-by: Daniel Jaglowski <jaglows3@gmail.com>
Component(s)
pkg/stanza
What happened?
Description
EventData from the following xml is omitted:
This is probably due to this part of code:
opentelemetry-collector-contrib/pkg/stanza/operator/input/windows/xml.go
Lines 145 to 147 in 13ff018
Steps to Reproduce
I'm running Sumo Logic Distribution for OpenTelemetry Collector as Windows service
Expected Result
"event_data"containing dataActual Result
Collector version
v0.81.0
Environment information
Environment
OS: (e.g., "Ubuntu 20.04")
Compiler(if manually compiled): (e.g., "go 14.2")
OpenTelemetry Collector configuration
No response
Log output
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: