Add a metric for image filesystem usage

[epochstamp]

Component(s)

receiver/hostmetrics, receiver/kubeletstats

Is your feature request related to a problem? Please describe.

I am currently migrating a monitoring solution from metricbeats to OTLP and I would like to monitor the image filesystem usage like it is done in metricbeats through the metrics kubernetes.node.runtime.imagefs.capacity.bytes, kubernetes.node.runtime.imagefs.available.bytes and kubernetes.node.runtime.imagefs.used.bytes.

Describe the solution you'd like

Implement in the same fashion the metrics (in the kubeletstatsreceiver) k8s.node.imagefs.capacity, k8s.node.imagefs.available and k8s.node.imagefs.used, respectively.
Implementing the same kind of metrics in hostmetrics (filesystem scraper) with the naming pattern system.imagefs.{*} should also be considered imho.

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/hostmetrics: @dmitryax @braydonk
• receiver/kubeletstats: @dmitryax @TylerHelmuth @ChrsMark

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

[braydonk]

Would you mind opening this same request in https://github.com/open-telemetry/semantic-conventions?

I'll repeat this thought there, but my initial thought is that imagefs metrics may belong in an exclusive imagefs namespace, and once that is in semantic conventions both receivers could simply produce the same set of metrics (or whichever makes the most sense; sorry I'm just learning from this issue what imagefs is 😄)

[epochstamp]

Sure, I'll take care of it !

Regarding the documentation of metricbeats, I would indeed agree that a new namespace is needed for that metric (though adding more inertia to this feature implementation :'()

(Don't worry, I'm also learning the whole stuff in my current position ^^)

[braydonk]

though adding more inertia to this feature implementation

Yeah apologies for that; we're going through a big transition to make all new instrumentation go through semantic conventions and right now it's a big lift of everything that's here into proper semantic conventions. Stuff will get easier once we're through the growing pains of that transition. Thanks for your understanding!

[ChrsMark]

Would you mind opening this same request in https://github.com/open-telemetry/semantic-conventions?

I'll repeat this thought there, but my initial thought is that imagefs metrics may belong in an exclusive imagefs namespace, and once that is in semantic conventions both receivers could simply produce the same set of metrics (or whichever makes the most sense; sorry I'm just learning from this issue what imagefs is 😄)

While that approach makes sense, one thing to verify here would be to ensure that kubeletstats and hostmetrics receivers can actually provide equivalent metrics. If that's true then enabling the metric in either of them should provide the same results.

kubeletstats receiver scrapes the Kubelet's stats endpoint hence we need to check if the provided value is aligned with what the hostmetrics receiver would collect.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/hostmetrics: @dmitryax @braydonk
• receiver/kubeletstats: @dmitryax @TylerHelmuth @ChrsMark

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