Opentelemetry-specification: Instrumented library version

Created on 7 Apr 2021  路  8Comments  路  Source: open-telemetry/opentelemetry-specification

What are you trying to achieve?
Similar to Instrumentation Library, I am trying to get the instrumented library version. In case of errors or issues, it can be very helpful to know the library version which was used.

So for example, if I'm using js ioredis auto instrumentation, I know that the instrumentation library version is 0.15.0, but I need to know that the ioredis version is 4.17.3.

Could not find a semantic convention attribute for this.
Was it discussed somewhere in the past maybe?

semantic-conventions trace

Most helpful comment

It's not specified, but the java instrumentation group has been appending the library version to the instrumentation name. So, like "ioredis-4.17.3" as the name, for example.

So the version of the instrumented library is matched with the name of the instrumenting library? This seems likely terribly confusing for users who aren't aware of this mismatch.

All 8 comments

It's not specified, but the java instrumentation group has been appending the library version to the instrumentation name. So, like "ioredis-4.17.3" as the name, for example.

It's not specified, but the java instrumentation group has been appending the library version to the instrumentation name. So, like "ioredis-4.17.3" as the name, for example.

Thanks,
Do you know what is the process for suggesting to add such an attribute to semantic conventions?
Is it done via Issues? or via oteps

It's not specified, but the java instrumentation group has been appending the library version to the instrumentation name. So, like "ioredis-4.17.3" as the name, for example.

Thanks,
Do you know what is the process for suggesting to add such an attribute to semantic conventions?
Is it done via Issues? or via oteps

You have taken the perfect first step by creating this issue. Thanks!

It's not specified, but the java instrumentation group has been appending the library version to the instrumentation name. So, like "ioredis-4.17.3" as the name, for example.

So the version of the instrumented library is matched with the name of the instrumenting library? This seems likely terribly confusing for users who aren't aware of this mismatch.

Isn't the version in the instrumentation library name for Java just the lowest version supported by the instrumentation? https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/contributing/writing-instrumentation.md#folder-structure

It's not specified, but the java instrumentation group has been appending the library version to the instrumentation name. So, like "ioredis-4.17.3" as the name, for example.

So the version of the instrumented library is matched with the name of the instrumenting library? This seems likely terribly confusing for users who aren't aware of this mismatch.

I don't understand the question. The instrumenting library in this case is the java agent, which has a version (like 1.0.0, for example). It seems clear that this is the right value.

Isn't the version in the instrumentation library name for Java just the lowest version supported by the instrumentation? https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/contributing/writing-instrumentation.md#folder-structure

yes, I was oversimplifying a bit. Thanks for the clarification.

Hi,
So how can I move forward with this?

I think the main issue that needs to be addressed is how to handle instrumentation library (or span) which is instrumenting multiple packages at once (most likely related, but not necessarily). In this case, the attribute will need to an array of package name and version. Another option is to state that one module version should be captured, which is the one that best suite the use-case.

Another issue in my opinion is whether this data should be set as span attribute, or it should be in a separate span property (like instrumentationLibrary).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

iNikem picture iNikem  路  4Comments

pavolloffay picture pavolloffay  路  4Comments

toumorokoshi picture toumorokoshi  路  3Comments

yurishkuro picture yurishkuro  路  5Comments

Oberon00 picture Oberon00  路  4Comments