Support for scraping a system "uptime" metric

[jamesmoessis]

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

The problem is that there is no "uptime" metric emitted from the collector's receivers. For us, many existing systems rely on this metric being scraped, and so not having this metric blocks migration. An entirely new receiver for this seems overkill.

Other agents, such as the signalfx agent, have scrapers for this.

Describe the solution you'd like

A scraper in the hostmetricsreceiver that retrieves uptime, in the Linux case, from /proc/uptime. Also open to suggestions if there are any other suitable receivers. Potentially there could be a scraper in the hostmetrics receiver that scrapes miscellaneous system information. Also open to suggestions here.

Describe alternatives you've considered

I've considered writing my own receiver that collects the metric.

Additional context

No response

[github-actions]

Pinging code owners: @dmitryax. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[andrzej-stencel]

I believe this is a reasonable request. I think a new system scraper could be created to provide general system information like uptime and other information (to be honest no other examples come to mind at the moment).

We would probably need a semantic convention established for the metric name. I allowed myself to create a proposal here: open-telemetry/semantic-conventions#648.

[jamesmoessis]

@astencel-sumo I like your idea of a systemreceiver/scraper that scrapes general system info. I would be interested in working with anyone to create such a scraper, providing that we had support and sponsorship from a maintainer. I wonder if any maintainer has had similar thoughts and ideas.

I don't think we need to wait for something like system.uptime to be in the semantic convention to start work on a systemreceiver/scraper. There are plenty of scrapers that emit metrics that aren't part of the semconv.

[jamesmoessis]

I've also noticed there is an InfoStat struct in gopsutils (the same lib that hostmetricsreceiver uses) which exposes uptime and a bunch of other system data. I think exposing that data as a scraper in the host metrics receiver would fit in quite nicely.

Perhaps we can get some thoughts on the above from the codeowner of host metrics - @dmitryax any thoughts?

[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

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

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.

[kevinnoel-be]

Still useful

[kernelpanic77]

Can we sort of reopen this issue ? I think it is still relevant.

[omkarumarani]

We are looking for this matrix

[andrzej-stencel]

This issue was closed due to inactivity some time ago. Recently a new issue has been raised for this: #31627, so there's a chance this will be implemented.