Add container id support to Resource

[XSAM]

resolves #1981

Prior Art

• #3308 Support adding container.id to resource metadata opentelemetry-java#3321

cc: @pavankrish123

[codecov]

Codecov Report

Merging #2418 (15b4fc7) into main (0d0a732) will increase coverage by 0.0%.
The diff coverage is 93.3%.

@@          Coverage Diff          @@
##            main   #2418   +/-   ##
=====================================
  Coverage   75.7%   75.8%           
=====================================
  Files        172     173    +1     
  Lines      11619   11664   +45     
=====================================
+ Hits        8800    8842   +42     
- Misses      2609    2612    +3     
  Partials     210     210           

Impacted Files	Coverage Δ
sdk/resource/container.go	92.3% <92.3%> (ø)
sdk/resource/config.go	100.0% <100.0%> (ø)

[jcchavezs]

I was checking this PR, I was wondering if the approach I took in https://github.com/hypertrace/goagent/blob/main/sdk/internal/container/container.go was simpler or am I missing something. I also wonder, do we want an integration test like https://github.com/hypertrace/goagent/tree/main/tests/docker. I could port it here @XSAM

[XSAM]

I was wondering if the approach I took in https://github.com/hypertrace/goagent/blob/main/sdk/internal/container/container.go was simpler or am I missing something.

This test case shows a cgroup line may contain the prefix and the suffix.

opentelemetry-go/sdk/resource/container_test.go

Lines 49 to 51 in bf3c93c

	name: "with prefix and suffix",
	line: "13:name=systemd:/podruntime/docker/kubepods/crio-dc679f8a8319c8cf7d38e1adf263bc08d23.stuff",
	expectedContainerID: "dc679f8a8319c8cf7d38e1adf263bc08d23",

Also, here is an example of the cgroup string that is fetched from my Kubernetes cluster. You can see the cgroup string becomes complicated.

2:cpuset:/kubepods/besteffort/podbd31ef54-609d-44dd-85f8-12014a486358/a4a47304716dc887fc6c8e389bfd32c0f98f3571d41d220e43dbc6d0eec67182

I also wonder, do we want an integration test like https://github.com/hypertrace/goagent/tree/main/tests/docker.

Good point. I also wonder about this. To achieve this integration test, we need container runtime. It means to run the tests, it requires all contributors to install a container runtime. It also increases the dependence on this project. Not sure it is worth doing that. Any thoughts? @open-telemetry/go-approvers

[XSAM]

BTW, I found the approach of this PR is not working for cgroup v2. In cgroup v2, we only get little info from the cgroup file.

For instance,

0::/

[jcchavezs]

I am curious about this. Instead of opening up an API to this I would focus all efforts to get a unique strong implementation. Are you targeting a concrete case?

…

On Thu, Dec 9, 2021, 22:13 Steven E. Harris ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In sdk/resource/container.go <#2418 (comment)> : > + defaultContainerIDProvider containerIDProvider = getContainerIDFromCGroup +) + +type containerIDDetector struct{} + +const cgroupPath = "/proc/self/cgroup" Given that this detector uses a specific technique to find this container's ID—this one assuming that one extraced from the cgroup file is the right choice—would you be amenable to naming this detector more specifically? Perhaps cgroupContainerIDDetector? That would clarify where this ID is coming from, and open us to other approaches to finding a container's ID. I'm not sure whether it would warrant a corresponding change to the proposed WithContainerID function. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2418 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXOYASTLK2CLGHPJMAVBBLUQELY5ANCNFSM5IZYPSYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[seh]

Are you targeting a concrete case?

Are you asking me? If so, I'm telegraphing the conversation from today's Go SIG meeting—a conversation that I started. There will be other interpretation of what "a container's ID" is or what it means. I don't know what they are. I know enough to doubt the universality of this particular choice.

[MadVikingGod]

So I approved this with my understanding at the time that both cgroups were made in a response to containers, and that the current Linux runtimes, that I know of, all use cgroups under the hood to manage containers.

While both the OCI, and the CRI require a container ID, neither specifies that you must use cgroups to do so. I don't know if there is an implementation counter to this, but I will admit I haven't checked all of them.

With that in mind, these would be my recommendations:

• Remove defaultContainerIDProvider. You can still have this setup if needed for testing, but it shouldn't be default, instead, there should be the option for many different detectors.
• containerIDDetector should have cgroup in the name. It uses cgroups to find the containerID

[XSAM]

FYI, I created a comment on OCI spec looking for an official/stable way to fetch container id within the container.

[XSAM]

looking for an official/stable way to fetch container id within the container.

This should be a long-term direction and not block this PR.

[XSAM]

I believe this PR is ready for review.

[hanyuancheung]

lgtm!