Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ensure that parsed container ID is 64 chars. (#8206)
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. 🙃
- Loading branch information