Add semantic convention for telemetry.auto.version

[iNikem]

Changes

In addition to the version of the SDK, I propose to add a resource semantic convention for the optional version of the auto instrumentation agent if that is used.

[tigrannajaryan]

LGTM

[SergeyKanzhelev]

should this be resource-wide or specific library-wide? Are we expecting mix and match of auto and non-auto telemetry in a single resource?

[iNikem]

This is resource-wide to report version of the auto instrumentation used in the given process. Library/trace-specific versions, which may differ from this version, are available as part of named Tracer/Meter

[SergeyKanzhelev]

Not a strong block. I think this attribute is very much java-auto-instr inspired. Would it be different in case of other languages where we might have auto and non-auto telemetry in a single resource? Or we will use separate resources in this situation?

[iNikem]

@SergeyKanzhelev I don't understand your concern about it being java-specific. Every language that uses auto instrumentation (.NET, js, ruby?) will probably end up in a situation when auto-instrumentation release version differs (if only in minor/patch parts) from the SDK version.

In general, we have up to 3 versions in play at every given time:

• Version of SDK. This is reported in resource as telemetry.sdk.version
• Version of auto instrumentation distribution, either reference one from OpenTelemetry project or from some vendor or just hand-rolled. This is reported in resource as telemetry.auto.version
• Version of a specific InstrumentationLibrary set during acquiring the Tracer. This is reported as part of the exported data

[carlosalberto]

cc @codeboten

[codeboten]

In general, we have up to 3 versions in play at every given time:

* Version of SDK. This is reported in resource as `telemetry.sdk.version`

* Version of auto instrumentation distribution, either reference one from OpenTelemetry project or from some vendor or just hand-rolled. This is reported in resource as `telemetry.auto.version`

* Version of a specific [InstrumentationLibrary](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/overview.md#instrumentation-libraries) set during [acquiring the Tracer](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#tracerprovider-operations). This is reported as part of the [exported data](https://github.com/open-telemetry/opentelemetry-proto/blob/master/opentelemetry/proto/trace/v1/trace.proto#L41)

I agree w/ @iNikem that this is not java specific. In the Python implementation, the opentelemetry-instrumentation package contains the auto-instrumentation interface and scripts, its version is independent of the SDK's.

[iNikem]

@SergeyKanzhelev do you still want to block this PR

[SergeyKanzhelev]

@SergeyKanzhelev I don't understand your concern about it being java-specific. Every language that uses auto instrumentation (.NET, js, ruby?) will probably end up in a situation when auto-instrumentation release version differs (if only in minor/patch parts) from the SDK version.

In general, we have up to 3 versions in play at every given time:

• Version of SDK. This is reported in resource as telemetry.sdk.version
• Version of auto instrumentation distribution, either reference one from OpenTelemetry project or from some vendor or just hand-rolled. This is reported in resource as telemetry.auto.version
• Version of a specific InstrumentationLibrary set during acquiring the Tracer. This is reported as part of the exported data

Sorry, wasn't very clear. My question is whether auto.version belongs to resource or not? What if resource sends telemetry via both - manual instrumentation and auto instrumentation. Should both carry the auto.version as resource attributes? Or it will be library version? Or those would be separate resources?

When I'm saying java specific, I mean that in Java there is not really manual instrumetnaiton when java agent present. java agent hijecks all instrumentation and adding auto.version to the resource is very logical

[trask]

in Java there is not really manual instrumentation when java agent present. java agent hijacks all instrumentation

Just a clarification, when the javaagent is present, there still is manual instrumentation.

It does replaces the SDK though, if one was brought by the user.

[iNikem]

Sorry, wasn't very clear. My question is whether auto.version belongs to resource or not? What if resource sends telemetry via both - manual instrumentation and auto instrumentation. Should both carry the auto.version as resource attributes? Or it will be library version? Or those would be separate resources?

telemetry.auto.version is global for the whole process, so it does not make sense to send it with every span. And thus resource was chosen as a place for this data. And I don't think there is any harm if even data sent by manual instrumentation from the process monitored by auto instrumentation agent will have this version in resource. See below for one reason. Second reason is that telemetry.auto.version still specifies the important piece of runtime environment: the presence and version of auto instrumentation agent.

In addition to this every span will have library info, which name will indicate the exact instrumentation library that has produced this span. Manual and auto instrumentation, I would assume, will use different names to get Tracer from TracerProvider. But this is out of the scope of this particular PR.

[SergeyKanzhelev]

In addition to this every span will have library info, which name will indicate the exact instrumentation library that has produced this span. Manual and auto instrumentation, I would assume, will use different names to get Tracer from TracerProvider. But this is out of the scope of this particular PR.

I agree that putting auto version into Library may be something we can decide to do in future. But this PR is not blocking us from doing it.

[iNikem]

@carlosalberto can it be merged now?

[SergeyKanzhelev]

no changes in spec for 2 working days and enough approvals. Merging