Container Resource MetaData auto detection in Resource SDK

[pavankrish123]

Problem Statement

In the spirit of what was done in #1788 #1840 for Process and Operating system auto detection - It is worthwhile to have an auto detection processor that collects and reports container information container.id and container.name.

Proposed Solution

Most of the container runtime environments (Docker, CRI-O, and containerd) have this informaton in cgroup files on the container filesystem. Resource SDK initialization goes through these files and fetches it.

Alternatives

Other option is to set environment variables on containers. But that is still sort of manual thing to do or some orchestration agent does it (like K8, PAAS environement)

cc: @stevebappd

[jmacd]

@pavankrish123 How would you detect the container name in K8s, by the way? I've heard concerns about using the K8s API server for this because of load.

[pavankrish123]

@jmacd - At least the idea is to tap into container filesystem (different locations for different runtimes) and get whatever information without touching k8 APIs. As you correctly put - accessing K8 apis is definitely not healthy.

Here is a feature our team has pushed recently on Java side open-telemetry/opentelemetry-java#3321 to do the same w/o using K8 downward APIs.

cc: @lo-jason @stevebappd

[jmacd]

@pavankrish123 This is great to hear. Very cool!

[pavankrish123]

@jmacd I Fixed the description (Struck off the contianer.name ask) - I believe only container.id can be derived through filesystem (PR open-telemetry/opentelemetry-java#3321) . container.name I am not sure.

Good catch 👍🏼

Once the Java one goes through, I can port the changes to golang.

[jmacd]

This interests me because Prometheus goes to great lengths to fill in this kind of name as a label without hammering the k8s API. If we could get basic resource information like this in the SDK itself, would be a huge win. I didn't think it was possible w/o modifying the k8s object...