[receiver/k8seventsreceiver] add extraction rules for labels and annotations #39495
Conversation
gmlexx
requested review from
dmitryax,
TylerHelmuth,
ChrsMark and
a team
as code owners
|
|
gmlexx
changed the title
gmlexx
force-pushed
the
k8s-events-receiver-extraction-rules
branch
from
e002bf3 to
4e7c2dd
Compare
gmlexx
force-pushed
the
k8s-events-receiver-extraction-rules
branch
3 times, most recently
from
93020e1 to
13f0d6f
Compare
| for _, opt := range allOptions { | ||
| if err := opt(kr); err != nil { | ||
| kr.settings.Logger.Error("Could not apply option", zap.Error(err)) | ||
| componentstatus.ReportStatus(host, componentstatus.NewFatalErrorEvent(err)) |
There was a problem hiding this comment.
I believe that yes, as the incorrect configuration shouldn't be executed as it's hard to catch later just from logs error reporting, better to fail immediately
| extract: | ||
| annotations: # same can be applied for labels | ||
| - tag_name: a1 # extracts value of annotation from event with key `annotation-one` and inserts it as a tag with key `a1` | ||
| key: annotation-one |
There was a problem hiding this comment.
Can we add a sample produced log as an example here? My concern is mostly about how these will be represented and under which fields of the Log 🤔 .
There was a problem hiding this comment.
THB, I don't know how as there is no produced log example exist for this receiver to add new attributes to this set.
Is there a good example to follow?
| @@ -149,6 +151,8 @@ func getEvent() *corev1.Event { | |||
| Name: "1", | |||
| Namespace: "test", | |||
| CreationTimestamp: v1.Now(), | |||
| Labels: make(map[string]string), | |||
There was a problem hiding this comment.
Shall we add some tests that will also illustrate what type of data this feature produces?
There was a problem hiding this comment.
Sure, added TestEventLabelsAndAnnotationsExtractionOptions test
| lr := rl.ScopeLogs().At(0) | ||
| attrs := lr.LogRecords().At(0).Attributes() | ||
|
|
||
| attr, ok := attrs.Get("k8s.event.labels.testlabel") |
There was a problem hiding this comment.
We will need to discuss and decide if k8s.event.label/annotation is the proper place for this. If so, I guess we would need to define those as Semantic Conventions.
There was a problem hiding this comment.
We were planning to deprecate this receiver in favor of the k8sobjectsreceiver (#24242). If the semconv is willing to define semantic conventions for k8s events we could consider reversing that decision, but my understanding if that we are no longer in the business of defining semconv for log attributes and are instead supposed to follow Otel's Event spec.
There was a problem hiding this comment.
I think focusing on #24242 first would be ideal. It would not worth it adding stuff for k8sevents receiver if it's to get deprecated.
gmlexx
force-pushed
the
k8s-events-receiver-extraction-rules
branch
from
f60b2e7 to
18cebbb
Compare
…tations Inspired by k8sattributesprocessor introduces the similar configuration syntax to support labels and annotations extraction from event
gmlexx
force-pushed
the
k8s-events-receiver-extraction-rules
branch
from
18cebbb to
af46ffd
Compare
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Inspired by k8sattributesprocessor introduce the similar configuration syntax to support labels and annotations extraction from event
Testing
Documentation