You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: