ContainerResource extract container.id in Host env #7437
Assignees
Labels
bug
Something isn't working
Comments
|
cc @breedx-splk in case you have any ideas |
|
Relates to #7176. Maybe relates to golang #3508. |
|
I agree this is a bug. Seems like the |
trask
pushed a commit
that referenced
this issue
Apr 4, 2023
Resolves #7437. A few caveats about this. The TL;DR on #7437 is that a non-containerized process was reporting a `container.id` attribute. The submitter narrowed it down and I was able to confirm with the test case in this PR. I hunted for other means for code to determine if it's containerized with the idea to not even do the parsing if not containerized, but I couldn't find anything useful. In fact, most approaches of detecting containerization at all do involve parsing cgroups. Wacky. So I attempted to verify that container IDs should always be 64 characters. I found: * podman - docs [here](https://docs.podman.io/en/latest/markdown/podman-container-inspect.1.html) "Container ID (full 64-char hash)" * docker - UID generator source [here](https://github.com/moby/moby/blob/634a848b8e3bdd8aed834559f3b2e0dfc7f5ae3a/pkg/stringid/stringid.go#L36) shows 32 bytes (and even guards against fully numeric!) * lxc [man page ](https://linuxcontainers.org/lxc/manpages/man1/lxc-info.1.html)says "container identifier format is an alphanumeric string". If this maps into cgroups (no idea!), it would have already been broken in some cases because we enforce hex. I'm a little concerned about this approach because the [otel spec](https://github.com/open-telemetry/opentelemetry-specification/blob/94c9c75c4f82fbda08bddff02ce9a0c582fdd55c/specification/resource/semantic_conventions/container.md) suggests that "The UUID might be abbreviated.", but it's unclear/non-specific about the circumstances that might cause this. Open to hearing about why the approach presented here is a bad idea. 🙃
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When I use javaagent to collect trace in the host environment, I found that there is containerID in the resource.attributes, and the problem seems to be the isValidBase16String judgment method of ContainerResource
Steps to reproduce
The /proc/self/cgroup content line is
1:name=systemd:/user.slice/user-0.slice/session-31207.scopeWhat did you see instead?
It well extract
31207as container.id, but the environment is host instead of container.What version are you using?
otel-javaagent 1.20.2
Environment
centos 7.5
Additional context
The text was updated successfully, but these errors were encountered: