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

[Metricbeat][Kubernetes] Add container.name field to state_container #37515

Closed
wants to merge 5 commits into from

Conversation

constanca-m
Copy link
Contributor

Proposed commit message

Please explain:

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

How to test this PR locally

  1. Clone this branch.
  2. Follow the steps in the README file.
  3. Check in Discover that the field exists.

Related issues

Screenshots

Proof that it works:
image

@constanca-m constanca-m added bug Team:Cloudnative-Monitoring Label for the Cloud Native Monitoring team labels Dec 27, 2023
@constanca-m constanca-m self-assigned this Dec 27, 2023
@constanca-m constanca-m requested a review from a team as a code owner December 27, 2023 09:45
@botelastic botelastic bot added needs_team Indicates that the issue/PR needs a Team:* label and removed needs_team Indicates that the issue/PR needs a Team:* label labels Dec 27, 2023
Copy link
Contributor

mergify bot commented Dec 27, 2023

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @constanca-m? 🙏.
For such, you'll need to label your PR with:

  • The upcoming major version of the Elastic Stack
  • The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

  • backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

@elasticmachine
Copy link
Collaborator

❕ Build Aborted

Either there was a build timeout or someone aborted the build.

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Duration: 32 min 32 sec

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@constanca-m constanca-m changed the title [Kubernetes] Add container.name field to state_container [Metricbeat][Kubernetes] Add container.name field to state_container Dec 27, 2023
@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2023-12-27T10:10:48.935+0000

  • Duration: 50 min 36 sec

Test stats 🧪

Test Results
Failed 0
Passed 4521
Skipped 902
Total 5423

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

Copy link
Contributor

@tetianakravchenko tetianakravchenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this issue needs more clarifications

When I checked this PR I found few relevant PRs/discussions:

kubernetes.ShouldPut(containerFields, "name", cName, m.Logger())
}
}

// applying ECS to kubernetes.container.id in the form <container.runtime>://<container.id>
// copy to ECS fields the kubernetes.container.image, kubernetes.container.name
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this comment is also applicable to the container.name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked, but the value of the field is just <container.name>, it does not have the same format as <container.runtime>://<container.id>.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR @constanca-m ! I have tested this locally and works fine.

(I am posting the example from my local setup:)

metricset: container -> container.name: nginx
metricset: state_container: -> container.name: nginx

Even works for mutiple containers inside same pod

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what @tetianakravchenko meant is that the comment copy to ECS fields the kubernetes.container.image, kubernetes.container.name applies also for the addition you did. So it would be better to move your code under this comment.

Co-authored-by: Tetiana Kravchenko <tanya.kravchenko.v@gmail.com>
@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2024-01-03T09:31:46.900+0000

  • Duration: 52 min 26 sec

Test stats 🧪

Test Results
Failed 0
Passed 4521
Skipped 902
Total 5423

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@gsantoro
Copy link
Contributor

gsantoro commented Jan 8, 2024

@constanca-m have we addressed @tetianakravchenko concerns above about kubernetes.container.name not matching container.name?

Just to summarise this is the comment from Christos #24380 (comment) about those fields having different values.

If they have the same value, we should either use a alias or just keep only one of those like suggested at #23585 (comment).

If they differ, we shouldn't copy so the code changes are not correct either.

Have we verified that those two fields are exactly the same in different runtimes (eg. cloud with all the providers, docker, ...)

Copy link
Contributor

@gsantoro gsantoro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

verify first that those two fields should have the same values

@constanca-m
Copy link
Contributor Author

Have we verified that those two fields are exactly the same in different runtimes (eg. cloud with all the providers, docker, ...)

I had only tested with docker, but I tested now with GCP, and they are the exact same:
image

Regarding the comment #23585 (comment),

container.name is the name of the container that the runtime populates while kubernates.container.name is the name of the container in the kubernetes manifest.

I don't exactly understand this. @MichaelKatsoulis this comment is 2 years old, but any chance you can give some insight into why container.name is not the same as kubernetes.container.name?

@MichaelKatsoulis MichaelKatsoulis self-requested a review January 9, 2024 08:01
Signed-off-by: constanca <constanca.manteigas@elastic.co>
@elasticmachine
Copy link
Collaborator

💔 Build Failed

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2024-01-09T08:44:19.675+0000

  • Duration: 36 min 25 sec

Test stats 🧪

Test Results
Failed 0
Passed 3228
Skipped 613
Total 3841

Steps errors 6

Expand to view the steps failures

metricbeat-windows-2022-windows-2022 - Install Python
  • Took 0 min 5 sec . View more details here
  • Description: .ci/scripts/install-tools.bat
metricbeat-windows-2022-windows-2022 - Install Python
  • Took 0 min 2 sec . View more details here
  • Description: .ci/scripts/install-tools.bat
metricbeat-windows-2022-windows-2022 - Install Python
  • Took 0 min 4 sec . View more details here
  • Description: .ci/scripts/install-tools.bat
x-pack/metricbeat-windows-2022-windows-2022 - Install Python
  • Took 0 min 4 sec . View more details here
  • Description: .ci/scripts/install-tools.bat
x-pack/metricbeat-windows-2022-windows-2022 - Install Python
  • Took 0 min 2 sec . View more details here
  • Description: .ci/scripts/install-tools.bat
x-pack/metricbeat-windows-2022-windows-2022 - Install Python
  • Took 0 min 4 sec . View more details here
  • Description: .ci/scripts/install-tools.bat

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@elasticmachine
Copy link
Collaborator

❕ Build Aborted

Either there was a build timeout or someone aborted the build.

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Duration: 6 min 22 sec

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@MichaelKatsoulis
Copy link
Contributor

Have we verified that those two fields are exactly the same in different runtimes (eg. cloud with all the providers, docker, ...)

I had only tested with docker, but I tested now with GCP, and they are the exact same: image

Regarding the comment #23585 (comment),

container.name is the name of the container that the runtime populates while kubernates.container.name is the name of the container in the kubernetes manifest.

I don't exactly understand this. @MichaelKatsoulis this comment is 2 years old, but any chance you can give some insight into why container.name is not the same as kubernetes.container.name?

They are the same because in your code you get the container.name value from the event, which is the one added by ksm. So they cannot be different.
The only case they can differ is in docker runtime as I have seen. Docker names the containers differently than the name that is set in the manifest. You can see that by running docker ps.
But we don't seem to populate the container.name field anywhere other than the kubernetes container metricset. And even there, we set it to the value of the event.

I think that the problem is that the concepts of those two fields is a bit different and shouldn't be aliased. Now regarding setting it explicitly in the state_container as we do in container metricset I am not sure.
ECS fields, supposedly could be populated by other sources such as Otel. So we should be very cautious when populating them.
@ChrsMark what do you think on this as you have been working with the introduction of ECS fields to Otel community?

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2024-01-09T10:53:57.165+0000

  • Duration: 51 min 40 sec

Test stats 🧪

Test Results
Failed 0
Passed 4549
Skipped 902
Total 5451

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@ChrsMark
Copy link
Member

ChrsMark commented Jan 9, 2024

SemConv of OTel for container resource specifically defines:

Container name used by container runtime

(The same, conceptually, defines ECS as well)

So the point here is that container.name should only be populated with values coming from the runtime (whatever it is).

OTel also specifies the k8s.container.name attribute: https://opentelemetry.io/docs/specs/semconv/resource/k8s/#container

This implies that these 2 can be different in principle.

There might be cases that runtimes's names match what we see in the spec but we should not overload container.name with values coming from the Pod spec if we are not sure what the container runtime gives.

Example: Let's say that we have Metricbeat collecting these data and we do container.name<=kubernetes.container.name.
Then if another low level agent (a security scanning mechanism for example) runs on the nodes and interacts with the container runtimes directly then there is a chance that we will have a missmatch there and will not be able to correlate the data.

I haven't done any extensive research on this recently so I might miss sth here but I think that's how we should approach this one here.

@MichaelKatsoulis
Copy link
Contributor

So after @ChrsMark comment, I understand that is wrong to assume that container.name equals to kubernetes.container.name and if we are not sure of the runtime container name, we should not populate this field.

I believe the best approach is to not populate this field at all and also remove it from the container metricset.
cc @gizas

@constanca-m
Copy link
Contributor Author

Ok, seeing this implementation is wrong, I will close this PR and the issue.

@constanca-m constanca-m deleted the add-container-name branch May 17, 2024 13:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Team:Cloudnative-Monitoring Label for the Cloud Native Monitoring team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Field container.name is not populated for kubernetes.state_container
7 participants