Allow adding a prefix to metric names

[jjzeng-seattle]

Knative needs to add a component name as the prefix to the matrix name. For example, of the metrics "request_count", we could have "activator/request_count" or "revision/request_count".

In opencensus, this is achieved by adding the option to each exporter. For example:

https://github.com/census-ecosystem/opencensus-go-exporter-prometheus/blob/master/prometheus.go#L170 https://github.com/census-ecosystem/opencensus-go-exporter-stackdriver/blob/master/metrics_proto.go#L413 and https://github.com/census-ecosystem/opencensus-go-exporter-ocagent/pull/84

Would it be better if opentelemetry provides a general way to do this so we don't need to fix every exporter?

[jmacd]

We've discussed this in the Metrics SIG call today. One point that was raised is that having a prefix will interfere with the use of semantic conventions for metric naming. We are working towards standardizing metric names, so supporting a standard prefix appears to conflict with our goals.

We think this kind of option would not make sense for OTLP exporters, in particular. For this reason, I suspect we should leave this option in the exporters, especially since different systems have different conventions for namespace prefixes.

[bogdandrutu]

Knative needs to add a component name as the prefix to the matrix name. For example, of the metrics "request_count", we could have "activator/request_count" or "revision/request_count".

Assumption: I think you refer to the "component" as one of the microservices running in the knative ecosystem? (not to a library inside the same binary).

1. Is that the case?
2. Are you planning to run the otel collector?
3. Why not having the component as a label?

[reyang]

Discussed during 09/14/2021 #199 Metrics SIG at 9am PT and concluded that we will not cover this before the initial Stable release. It can be a nice-to-have feature after the initial Stable release.