(feat) Set context and body for log records emitted by instrumentation

[gfoidl]

Which problem is this PR solving?

From Grafana:

There's no body in the log records, so it's hard to spot which instrumenation emitted the log. This is only seeable in the details.

Short description of the changes

Type of change

The body is set on the emitted log records, as well the context.active() set, so that there's a potential link to traces in order to make observability more seamless.

With this change it looks in Grafana like

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

---

An alternative to this PR could be using a transformer in the OTel-collector, but this is not very user-friendly.
Also when the setup doesn't use OTel-collector the logs will look empty again.

How Has This Been Tested?

Added assertions to the unit tests, and manual verification.

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[martinkuba]

Thanks for putting this together!

Regarding body -
I understand the reasoning for adding description to the body. Your proposal is technically allowed by the events semconv - bodies can be a string display message of the event. However, there is currently no precedent for this, and I would like to run this by the sem conv SIG first.

My hesitation is also about layer and scope -
The display string is fully derivable from event name and attributes, so this feels like presentation logic in the producer. I understand that the collector route isn't user-friendly, but baking a specific phrasing into the instrumentations locks everyone into it. At the very least, this should be captured as part of the event's semantic conventions (similar to span names).

I'll open an issue in semantic-conventions to discuss the body question more broadly. Since there's no precedent or guidance on this, I think it's worth getting an answer there before any instrumentation adopts a pattern. I'll link it back here once it's up, and would love your input in that discussion.

Regarding context -
The Logs SDK is already using active context by default.

The reason these events are not associated with spans is that their callsites (window error handler, PerformanceObserver, history wrappers, DOM listeners) all fire from the platform when there is no active span. The only time the active context will work is for events emitted from wrapped callbacks (e.g. for the xhr/fetch instrumentations).

If you have a specific use case in mind for linking events to span context, please open an issue and we can discuss it there.

[gfoidl]

Thanks for your coherent insight -- makes all sense, and also thanks for putting this to the SIG!

ad context: uh, I really missed that part from reading the coce, so this should be removed from this PR.