-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Thanks, @djaglowski. The suggestion makes sense to me. This functionality is important for Splunk. I'll try to prioritize it in my team. |
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. |
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 |
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 Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
I updated the todo list. Anyone planning to work on any item please convert it to an issue and assign to yourself. |
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/
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/
…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/
…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/
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 ```
…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 ```
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 ```
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.
…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 ```
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.
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
The text was updated successfully, but these errors were encountered: