-
Notifications
You must be signed in to change notification settings - Fork 2.8k
[k8sattributesprocessor]: Fall back to only container within a pod if no k8s.container.name
/container.id
attribute is present in resource
#34189
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
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
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. |
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'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. |
Thanks for the feedback @ChrsMark! I'll start working on a PR for this today |
…o container name/id has been specified in the incoming resource attributes (open-telemetry#36844) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This PR adds a fallback logic to the processor by adding the container attributes for an incoming resource without the container name/id being explicitly set, provided the related pod only contains one container. If there are more than one container in a pod, the container name/id still have to be set explicitly. <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes open-telemetry#34189 <!--Describe what testing was performed and which tests were added.--> #### Testing Added unit tests <!--Describe the documentation added.--> #### Documentation Adapted the readme to reflect the changes made in this PR <!--Please delete paragraphs that you did not use before submitting.--> --------- Signed-off-by: Florian Bacher <[email protected]>
…o container name/id has been specified in the incoming resource attributes (open-telemetry#36844) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This PR adds a fallback logic to the processor by adding the container attributes for an incoming resource without the container name/id being explicitly set, provided the related pod only contains one container. If there are more than one container in a pod, the container name/id still have to be set explicitly. <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> #### Link to tracking issue Fixes open-telemetry#34189 <!--Describe what testing was performed and which tests were added.--> #### Testing Added unit tests <!--Describe the documentation added.--> #### Documentation Adapted the readme to reflect the changes made in this PR <!--Please delete paragraphs that you did not use before submitting.--> --------- Signed-off-by: Florian Bacher <[email protected]>
Component(s)
processor/k8sattributes
Is your feature request related to a problem? Please describe.
Currently, the
k8sattributes
processor requires either thek8s.container.name
orcontainer.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
andcontainer.id
are not provided resource attributes.Describe alternatives you've considered
Attaching the
k8s.container.name
orcontainer.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
The text was updated successfully, but these errors were encountered: