[receiver/hostmetricsreceiver] Deprecate the processesscraper

[braydonk]

Component(s)

[receiver/hostmetrics]

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

In the orbit of the coming semantic conventions changes, it was decided that the processesscraper should be deprecated in favour of adding the system.processes.* metrics to the processscraper directly.

Describe the solution you'd like

Instead of:

hostmetrics:
  scrapers:
    process:
    processes:

I would like the following config to give the same results:

hostmetrics:
  scrapers:
    process:
      metrics:
        system.processes.created:
          enabled: true
        system.processes.count:
          enabled: true

Describe alternatives you've considered

It might be useful to have particular flags on the processscraper to enable/disable per process metrics and enable/disable aggregate process metrics. This is because if you only want the system.processes.* metrics, it is quite tedious to manually disable all the other metrics through the configuration.

Additional context

This has two benefits:

1. While the change hasn't formulated yet, there is a plan for the system.processes namespace to be renamed to conform with the semantic conventions rules around pluralized namespaces
2. Collecting all the processes on the system only one time should be a performance/memory improvement.

[braydonk]

I messed up submitting the issue and missed setting the component properly my bad

[github-actions]

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

[crobert-1]

Out of ignorance, do you have a reference for where this was discussed and the decision was reached? This may need a deprecation warning and some time to pass before actually doing the work of deprecating it since the host metrics receiver is in beta.

[braydonk]

It was discussed in System Semantic Conventions Meetings and directly between @dmitryax and I, so I don't have anything to link to. I should have opened the issue sooner, and my PR shouldn't gun it straight for deprecation. I admit I'm not fully familiar with the process for deprecation, where is that written down? I'll regroup and make sure I actually follow that here.

[crobert-1]

No worries, just wanted to make sure I understood the context here. Thanks for adding more information!

For deprecation the closest thing would probably be here. This is for an entire component, but I think the idea is generally applicable to this situation.

Your initial PR isn't actually removing things, so I think it's probably still matching expectations here.

[ChrsMark]

It was discussed in System Semantic Conventions Meetings and directly between @dmitryax and I, so I don't have anything to link to.

That was also summarised at open-telemetry/semantic-conventions#484 (comment).

While the change hasn't formulated yet, there is a plan for the system.processes namespace to be renamed to conform with the semantic conventions rules around pluralized namespaces

The change in the SemConv has also already been merged: open-telemetry/semantic-conventions#484

[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.

[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.