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

[k8sattributesprocessor]: Fall back to only container within a pod if no k8s.container.name/container.id attribute is present in resource #34189

Open
bacherfl opened this issue Jul 22, 2024 · 5 comments · May be fixed by #36844
Labels
enhancement New feature or request never stale Issues marked with this label will be never staled and automatically removed processor/k8sattributes k8s Attributes processor

Comments

@bacherfl
Copy link
Contributor

Component(s)

processor/k8sattributes

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

Currently, the k8sattributes processor requires either the k8s.container.name or container.id attribute to be present in the resource attributes to attach container level attributes, as described in the readme.
This makes sense for pods with multiple containers, as otherwise it would not be possible to correctly associate the resource to the correct container.
For pods containing only one container however, this requirement can likely be dropped, and the container level attributes from the only container can automatically be attached for resources coming from a matching pod. This could potentially make things a bit simpler for users, as the requirement of providing the container name or id as attributes for the resource seemed to have caused some confusion in the past (e.g. #32104 (comment))

Describe the solution you'd like

If a matching pod is found for an incoming resource, and the pod only consists of one container, automatically attach the container level attributes if they are part of the extraction rules, also when the k8s.container.name and container.id are not provided resource attributes.

Describe alternatives you've considered

Attaching the k8s.container.name or container.id attribute to the resource sent to the collector will also ensure the container level attributes are attached correctly, but this is a requirement that may easily be missed by users.

Additional context

If this is something we agree to add, I'm happy to work on the implementation. In the meantime I will work on a PoC to validate the suggested solution

@bacherfl bacherfl added enhancement New feature or request needs triage New item requiring triage labels Jul 22, 2024
@github-actions github-actions bot added the processor/k8sattributes k8s Attributes processor label Jul 22, 2024
Copy link
Contributor

Pinging code owners:

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

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.

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 Dec 16, 2024
@ChrsMark
Copy link
Member

ChrsMark commented Dec 16, 2024

I'd also agree that there is room for improvement there. I'd be happy to review if there is a PR attempting to do so.

@ChrsMark ChrsMark added never stale Issues marked with this label will be never staled and automatically removed and removed Stale waiting-for-code-owners labels Dec 16, 2024
@bacherfl
Copy link
Contributor Author

Thanks for the feedback @ChrsMark! I'll start working on a PR for this today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request never stale Issues marked with this label will be never staled and automatically removed processor/k8sattributes k8s Attributes processor
Projects
None yet
3 participants