[receiver/k8seventsreceiver] Labels and attributes extraction from event metadata

[gmlexx]

Component(s)

receiver/k8sevents

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

We store involved object generation as an event annotation, so we need to extract it when receiving events.

Describe the solution you'd like

Here is a PR solving this issue, so creating this issue for reference in the changelog

#39495

Describe alternatives you've considered

We tried k8sobjects receiver initially, but it didn't work well with events for us, had multiple empty fields in the stored object

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/k8sevents: @dmitryax @TylerHelmuth @ChrsMark

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

[odubajDT]

Not sure if new features should be added to this receiver, since a deprecation ticket is opened here. Leaving this decisions on code owners

[gmlexx]

Not sure if new features should be added to this receiver, since a deprecation ticket is opened here. Leaving this decisions on code owners

Thanks for heads-up @odubajDT, we tried this receiver initially, but it didn't work well with events for us, had multiple empty fields in the stored object, so this receiver works perfectly.

[ChrsMark]

Apart from discussing the deprecation thing (I don't have an answer for this :)) we should also discuss and agree on the schema that these attributes will potentially follow (ref). Probably these would need to be part of SemConv as well as it was done for K8s Node's labels/annotations etc.

[gmlexx]

@ChrsMark is the absence of these fields in SemConv a real blocker? I wonder what exactly should be done to proceed.

[ChrsMark]

@ChrsMark is the absence of these fields in SemConv a real blocker? I wonder what exactly should be done to proceed.

Usually we request covering the SemConv part prior to introducing any new attributes in the Collector, specially for the k8s components.

This is to ensure alignment in definitions and avoid future breaking changes.

[gmlexx]

Hi @ChrsMark we would like to move this forward, could you elaborate on covering the SemConv part, please if this is the main blocker now?

[ChrsMark]

@gmlexx I think the main blocker is that the component is probably about to be deprecated as mentioned already: #24242