In open-telemetry/opentelemetry-specification#1904 the span attribute messaging.rocketmq.version was proposed to report the version of the RocketMQ client library being used for producing or consuming a message.
Would it make sense to have generic attributes for the name and version of the instrumented library instead?
The instrumentation library is already reported via the tracer or meter name. See https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md#instrumentation-libraries and https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md#instrumentation-library for definitions and details.
If the instrumented library comes with instrumentation built-in, the instrumentation library will already match what we are looking for here.
If instrumentation is provided by a separate instrumentation library, however, we have no information about the library being used.
Most applications will be composed of multiple libraries but usually there should be a clear "top of stack" library that is the most relevant for a particular span, that would be the one to report here.
An alternative would be to just report all detected libraries as resource attributes but this will likely not be suitable for all languages and also multiple languages could be candidates to be "responsible" for a certain span, so a span attribute would likely make more sense.
In open-telemetry/opentelemetry-specification#1904 the span attribute
messaging.rocketmq.versionwas proposed to report the version of the RocketMQ client library being used for producing or consuming a message.Would it make sense to have generic attributes for the name and version of the instrumented library instead?
The instrumentation library is already reported via the tracer or meter name. See https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md#instrumentation-libraries and https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md#instrumentation-library for definitions and details.
If the instrumented library comes with instrumentation built-in, the instrumentation library will already match what we are looking for here.
If instrumentation is provided by a separate instrumentation library, however, we have no information about the library being used.
Most applications will be composed of multiple libraries but usually there should be a clear "top of stack" library that is the most relevant for a particular span, that would be the one to report here.
An alternative would be to just report all detected libraries as resource attributes but this will likely not be suitable for all languages and also multiple languages could be candidates to be "responsible" for a certain span, so a span attribute would likely make more sense.