Consistent way to specify metric source

[dmitryax]

Is your feature request related to a problem? Please describe.
It would be great to have a consistent way to specify a source (receiver) of collected metrics. For example, kubeletstats receiver uses "receiver" resource label for that https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/master/receiver/kubeletstatsreceiver/kubelet/metrics.go#L51 . But I don't see any other receivers doing it.

Describe the solution you'd like
It seems pretty useful to have metrics source information, so would be nice to come up with a unified way of doing that.

Describe alternatives you've considered
We can decide that it's not needed, then we should remove it from kubeletstats receiver

[jrcamp]

As far as I can tell we're not setting instrumentation library name or version for metrics that we're emitting from the collector (ie hostmetricsreceiver, redis, etc. vs metrics passing through that were generated in some other source). Perhaps these should set instr. library name and version? Are there any conventions around the name? Didn't see any in the spec.

One option:

Name: opentelemetry-collector/${RECEIVER_NAME}
Version: ${BUILD_NUMBER}

In the spec above it says attributes may be added at some point, which I think is the ideal place for the receiver name to live with name just being opentelemetry-collector (or similar).

[dmitryax]

I agree with @jrcamp . I makes sense to keep that info in metrics instrumentationLibrary. @bogdandrutu @tigrannajaryan do you have any thoughts on this?

[tigrannajaryan]

Is this about Collector's self metrics? I am not sure I understand.
Any justification on why we need this?

[jrcamp]

It can be helpful for support purposes to know who the emitter of the metrics are and what version of it is sending. Maybe you have redis metrics coming from a Prometheus exporter that have been renamed to be the same as the redis metrics from the redis receiver you might want to be able to differentiate between them. Or for just metrics coming from the redis receiver maybe there was a bug in 1.1 that was fixed in 1.1.1. Being able to know the version of the emitter can be very helpful.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 120 days if there is no activity.

[github-actions]

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