Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[receiver/k8scluster] Remove usage of 'component.Host.GetExporters' #19741

Open
6 of 10 tasks
djaglowski opened this issue Mar 15, 2023 · 6 comments
Open
6 of 10 tasks

[receiver/k8scluster] Remove usage of 'component.Host.GetExporters' #19741

djaglowski opened this issue Mar 15, 2023 · 6 comments
Labels
never stale Issues marked with this label will be never staled and automatically removed receiver/k8scluster

Comments

@djaglowski
Copy link
Member

djaglowski commented Mar 15, 2023

Component(s)

receiver/k8scluster

Describe the issue you're reporting

See open-telemetry/opentelemetry-collector#7370 for additional context.

This receiver depends on an experimental function that may be removed in a future version. It uses this function to get a handle to a "metadata exporter". It then generates a special kind of data and sends it to this exporter.

The metadata is reported in an event driven style, where only changes are reported from this receiver to the metadata exporter.

I propose that this is not an appropriate way to pass non-standard data between components. Instead, an extension should be developed that can facilitate a publisher/subscriber model (or similar). The exporter, which currently must implement a special interface, can instead check for this extension and listen for updates. The receiver, which currently asks for a handle to the exporter and pushes updates, can instead check for the extension and push there instead.

Todo

We will execute according to design document here: https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/edit

@djaglowski djaglowski added the needs triage New item requiring triage label Mar 15, 2023
@github-actions
Copy link
Contributor

Pinging code owners:

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

@dmitryax
Copy link
Member

I propose that this is not an appropriate way to pass non-standard data between components. Instead, an extension should be developed that can facilitate a publisher/subscriber model (or similar). The exporter, which currently must implement a special interface, can instead check for this extension and listen for updates. The receiver, which currently asks for a handle to the exporter and pushes updates, can instead check for the extension and push there instead.

Thanks, @djaglowski. The suggestion makes sense to me. This functionality is important for Splunk. I'll try to prioritize it in my team.

@dmitryax
Copy link
Member

I discussed this with @tigrannajaryan offline, and he reminded me about a document he wrote specifically for this use case. https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/edit#heading=h.hxs8bzpumhfw I think we should migrate metadata updates to the entity data model and add logs pipeline support to k8s cluster receiver.

@djaglowski
Copy link
Member Author

djaglowski commented Mar 27, 2023

Looks like a well thought out solution. I don't have much of an opinion on which approach we take, aside from suggesting we should remove GetExporters.

@github-actions
Copy link
Contributor

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:

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

@github-actions github-actions bot added the Stale label May 29, 2023
@djaglowski djaglowski removed the Stale label May 30, 2023
@tigrannajaryan tigrannajaryan added the never stale Issues marked with this label will be never staled and automatically removed label Jun 19, 2023
@tigrannajaryan
Copy link
Member

I updated the todo list. Anyone planning to work on any item please convert it to an issue and assign to yourself.

tigrannajaryan added a commit to tigrannajaryan/opentelemetry-collector-contrib that referenced this issue Jul 11, 2023
Resolves open-telemetry#23565

This is part 1 of the work to move to entity events-as-log-records in K8s cluster receiver:
open-telemetry#19741

Overall design document:
https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/
djaglowski pushed a commit that referenced this issue Jul 19, 2023
Resolves
#23565

This is part 1 of the work to move to entity events-as-log-records in
K8s cluster receiver:
#19741

Overall design document:

https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/
tigrannajaryan added a commit to tigrannajaryan/opentelemetry-collector-contrib that referenced this issue Jul 19, 2023
…tity model

Resolves open-telemetry#24394

This is part 2 of the work to move to entity events-as-log-records in K8s cluster receiver:
open-telemetry#19741

This also adds the notion of entity type to the KubernetesMetadata definition
since it is required in the new data model.

Overall design document:
https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/
dmitryax pushed a commit that referenced this issue Jul 19, 2023
…he new entity model (#24396)

Resolves
#24394

This is part 2 of the work to move to entity events-as-log-records in
K8s cluster receiver:

#19741

This also adds the notion of entity type to the KubernetesMetadata
definition
since it is required in the new data model.

Overall design document: 

https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/
tigrannajaryan added a commit to tigrannajaryan/opentelemetry-collector-contrib that referenced this issue Jul 20, 2023
Resolves open-telemetry#24400

This is part 3 of the work to move to entity events-as-log-records in K8s cluster receiver:
open-telemetry#19741

Overall design document:
https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/

Example log record emitted when a pod changes:
```
ObservedTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 1970-01-01 00:00:00 +0000 UTC
SeverityText:
SeverityNumber: Unspecified(0)
Body: Empty()
Attributes:
     -> otel.entity.id: Map({"k8s.pod.uid":"07cc87d9-8e76-4472-b5ee-c9ecbad94ea9"})
     -> otel.entity.event.type: Str(entity_state)
     -> otel.entity.type: Str(k8s.pod)
     -> otel.entity.attributes: Map({"k8s-app":"kubernetes-dashboard","k8s.deployment.name":"kubernetes-dashboard","k8s.deployment.uid":"4c1ee765-906b-498b-80b5-bea67a714fce","k8s.replicaset.name":"kubernetes-dashboard-6c7ccbcf87","k8s.replicasetuid":"e8c052b4-c1db-43bd-806d-f85d8a861f5b","k8s.service.kubernetes-dashboard":"","k8s.workload.kind":"Deployment","k8s.workload.name":"kubernetes-dashboard","pod-template-hash":"6c7ccbcf87","podcreation_timestamp":"2023-06-30T11:32:00-04:00"})
Trace ID:
Span ID:
Flags: 0
```
dmitryax pushed a commit that referenced this issue Jul 21, 2023
…24419)

Resolves
#24400

This is part 3 of the work to move to entity events-as-log-records in
K8s cluster receiver:

#19741

Overall design document: 

https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/

Example log record emitted when a pod changes:
```
ObservedTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 1970-01-01 00:00:00 +0000 UTC
SeverityText:
SeverityNumber: Unspecified(0)
Body: Empty()
Attributes:
     -> otel.entity.id: Map({"k8s.pod.uid":"07cc87d9-8e76-4472-b5ee-c9ecbad94ea9"})
     -> otel.entity.event.type: Str(entity_state)
     -> otel.entity.type: Str(k8s.pod)
     -> otel.entity.attributes: Map({"k8s-app":"kubernetes-dashboard","k8s.deployment.name":"kubernetes-dashboard","k8s.deployment.uid":"4c1ee765-906b-498b-80b5-bea67a714fce","k8s.replicaset.name":"kubernetes-dashboard-6c7ccbcf87","k8s.replicasetuid":"e8c052b4-c1db-43bd-806d-f85d8a861f5b","k8s.service.kubernetes-dashboard":"","k8s.workload.kind":"Deployment","k8s.workload.name":"kubernetes-dashboard","pod-template-hash":"6c7ccbcf87","podcreation_timestamp":"2023-06-30T11:32:00-04:00"})
Trace ID:
Span ID:
Flags: 0
```
tigrannajaryan added a commit to tigrannajaryan/opentelemetry-collector-contrib that referenced this issue Jul 21, 2023
Resolves open-telemetry#24428

This is part 4 of the work to move to entity events-as-log-records in K8s cluster receiver:
open-telemetry#19741

Overall design document:
https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/

I chose to use Timestamp field of the LogRecord (and not ObservedTimestamp).
Please speak if you think ObservedTimestamp is a better place.

Example log record emitted BEFORE this PR:
```
ObservedTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 1970-01-01 00:00:00 +0000 UTC
SeverityText:
SeverityNumber: Unspecified(0)
Body: Empty()
Attributes:
     -> otel.entity.id: Map({"k8s.pod.uid":"07cc87d9-8e76-4472-b5ee-c9ecbad94ea9"})
     -> otel.entity.event.type: Str(entity_state)
     -> otel.entity.type: Str(k8s.pod)
     -> otel.entity.attributes: Map({"k8s-app":"kubernetes-dashboard","k8s.deployment.name":"kubernetes-dashboard","k8s.deployment.uid":"4c1ee765-906b-498b-80b5-bea67a714fce","k8s.replicaset.name":"kubernetes-dashboard-6c7ccbcf87","k8s.replicasetuid":"e8c052b4-c1db-43bd-806d-f85d8a861f5b","k8s.service.kubernetes-dashboard":"","k8s.workload.kind":"Deployment","k8s.workload.name":"kubernetes-dashboard","pod-template-hash":"6c7ccbcf87","podcreation_timestamp":"2023-06-30T11:32:00-04:00"})
Trace ID:
Span ID:
Flags: 0
```

Example log record emitted AFTER this PR:
```
ObservedTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 2023-07-21 17:42:54.851743 +0000 UTC
SeverityText:
SeverityNumber: Unspecified(0)
Body: Empty()
Attributes:
     -> otel.entity.id: Map({"k8s.pod.uid":"07cc87d9-8e76-4472-b5ee-c9ecbad94ea9"})
     -> otel.entity.event.type: Str(entity_state)
     -> otel.entity.type: Str(k8s.pod)
     -> otel.entity.attributes: Map({"k8s-app":"kubernetes-dashboard","k8s.deployment.name":"kubernetes-dashboard","k8s.deployment.uid":"4c1ee765-906b-498b-80b5-bea67a714fce","k8s.replicaset.name":"kubernetes-dashboard-6c7ccbcf87","k8s.replicasetuid":"e8c052b4-c1db-43bd-806d-f85d8a861f5b","k8s.service.kubernetes-dashboard":"","k8s.workload.kind":"Deployment","k8s.workload.name":"kubernetes-dashboard","pod-template-hash":"6c7ccbcf87","podcreation_timestamp":"2023-06-30T11:32:00-04:00"})
Trace ID:
Span ID:
Flags: 0
```
tigrannajaryan added a commit to tigrannajaryan/opentelemetry-collector-contrib that referenced this issue Jul 21, 2023
Resolves open-telemetry#24413

This is part 4 of the work to move to entity events-as-log-records in K8s cluster receiver:
open-telemetry#19741

Overall design document:
https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/

Note that metadata.GetMetadataUpdate() computes deltas between the old and
new state. If the old and states are equal metadata.GetMetadataUpdate() returns
an empty slice. This means periodic polling when no state is changed will
NOT result in any additional metadata update calls. So, we expect no changes
in the behavior of existing metadata listeners, such as signalfxexporter.

As opposed to that entity events are always emitted even if no state is
changed. So, this periodic collection will result in periodic emitting
of entity events. This is the desirable effect of this PR.

### Testing

I was unable to think of a good automated test for this capability that does
not require a major refactoring of other code and executes reasonably quickly.
For this reason I am not including any tests in this PR. I have tested the
functionality manually and can see the entities periodically collected
according to the config setting.
dmitryax pushed a commit that referenced this issue Jul 21, 2023
…24431)

Resolves
#24428

This is part 4 of the work to move to entity events-as-log-records in
K8s cluster receiver:
#19741

Overall design document:

https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/

I chose to use Timestamp field of the LogRecord (and not
ObservedTimestamp). Please speak if you think ObservedTimestamp is a
better place.

I am not sure if changelog entry is needed for this PR. It is an
addition to an API that is experimental
and not yet released.

Example log record emitted BEFORE this PR:
```
ObservedTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 1970-01-01 00:00:00 +0000 UTC
SeverityText:
SeverityNumber: Unspecified(0)
Body: Empty()
Attributes:
     -> otel.entity.id: Map({"k8s.pod.uid":"07cc87d9-8e76-4472-b5ee-c9ecbad94ea9"})
     -> otel.entity.event.type: Str(entity_state)
     -> otel.entity.type: Str(k8s.pod)
     -> otel.entity.attributes: Map({"k8s-app":"kubernetes-dashboard","k8s.deployment.name":"kubernetes-dashboard","k8s.deployment.uid":"4c1ee765-906b-498b-80b5-bea67a714fce","k8s.replicaset.name":"kubernetes-dashboard-6c7ccbcf87","k8s.replicasetuid":"e8c052b4-c1db-43bd-806d-f85d8a861f5b","k8s.service.kubernetes-dashboard":"","k8s.workload.kind":"Deployment","k8s.workload.name":"kubernetes-dashboard","pod-template-hash":"6c7ccbcf87","podcreation_timestamp":"2023-06-30T11:32:00-04:00"})
Trace ID:
Span ID:
Flags: 0
```

Example log record emitted AFTER this PR:
```
ObservedTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 2023-07-21 17:42:54.851743 +0000 UTC
SeverityText:
SeverityNumber: Unspecified(0)
Body: Empty()
Attributes:
     -> otel.entity.id: Map({"k8s.pod.uid":"07cc87d9-8e76-4472-b5ee-c9ecbad94ea9"})
     -> otel.entity.event.type: Str(entity_state)
     -> otel.entity.type: Str(k8s.pod)
     -> otel.entity.attributes: Map({"k8s-app":"kubernetes-dashboard","k8s.deployment.name":"kubernetes-dashboard","k8s.deployment.uid":"4c1ee765-906b-498b-80b5-bea67a714fce","k8s.replicaset.name":"kubernetes-dashboard-6c7ccbcf87","k8s.replicasetuid":"e8c052b4-c1db-43bd-806d-f85d8a861f5b","k8s.service.kubernetes-dashboard":"","k8s.workload.kind":"Deployment","k8s.workload.name":"kubernetes-dashboard","pod-template-hash":"6c7ccbcf87","podcreation_timestamp":"2023-06-30T11:32:00-04:00"})
Trace ID:
Span ID:
Flags: 0
```
dmitryax pushed a commit that referenced this issue Jul 24, 2023
Resolves
#24413

This is part of the work to move to entity events-as-log-records in K8s
cluster receiver:
#19741

Overall design document:

https://docs.google.com/document/d/1Tg18sIck3Nakxtd3TFFcIjrmRO_0GLMdHXylVqBQmJA/

Note that metadata.GetMetadataUpdate() computes deltas between the old
and new state. If the old and new states are equal
metadata.GetMetadataUpdate() returns an empty slice. This means periodic
polling when no state is changed will NOT result in any additional
metadata update calls. So, we expect no changes in the behavior of
existing metadata listeners, such as signalfxexporter.

As opposed to that entity events are always emitted even if no state is
changed. So, this periodic collection will result in periodic emitting
of entity events. This is the desirable effect of this PR.

### Testing

I was unable to think of a good automated test for this capability that
does not require a major refactoring of other code and executes
reasonably quickly. For this reason I am not including any tests in this
PR. I have tested the functionality manually and can see the entities
periodically collected according to the config setting.

If anyone has ideas about how to write good unit tests for this PR I am
open to suggestions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
never stale Issues marked with this label will be never staled and automatically removed receiver/k8scluster
Projects
None yet
Development

No branches or pull requests

4 participants