Rename system.processes.* namespace to system.process.*

[ChrsMark]

Fixes #266

Changes

This PR renames system.processes.* namespace to system.process.*. This is based on #267 to align with "Metric namespaces should not be pluralized" rule.

Also it changes system.processes.created to system.process.created_total since .process.created would not indicate the total number of processes but possible when a process was created.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• CHANGELOG.md updated for non-trivial changes.
• schema-next.yaml updated with changes to existing conventions.

[mx-psi]

LGTM but needs a few updates to make CI pass

[joaopgrassi]

@open-telemetry/semconv-system-approvers please take another look

[mx-psi]

Blocking to avoid merge since we want to discuss this with semconv after the WG meeting yesterday

[mx-psi]

One of the points of discussion was the fact that the hostmetrics receiver has different scrapers process and processes https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver#getting-started and that this rename causes the metrics to have a namespace that does not match its scraper. Some previous discussion about the rationale for the namespace can be found at #212 (comment)

[ChrsMark]

@trask any thoughts on #484 (comment)?

[ChrsMark]

Trying to summarize our options here (outcome from discussions on last week's System WG meeting):

Option 1: Reconsider the pluralization rule for namespaces based on the inconsistency with Otel collector implantation mentioned at #484 (comment). Feedback from @trask
on this would be really valuable.

Option 2: Accept this PR. Change Otel Collector's implementation so as conventionally to be aligned with the namespace pluralization rule of SemConv. This means that we change processes and process scrapers. cc: @braydonk @dmitryax

Option 3: Accept this PR. Keep the pluralization rule as is as well as the current Collector's implementation but add a note in the rule and the collector to clarify that system.process.* is for aggregated metrics while process.* is for metrics of a single resource. This is a "lighter" version if option2.

Update:

Note that for option 3 we need to verify if it is aligned in general with how Collector uses system.* metrics. For example the Collector emits system.cpu.* metrics which are per CPU.

From my perspective the implementation detail that processes scraper will use the system.process.* namespace for aggregated process metrics of the system does not seem quite problematic. In the future the same scraper might emit additional metrics under a completely different namespace.

@open-telemetry/semconv-system-approvers could you have another look and provide your feedback here?

[mlunadia]

this rename causes the metrics to have a namespace that does not match its scraper

Option 1. Whilst I understand it would be nice to have consistency with the Otel collector implementation, enforcing this results in surfacing unnecessary implementation details to users.

IIUC the push for consistency of scraper need to match the namespace would apply across. There are areas where this would result in namespaces that many users would not necessarily be familiar with eg. kubelestats receiver: namespace would need to be k8s.kublet.* or k8s.kubeletstats.* (?) to match the relevant scraper when these are metrics related to node, pod, container, and volume.

Options 2&3. I don't have strong opinions on either of these two options because they are more focused on the implementation without affecting the user experience.

@jsuereth this comment is in addition to the reasoning of CPU not being plural as discussed at the last semcon SIG meeting.

[trask]

@trask any thoughts on #484 (comment)?

the trouble seems to stem from having process.* (Process Metrics) and system.process.* (Aggregate System Process Metrics)

what do you think of naming the scrapers

• process - capturing aggregated system.process.*, since this matches the naming for all the others, e.g. network, cpu, etc
• process_detail - capturing process.* metrics (per-process metrics)

[ChrsMark]

From the discussion on Thursday's System WG meeting(Dec 14th):

We are good to go with this PR. Collector(hostmetricsreceiver)'s maintainers will figure out the implementation details but from SemConv point of view there is no reason to block this change/PR.

cc: @dmitryax @braydonk @jsuereth

[braydonk]

maintainers will figure out the implementation details

Yes, I won't get into too much detail but to clarify I am planning to merge the process and processes scraper, such that just the process scraper produces both process and system.process metrics.

Discussion was resolved

[jsuereth]

Can you rebase your CHANGELOG / Schema-next changes? They appear to have moved into the release :)