Should metric namespaces be restricted from also being metric names?

[trask]

Summarizing reasons for not introducing this restriction:

• allows more flexibility in naming metrics, e.g.
  • allows dropping .count suffixes for more concise metric names, e.g. system.processes instead of system.processes.count

Summarizing reasons for introducing this restriction:

• makes metrics documentation simpler for both author and reader
• consistency with same restriction on attribute namespaces
  • (the reason for attribute name restrictions was to leave open the possibility for attribute names to be represented as nested maps, simlar to ECS)
• allows converting bidirectionally between our dot-notation and common structured data formats such as json or yaml

I will update these summaries based on any comments made below.

[trask]

If "Option C" is chosen in #51 (comment), I think that this reason not introducing the restriction will no longer be relevant:

• allows dropping .count suffixes for more concise metric names, e.g. system.processes instead of system.processes.count

because system.processes.count has attribute state, which would implicitly become system.processes.state, while if the metric was system.processes, the attribute state would implicitly become system.state.

[reyang]

The TC voted and here is the result #51 (comment).

[trask]

@reyang this issue is about namespaces for instrument names as opposed to namespaces for attribute names, did the TC vote also on this? thx

[Oberon00]

To me this looks like a mix-up. Re-opening.