jason plumb 32b6bd2a71 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](634a848b8e/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](94c9c75c4f/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. 🙃		2023-04-04 09:37:23 -07:00
..
library	Ensure that parsed container ID is 64 chars. (#8206)	2023-04-04 09:37:23 -07:00