Add ETW mapping to logs data model appendix

[swashtek]

Fixes #
Add ETW mapping to logs data model appendix

Changes

Please provide a brief description of the changes here.

For non-trivial changes, follow the change proposal process.

• Related issues #
• Related OTEP(s) #
• Links to the prototypes (when adding or changing features)
• CHANGELOG.md file updated for non-trivial changes
  • For trivial changes, include [chore] in the PR title to skip the changelog check
• Spec compliance matrix updated if necessary
• Declarative config data model is updated if SDK config surface is changed

comment addressed

[MrAlias]

This still claims the ETW level is preserved in Attributes["etw.level"], but the ETW receiver linked in the thread does not currently emit that attribute. In the level 0 and provider-defined/reserved cases, the receiver maps severity to unspecified or leaves severity unset, so downstream consumers cannot recover the original ETW level from the OTel record.

I think the fix should either drop the reversibility claim from this example or update the referenced implementation and tests to actually append etw.level. Otherwise the appendix documents behavior that the implementation does not provide.

[swashtek]

Great catch, I am adding the preserving change simultaneously, I intend to complete the below PR in receiver before merging spec document. I will keep this comment unresolved until then. Thanks.
open-telemetry/otel-arrow#3309

[tigrannajaryan]

Is there a reason this is not using Otel semconv for threads and processes for attributes (thread.id and process.pid)?

[utpilla]

We could definitely use process.pid.

However, we can't use thread.id here because the semconv definition for it says:

Current “managed” thread ID (as opposed to OS thread ID)

ETW is an OS/kernel facility. The thread ID it emits is the OS thread ID.

[reyang]

What if the event came from the kernel executive from IRQ? I guess there won't be process/thread?

[utpilla]

EVENT_HEADER always carries ThreadId and ProcessId (fixed ULONG fields). For some contexts (e.g. kernel/interrupt) the value may not correspond to a meaningful thread/process, but it's always present. So, our stance is to always emit whatever the header provides and let consumers interpret it.