Add cgroup v2 support for container id detector#3508
Add cgroup v2 support for container id detector#3508XSAM wants to merge 12 commits intoopen-telemetry:mainfrom
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3508 +/- ##
=====================================
Coverage 78.0% 78.1%
=====================================
Files 164 166 +2
Lines 11815 11845 +30
=====================================
+ Hits 9226 9252 +26
- Misses 2393 2395 +2
- Partials 196 198 +2
🚀 New features to boost your workflow:
|
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
MadVikingGod
left a comment
There was a problem hiding this comment.
I found this doesn't work with podman. I tested it also with minikube docker, and found that I didn't get the proper containerID from V1, but the correct one from V2.
I made a gist of what I saw from /proc/self/cgroup and /proc/self/mointinfo https://gist.github.com/MadVikingGod/6ecba436717948c1a332c63f250f973e
|
|
||
| const cgroupV2Path = "/proc/self/mountinfo" | ||
|
|
||
| var cgroupV2ContainerIDRe = regexp.MustCompile(`.*/docker/containers/([0-9a-f]{64})/.*`) |
There was a problem hiding this comment.
This is very docker specific. I found with podman there is a different format for the container layers, and I am also checking containerd.
There was a problem hiding this comment.
The same is used in Java here (https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/ca8e7b1385d95517f28103d834aba960a0baa477/instrumentation/resources/library/src/main/java/io/opentelemetry/instrumentation/resources/CgroupV2ContainerIdExtractor.java#L27), so it would need to be fixed in both.
JavaScript is taking a different approach, I remember that we talked about containerd there and making it work:
There was a problem hiding this comment.
@svrnm Thanks for the heads-up. Looks like you pasted the same link twice, but it reads like the second one intended to link to a js discussion? Curious what the alt approach is...
There was a problem hiding this comment.
@breedx-splk thanks for calling out the wrong link, here's the JS one: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/f0a93685cfb43543b7ca577dd370d56576b49e3f/detectors/node/opentelemetry-resource-detector-container/src/detectors/ContainerDetector.ts#L54
|
|
||
| const cgroupV1Path = "/proc/self/cgroup" | ||
|
|
||
| var cgroupV1ContainerIDRe = regexp.MustCompile(`^.*/(?:.*-)?([0-9a-f]+)(?:\.|\s*$)`) |
There was a problem hiding this comment.
I don't think this is still the right way to capture this for V1.
When used with podman I'm capturing the userID of the pod, not a container or an empty string.
This is based on a conversation in [opentelemetry-go #3508](open-telemetry/opentelemetry-go#3508) and to be more consistent with [the js cgroupv2 parser impl](https://github.com/open-telemetry/opentelemetry-js-contrib/blob/f0a93685cfb43543b7ca577dd370d56576b49e3f/detectors/node/opentelemetry-resource-detector-container/src/detectors/ContainerDetector.ts#L68). Unsurprisingly, podman does not include the word `docker` in the `mountinfo` file. As a result, the container id parsing would fail from inside a podman container. This fixes that up to be more compatible.
…y-go into container-id-cgroup-v2
I found a strange case where my In this case, @MadVikingGod What was your environment to get those |
I started minikube with a different From what I've seen I don't know if there is a reliable way to get the containerID from within the context of the running container. It does seem like docker might do it this way, but that doesn't look like it's guaranteed between versions, and different runtimes do things differently. |
|
A concrete example of reproducing the incorrect container id in the cgroup v2 file in k8s EnvironmentOS: macOS 14.4.1 (ARM) Steps
Result:
Result The id on the
Result
Result SummaryThe container id |
|
Hi @XSAM. We are using crio as container runtime and I can confirm that the approach used here also does not work for crio. The current logic added in ths PR obtains the pod ID instead of the container ID, since the container does not seem to be present in in EnvironmentOS: Oracle Linux 9 (Kernel UEK7) |
|
Closing as stale |
Resolves #3501
The new container id detector tries to resolve the container id from the cgroup v1 file, if successful, the result is used. If v1 fails, then the detector falls back to the cgroup v2 file.