dockerstats/different containers runtimes

[bmiguel-teixeira]

Component(s)

receiver/dockerstats

Describe the issue you're reporting

Hi team,

Considering that this receiver is intended for Docker API, would it make sense to extend this receiver via configuration (ex: runtime_engine: containerd) to support different runtime engines?

There are many other common container runtimes, most common are containerd and cri-o. Id like to eventually fetch stats from these engines as well. Would it make sense to expand this receiver as more generic and expose same/similar metrics but support multiple runtimes?

Cheers,

[github-actions]

Pinging code owners:

• receiver/dockerstats: @jamesmoessis

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[jamesmoessis]

My intial thoughts would be this idea is good for it's own receiver. Then, if the new receiver was able to successfully abstract all container runtimes then we can deprecate dockerstats receiver and podman receiver.

Also remember there are docker events (logs) as well as metrics, which is being added in this PR: #36284

Would this kind of thing also be ideally abstracted? May be more difficult because it's less structured than metrics, but happy to hear ideas.

[bmiguel-teixeira]

I was unaware about docker events (ill read up on that). However, just from looking at the docs shown for both docker & podman regarding metrics (https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/dockerstatsreceiver/documentation.md, https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/podmanreceiver/documentation.md) there are a lot of similarities.

I was actually thinking of trying to maintain a common set of metrics, with optional, specific runtime metrics available as needed.

I think we could move this in 2 directions.

1. Submit a standalone new receiver just for containerd (ex: containerdstatsreceiver). Give a spin as dev/alpha and see how the metrics generated compare to others, and consider merging if applicable.

or

2. We create try and move to new "generic" receiver (ex: containerruntimestatsreceiver) that tries to support all runtimes as best effort. Keep in dev/alpha and see how adoption/use-cases go.

P.S: I only know of the most common runtimes (containerd, docker - which typically also uses containerd underneath, containerd). Im unsure of how "broad" this market really is (w/ podman, cri-o etc)

wdyt?