Add a metric for available system entropy

[epochstamp]

Component(s)

receiver/hostmetrics

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 system entropy like it was done (in metricbeats).

Describe the solution you'd like

Provide an optional metric system.entropy in hostmetricsreceiver (unit as %, relative to the pool size of 4096) and/or system.entropy.available (bytes) along with system.entropy.total (bytes)

Describe alternatives you've considered

I have not identified any alternative inside OTLP to get that value

Additional context

See entropy metrics provided by metricbeats

[github-actions]

Pinging code owners:

• receiver/hostmetrics: @dmitryax @braydonk

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

[rogercoll]

@epochstamp Thanks for raising this topic.

Before adding a new metrics, it should be first defined in the semantic conventions repository to align with naming standards. I think system.entropy is a good name for it, @epochstamp do you know if these value can also be retrieved in systems other than Linux? I was wondering if system.linux.entropy would be a more suitable name.

The hostmetrics receiver does not have any specific scraper for this type of metrics, but I think it belongs to the same category of system.uptime. As discussed in #31627, a new system scraper would be needed.

[epochstamp]

@rogercoll thanks for raising your interest regarding this feature request :)

Accordingly to this Wikipedia article, it seems possible to get that value on Windows. For MacOS, /dev/random and /dev/urandom are also available, like in Linux.

About the naming, I would do exactly like the metrics system.memory.available and system.linux.memory.available by replacing memory.available by entropy (and linux by unix ?).

I also agree that this type of metrics should belong in a system category in hostmetrics.

BTW, I am open to implement this feature (and also other related to this category).

[rogercoll]

About the naming, I would do exactly like the metrics system.memory.available and system.linux.memory.available by replacing memory.available by entropy (and linux by unix ?).

If the entropy concept is shared among different systems/os, I think we should keep the metric name into a more generic group: system.entropy.available or system.entropy.usage. The system.linux.memory.available metric was moved to the Linux subgroup as the MemAvailable term being specific to the Linux Kernel.

BTW, I am open to implement this feature (and also other related to this category).

Sounds great, let's start with the semantic conventions approval on the metric names so we can import it later using the SDK: open-telemetry/semantic-conventions#1288

[epochstamp]

Many thanks for your feature request :)

[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

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

[rogercoll]

/label never-stale