[receiver/k8seventsreceiver] Support for semantic attributes #14474

povilasv · 2022-09-26T10:56:33Z

Describe the issue you're reporting

Would be cool to make some refactorings in k8s event receiver :)

One thing I was thinking about is parsing involvedObject to Kubernetes Resource Attributes using https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/k8s.md

For example, this Event:

- apiVersion: v1
  count: 1
  eventTime: null
  firstTimestamp: "2022-09-26T10:42:38Z"
  involvedObject:
    apiVersion: apps/v1
    kind: Deployment
    name: opentelemetry-collector
    namespace: sys-mon
    resourceVersion: "15905558"
    uid: f875e269-0e76-4735-a02d-a254ed056111
  kind: Event
  lastTimestamp: "2022-09-26T10:42:38Z"
  message: Scaled down replica set opentelemetry-collector-55c485d665 to 0
  metadata:
    creationTimestamp: "2022-09-26T10:42:38Z"
    name: opentelemetry-collector.1718630a415e713e
    namespace: sys-mon
    resourceVersion: "15905574"
    uid: 5b8fc5bb-3f64-47a5-bf21-d02f45377af5
  reason: ScalingReplicaSet
  reportingComponent: ""
  reportingInstance: ""
  source:
    component: deployment-controller
  type: Normal

Would end up with the following Resource attributes:

k8s.deployment.name =   opentelemetry-collector
k8s.deployment.id = f875e269-0e76-4735-a02d-a254ed056111
k8s.namespace.name =  sys-mon

Also, currently namespace is in Log attribute, not Resource -> https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/k8seventsreceiver/k8s_event_to_logdata.go#L77-L85

So I would like to move that to Resource :)

Thoughts @dmitryax ? :)

The text was updated successfully, but these errors were encountered:

github-actions · 2022-09-26T19:19:16Z

Pinging code owners: @dmitryax. See Adding Labels via Comments if you do not have permissions to add labels yourself.

povilasv · 2022-09-30T09:47:46Z

Related to this we also can support the new Event semantic conventions -> https://github.com/open-telemetry/opentelemetry-specification/blob/main/semantic_conventions/logs/events.yaml

Example draft PR: #14603

What I'm not sure about is the uniqueness of the event.Name, Kubernetes states (https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#ObjectMeta):

// Name must be unique within a namespace. Is required when creating resources, although
// some resources may allow a client to request the generation of an appropriate name
// automatically. Name is primarily intended for creation idempotence and configuration
// definition.

So to make it unique we need to add the namespace in? We could use that in event.domain, but it seems that needs to be k8s based on this file https://github.com/open-telemetry/opentelemetry-specification/blob/main/semantic_conventions/logs/events.yaml#L18-L27 ?

And so we are conflicting with https://github.com/open-telemetry/oteps/blob/main/text/0202-events-and-logs-api.md#events-structure as Event name is not unique?

All Events will have a name and a domain. The name is MANDATORY. The domain will serve as a mechanism to avoid conflicts with event names and is OPTIONAL. With this structure, an event name will be unique only in the context of a domain.

Maybe I'm misunderstanding something? Maybe @scheler you can give some insights?

Aaand @dmitryax what do you think ?

scheler · 2022-09-30T16:35:22Z

@povilasv I will work on modifying the spec language to allow for this. The attribute event.domain is only meant to be a logical separation across different event systems, so it allows for similar looking names in different domains but with a completely different purpose. However, within each domain we don't have to have any uniqueness constraints but leave it to whatever is idiomatic to the particular event system the domain represents.

Separately, I've a question on Kubernetes Events for my understanding - is the namespace+name combination unique across clusters? that is, (cluster+namespace+name) is unique and not just (namespace+name)?

This came up in open-telemetry/opentelemetry-collector-contrib#14474 where it was highlighted that just `name` is not sufficient to provide for uniqueness of a Kubernetes Event. The attribute `event.domain` is only meant to be a logical separation across different event systems, so it allows for similar looking names in different domains but with a completely different purpose. However, within each domain we don't have to have any uniqueness constraints on the `name` and leave it to whatever is idiomatic to the particular event system the domain represents.

jack-berg · 2022-10-03T16:33:34Z

Which kubernetes field are is proposed to be mapped to event.name?

scheler · 2022-10-03T22:20:38Z

@jack-berg The PR associated with this issue is mapping the Kubernetes Event's name to event.name.

povilasv · 2022-10-04T12:46:35Z

Yes the proposal is to use Kubernetes Event.Name for event.name attribute and event.domain to be k8s.

A couple of examples of K8s events:

- apiVersion: v1
  count: 1
  eventTime: null
  firstTimestamp: "2022-10-04T12:35:00Z"
  involvedObject:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
    namespace: sys-mon
    resourceVersion: "16998364"
    uid: 03194d84-89ba-433a-92f6-8d902e17493d
  kind: Event
  lastTimestamp: "2022-10-04T12:35:00Z"
  message: Scaled up replica set nginx-deployment-68d7dcf58 to 2
  metadata:
    creationTimestamp: "2022-10-04T12:35:00Z"
    name: nginx-deployment.171addd08f0f0247
    namespace: sys-mon
    resourceVersion: "16998367"
    uid: ff4024df-09bc-4c7e-a31a-645413ea5c60
  reason: ScalingReplicaSet
  reportingComponent: ""
  reportingInstance: ""
  source:
    component: deployment-controller
  type: Normal

- apiVersion: v1
  count: 1
  eventTime: null
  firstTimestamp: "2022-10-04T12:36:51Z"
  involvedObject:
    apiVersion: apps/v1
    kind: ReplicaSet
    name: nginx-deployment-68d7dcf58
    namespace: sys-mon
    resourceVersion: "16998584"
    uid: c8b6ae14-308f-4ad4-aee3-851ba5732694
  kind: Event
  lastTimestamp: "2022-10-04T12:36:51Z"
  message: 'Created pod: nginx-deployment-68d7dcf58-ffshg'
  metadata:
    creationTimestamp: "2022-10-04T12:36:51Z"
    name: nginx-deployment-68d7dcf58.171addea70c5a7ac
    namespace: sys-mon
    resourceVersion: "16998593"
    uid: 01ff1884-8c34-4907-bc7f-131854ca7d95
  reason: SuccessfulCreate
  reportingComponent: ""
  reportingInstance: ""
  source:
    component: replicaset-controller
  type: Normal

povilasv · 2022-10-04T12:49:24Z

Separately, I've a question on Kubernetes Events for my understanding - is the namespace+name combination unique across clusters? that is, (cluster+namespace+name) is unique and not just (namespace+name)?

In the case of multiple K8s clusters, event.Name + event.Namespace might collide. So to make it unique you would have to do something like event.name = Cluster Name + Event.Name + Event.Namespace to make it unique

jack-berg · 2022-10-04T23:44:23Z

In those examples the Kubernetes event name is nginx-deployment for the first, and nginx-deployment-68d7dcf58 for the second, correct? If so, I actually think these are not good matches for event.name. My interpretation of event.name (and I think this has been the consensus based on conversations) is that along with event.domain, it forms an identifier for a particular class of events. Events with the same event.domain / event.name should generally follow the same structure, which may be defined via semantic conventions. For example, within the browser domain, we may emit events with event.name of click. All click events would adhere to a similar structure.

The kubernetes event.name appears to be an identifier for a particular kubernetes resource, which is a different concept. For one, kubernetes event.name will be high cardinality. Although not yet explicitly stated in the spec, opentelemetry event.name is expected to be low-ish cardinality. Additionally, a particular kubernetes resource will have lots of distinct types of things performed on it, so records with the same event.name wouldn't follow a similar structure.

Looking at the examples you've shown there, I'd say an appropriate event.name might be something like involvedObject.kind + reason. So Deployment.ScalingReplicaSet and ReplicaSet.SuccessfulCreate for the two examples shown here.

povilasv · 2022-10-05T17:24:35Z

Thanks for your input @jack-berg :)

It makes sense, in these couple of examples we would have:

event.name = ReplicaSet.SuccessfulCreate
event.name= Deployment.ScalingReplicaSet

Some more different events from my K8s cluster:

event.name = Pod.FailedScheduling
event.name= Pod.SandboxChanged

And their event yamls:

- apiVersion: v1
  count: 1427
  eventTime: null
  firstTimestamp: "2022-10-04T14:36:18Z"
  involvedObject:
    apiVersion: v1
    kind: Pod
    name: grafana-7ff787496-jt66f
    namespace: sys-mon
    resourceVersion: "16683329"
    uid: 95690999-b3ce-4ce0-8b13-7bc96fee1320
  kind: Event
  lastTimestamp: "2022-10-05T17:21:51Z"
  message: '0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/unreachable:
    }, that the pod didn''t tolerate, 1 node(s) had volume node affinity conflict,
    1 node(s) were unschedulable.'
  metadata:
    creationTimestamp: "2022-10-04T14:36:19Z"
    name: grafana-7ff787496-jt66f.171ae46f3328e31a
    namespace: sys-mon
    resourceVersion: "17184616"
    uid: e279da47-303a-4ce2-9970-eedeb348f5ec
  reason: FailedScheduling
  reportingComponent: ""
  reportingInstance: ""
  source:
    component: default-scheduler
  type: Warning
 - apiVersion: v1
  count: 7396
  eventTime: null
  firstTimestamp: "2022-10-04T14:36:35Z"
  involvedObject:
    apiVersion: v1
    kind: Pod
    name: jaeger-http-app-76c6c87c5d-qrsc7
    namespace: kube-system
    resourceVersion: "16973991"
    uid: ac799f16-2de7-4cb3-ade6-e11b89178977
  kind: Event
  lastTimestamp: "2022-10-05T17:21:46Z"
  message: Pod sandbox changed, it will be killed and re-created.
  metadata:
    creationTimestamp: "2022-10-04T14:36:36Z"
    name: jaeger-http-app-76c6c87c5d-qrsc7.171ae4733596cefb
    namespace: kube-system
    resourceVersion: "17184604"
    uid: 920b4014-9e3a-4114-9d6d-26de852bfe8f
  reason: SandboxChanged
  reportingComponent: ""
  reportingInstance: ""
  source:
    component: kubelet
    host: rock64-0
  type: Normal

tigrannajaryan · 2022-10-05T18:34:59Z

I think using involvedObject.kind + reason or just reason sounds reasonable for event.name.

However, before we do that I have a question. Why do we need to record event.name and event.domain attributes for Kubernetes event? What's the purpose of doing it, what problem does it solve?

The primary purpose of event.name/event.domain is to make sure event consumers can clearly differentiate a subset of events they are interested in. In the case of Kubernetes events we already record a number of Kubernetes-specific attributes, such as k8s.event.reason or k8s.event.name which are very distinct and server the differentiation purpose.

What other reasons are there?

dmitryax · 2022-10-05T18:46:42Z

I think using involvedObject.kind + reason or just reason sounds reasonable for event.name.

I agree. Reason seems the best candidate for event.name.

Why do we need to record event.name and event.domain attributes for Kubernetes event? What's the purpose of doing it, what problem does it solve?

Probably just comply with the new Events API spec.

dmitryax · 2022-10-05T18:50:04Z

Also I believe we need to put the full k8s event payload into the log body. Thats my understanding from reading the new OTel Events spec.

This approach is taken in the new receiver proposed in #14185 which does a bit more than events collection.

If we agree on the approach, we can probably replace the k8s events receiver with the new one going forward

scheler · 2022-10-05T18:50:09Z

Why do we need to record event.name and event.domain attributes for Kubernetes event? What's the purpose of doing it, what problem does it solve?

I thought this is to conform the definition of Event in OpenTelemetry. If these attributes are missing, then these messages would be termed as logs. So if the backends are okay receiving Kubernetes events as logs then we can omit these attributes.

Btw, recording metadata.name for event.name or k8s.event.name is incorrect and misleading, it is the name of the object reported in the event and not the name of the event itself.

Aneurysm9 · 2022-10-05T19:59:00Z

Why do we need to record event.name and event.domain attributes for Kubernetes event? What's the purpose of doing it, what problem does it solve?

I thought this is to conform the definition of Event in OpenTelemetry. If these attributes are missing, then these messages would be termed as logs. So if the backends are okay receiving Kubernetes events as logs then we can omit these attributes.

I think this gets at the question I was trying to ask in the SIG meeting today but maybe not expressing well. What is the purpose of the event.name and event.domain attributes? It seems that they should be to identify the LogRecord as an Event and to allow determination of how to interpret other attributes in the Event. If, instead, we're meant to already know that we're looking for k8s events and check for k8s.kind == Event and k8s.reason as an attribute then what is the purpose of the Event type? What distinguishes the RUM events that are supposed to use event.domain and event.name?

tigrannajaryan · 2022-10-05T21:02:13Z

Probably just comply with the new Events API spec.

I thought this is to conform the definition of Event in OpenTelemetry.

There is no blanket requirement that every LogRecord produced by Collector complies with Events API spec. Events API is a spec for events produced by OpenTelemetry API, it is not a requirement for the Collector (at least it is not in the current understanding of the spec).

We may voluntarily follow if we believe we specifically want k8s events to have a similar shape, but it should not be the default assumption for all log record sources in the Collector.

tigrannajaryan · 2022-10-05T21:07:54Z

What is the purpose of the event.name and event.domain attributes?

My understanding of the purpose of the event.domain attribute is to:

Provide efficient means to route OTLP data by looking at the event.domain scope attribute only.
Isolate the domains at the design phase, so that if producers in one domain design a poor event schema, the blast radius of their poor choices is limited to that domain only and does not pollute someone else's domain.

dmitryax · 2022-10-05T22:01:45Z

There is no blanket requirement that every LogRecord produced by Collector complies with Events API spec. Events API is a spec for events produced by OpenTelemetry API, it is not a requirement for the Collector (at least it is not in the current understanding of the spec).

The receiver actually produces events not logs. So I was thinking that having event.domain and event.name are needed to distinguish events from log records.

tigrannajaryan · 2022-10-06T14:30:48Z

The receiver actually produces events not logs. So I was thinking that having event.domain and event.name are needed to distinguish events from log records.

Events are logs (mostly) :-)

We need to be careful with extending Otel API concepts unnecessarily to the Collector. We introduced an Otel Events helper API that allows to create LogRecords with a specific shape easily (with event.domain and event.name) because users told us this is a frequent case. However, it does not automatically mean that LogRecords we want to emit in Collector needs to comply with that same shape.

For now I still do not understand why the data that is produced by k8s events receiver needs to match the shape of LogRecord that is produced by Otel Events API. What is the rationale for this?

I have a feeling that we are trying to shoehorn the data produced by k8s events receiver into the shape that Otel Events API defined because there is a co-incidence of terminology (both have the word "events" in them).

Also keep in mind that event.domain is recorded as a Scope attribute, so there MUST be a Scope for this to be even applicable. What's the Scope for k8s events? What's the Name of that Scope? As far as I can tell the Scope produced by k8sevents receiver is currently empty.

scheler · 2022-10-06T16:44:25Z

For now I still do not understand why the data that is produced by k8s events receiver needs to match the shape of LogRecord that is produced by Otel Events API. What is the rationale for this?

The backends can have different processing pipelines for logs and events, so the telemetry producers should decide on what they are emitting and freeze it.

If, instead, we're meant to already know that we're looking for k8s events and check for k8s.kind == Event and k8s.reason as an attribute then what is the purpose of the Event type? What distinguishes the RUM events that are supposed to use event.domain and event.name?

For RUM events, we want to have expectation on the set of attributes for each value of event.name for the purpose of doing validation. and to avoid conflicts with events from other domains having same event names, we introduced the attribute event.domain for isolation. Now it felt natural to extend this convention to everyone that's generating events. They are still log records, but the distinction allows for a common events-specific processing pipeline additionally on the backend.

tigrannajaryan · 2022-10-06T17:40:23Z

The backends can have different processing pipelines for logs and events, so the telemetry producers should decide on what they are emitting and freeze it.

Right, but why are deciding that k8s events are more likely to be processed similar to RUM events than similar to for example K8s pod logs collected by filelog using Helm Chart (which are plain LogRecords)?

Again, I think we should not by default assume every new kind of log record becomes an event. If that is the case then we failed with defining why we needed both the Events API and the Logs API. In that case we shouldn't have a Logs API and we should have event.name and event.domain as hard-coded fields of the log data model instead of being semantic conventions. I disagree with this approach. To me the default is exactly the opposite: every new source of logs is a LogRecord. Only if there is a strong evidence that it precisely fits the Otel API's Event definition then it should be shaped as an Event with event.name attribute on LogRecord and event.domain attribute on the Scope.

Aneurysm9 · 2022-10-06T22:45:24Z

For RUM events, we want to have expectation on the set of attributes for each value of event.name for the purpose of doing validation. and to avoid conflicts with events from other domains having same event names, we introduced the attribute event.domain for isolation. Now it felt natural to extend this convention to everyone that's generating events.

Shouldn't this be the case for every structured log record? You need to know how to interpret the data contained in the record. That can come from an implicit expectation that all records in a given log stream conform to a set of conventions or by an explicit indication on each record. Why would RUM events be any different than k8s events from this perspective?

Right, but why are deciding that k8s events are more likely to be processed similar to RUM events than similar to for example K8s pod logs collected by filelog using Helm Chart (which are plain LogRecords)?

k8s events are emitted in a different way by a different system than pod logs. Pod logs are application logs that may or may not have structure and may or may not be part of an event-driven system. k8s events are events emitted by actors in an event-driven system and have shapes that can be determined based on the name of the event.

Again, I think we should not by default assume every new kind of log record becomes an event. If that is the case then we failed with defining why we needed both the Events API and the Logs API.

I'm worrying that we have decided that RUM events are somehow special and need to have their own API created for them which will be named as if it is generic but then people will be told that it isn't and they shouldn't use it as if it were. Event is a terribly general term and even if we try to give it a specific meaning it is likely that definition will be ignored in favor of intuition. Many different systems are going to have events and I'm not sure we should try to be gatekeepers protecting the One True Event.

In my view, every log record represents an event. Every structured log record may represent an Event. Most probably do, but event.domain is implicit or simply the log stream name and event.name is the message with the two combined enabling identification of how to interpret the remaining fields in the event.

We need to be careful with extending Otel API concepts unnecessarily to the Collector. We introduced an Otel Events helper API that allows to create LogRecords with a specific shape easily (with event.domain and event.name) because users told us this is a frequent case. However, it does not automatically mean that LogRecords we want to emit in Collector needs to comply with that same shape.

Why would this only apply to LogRecords created by an OTel API? Don't we assume that metrics or spans may be constructed by systems that do not use an OTel API? Whether directly into OTLP or in some other format through the collector. Shouldn't logs be the same?

Also keep in mind that event.domain is recorded as a Scope attribute, so there MUST be a Scope for this to be even applicable. What's the Scope for k8s events? What's the Name of that Scope? As far as I can tell the Scope produced by k8sevents receiver is currently empty.

That should be easily fixed. There has to be a scope in the plogs.Logs emitted by the receiver. If it isn't populated with attributes then that can be fixed. The receiver's import path becomes the scope name and the event.domain value can be k8s or it could be io.k8s.{{.kind}}.{{.apiVersion}}, which should give something like io.k8s.Event.v1. That seems to fulfill the stated purpose of "avoid[ing] conflicts with events from other domains having same event names".

tigrannajaryan · 2022-10-06T23:12:26Z

OK, looks like some clarifications and guidance is due in the Logs spec. I will try to put together something and will link from here.

The spec is currently not very clear about what is a log and what is an event. Here is a for example a discussion that shows that there are different ways to interpret what is written in the spec today: open-telemetry/opentelemetry-collector-contrib#14474 This PR attempts to clarify the spec by defining the vocabulary more strictly and by adding a relevant FAQ.

tigrannajaryan · 2022-10-11T14:41:53Z

I submitted open-telemetry/opentelemetry-specification#2863, let's discuss.

The spec is currently not very clear about what is a log and what is an event. Here is a for example a discussion that shows that there are different ways to interpret what is written in the spec today: open-telemetry/opentelemetry-collector-contrib#14474 This PR attempts to clarify the spec by defining the vocabulary more strictly and by adding a relevant FAQ.

…t.name attributes represent (#2848) * Remove language around uniqueness of event names within a domain This came up in open-telemetry/opentelemetry-collector-contrib#14474 where it was highlighted that just `name` is not sufficient to provide for uniqueness of a Kubernetes Event. The attribute `event.domain` is only meant to be a logical separation across different event systems, so it allows for similar looking names in different domains but with a completely different purpose. However, within each domain we don't have to have any uniqueness constraints on the `name` and leave it to whatever is idiomatic to the particular event system the domain represents.

github-actions · 2022-12-12T03:33:17Z

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

receiver/k8sevents: @dmitryax

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

…t.name attributes represent (#2848) * Remove language around uniqueness of event names within a domain This came up in open-telemetry/opentelemetry-collector-contrib#14474 where it was highlighted that just `name` is not sufficient to provide for uniqueness of a Kubernetes Event. The attribute `event.domain` is only meant to be a logical separation across different event systems, so it allows for similar looking names in different domains but with a completely different purpose. However, within each domain we don't have to have any uniqueness constraints on the `name` and leave it to whatever is idiomatic to the particular event system the domain represents.

github-actions · 2023-05-26T22:00:08Z

This issue has been closed as inactive because it has been stale for 120 days with no activity.

…t.name attributes represent (#2848) * Remove language around uniqueness of event names within a domain This came up in open-telemetry/opentelemetry-collector-contrib#14474 where it was highlighted that just `name` is not sufficient to provide for uniqueness of a Kubernetes Event. The attribute `event.domain` is only meant to be a logical separation across different event systems, so it allows for similar looking names in different domains but with a completely different purpose. However, within each domain we don't have to have any uniqueness constraints on the `name` and leave it to whatever is idiomatic to the particular event system the domain represents.

povilasv added the needs triage New item requiring triage label Sep 26, 2022

evan-bradley added enhancement New feature or request priority:p2 Medium receiver/k8sevents and removed needs triage New item requiring triage labels Sep 26, 2022

povilasv mentioned this issue Sep 30, 2022

[receiver/k8seventsreceiver] add support for Event semantic attributes #14603

Closed

scheler mentioned this issue Sep 30, 2022

Clarification on what an Event is, and what the event.domain and event.name attributes represent open-telemetry/opentelemetry-specification#2848

Merged

dmitryax mentioned this issue Oct 5, 2022

add Kubernetes events preset open-telemetry/opentelemetry-helm-charts#388

Closed

tigrannajaryan mentioned this issue Oct 7, 2022

Update log readme to reflect addition of API open-telemetry/opentelemetry-specification#2800

Merged

povilasv mentioned this issue Oct 10, 2022

[receiver/k8sobjects] initial commit #14699

Merged

tigrannajaryan mentioned this issue Oct 11, 2022

Clarify logs vs events vocabulary and usage open-telemetry/opentelemetry-specification#2863

Closed

github-actions bot added the Stale label Dec 12, 2022

github-actions bot added the closed as inactive label May 26, 2023

github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 26, 2023

tetianakravchenko mentioned this issue Oct 17, 2024

event.name field of the kubernetes events does not reflect events definition #35857

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[receiver/k8seventsreceiver] Support for semantic attributes #14474

[receiver/k8seventsreceiver] Support for semantic attributes #14474

povilasv commented Sep 26, 2022 •

edited

Loading

github-actions bot commented Sep 26, 2022

povilasv commented Sep 30, 2022 •

edited

Loading

scheler commented Sep 30, 2022

jack-berg commented Oct 3, 2022

scheler commented Oct 3, 2022

povilasv commented Oct 4, 2022

povilasv commented Oct 4, 2022

jack-berg commented Oct 4, 2022

povilasv commented Oct 5, 2022 •

edited

Loading

tigrannajaryan commented Oct 5, 2022

dmitryax commented Oct 5, 2022 •

edited

Loading

dmitryax commented Oct 5, 2022 •

edited

Loading

scheler commented Oct 5, 2022

Aneurysm9 commented Oct 5, 2022

tigrannajaryan commented Oct 5, 2022 •

edited

Loading

tigrannajaryan commented Oct 5, 2022 •

edited

Loading

dmitryax commented Oct 5, 2022 •

edited

Loading

tigrannajaryan commented Oct 6, 2022

scheler commented Oct 6, 2022

tigrannajaryan commented Oct 6, 2022

Aneurysm9 commented Oct 6, 2022

tigrannajaryan commented Oct 6, 2022

tigrannajaryan commented Oct 11, 2022

github-actions bot commented Dec 12, 2022

github-actions bot commented May 26, 2023

[receiver/k8seventsreceiver] Support for semantic attributes #14474

[receiver/k8seventsreceiver] Support for semantic attributes #14474

Comments

povilasv commented Sep 26, 2022 • edited Loading

Describe the issue you're reporting

github-actions bot commented Sep 26, 2022

povilasv commented Sep 30, 2022 • edited Loading

scheler commented Sep 30, 2022

jack-berg commented Oct 3, 2022

scheler commented Oct 3, 2022

povilasv commented Oct 4, 2022

povilasv commented Oct 4, 2022

jack-berg commented Oct 4, 2022

povilasv commented Oct 5, 2022 • edited Loading

tigrannajaryan commented Oct 5, 2022

dmitryax commented Oct 5, 2022 • edited Loading

dmitryax commented Oct 5, 2022 • edited Loading

scheler commented Oct 5, 2022

Aneurysm9 commented Oct 5, 2022

tigrannajaryan commented Oct 5, 2022 • edited Loading

tigrannajaryan commented Oct 5, 2022 • edited Loading

dmitryax commented Oct 5, 2022 • edited Loading

tigrannajaryan commented Oct 6, 2022

scheler commented Oct 6, 2022

tigrannajaryan commented Oct 6, 2022

Aneurysm9 commented Oct 6, 2022

tigrannajaryan commented Oct 6, 2022

tigrannajaryan commented Oct 11, 2022

github-actions bot commented Dec 12, 2022

github-actions bot commented May 26, 2023

povilasv commented Sep 26, 2022 •

edited

Loading

povilasv commented Sep 30, 2022 •

edited

Loading

povilasv commented Oct 5, 2022 •

edited

Loading

dmitryax commented Oct 5, 2022 •

edited

Loading

dmitryax commented Oct 5, 2022 •

edited

Loading

tigrannajaryan commented Oct 5, 2022 •

edited

Loading

tigrannajaryan commented Oct 5, 2022 •

edited

Loading

dmitryax commented Oct 5, 2022 •

edited

Loading