Need attributes to identify Splunk distro name+version being used.

[owais]

SignalFx libraries added a couple of attributes to spans to help identify the SignalFx library and version being used. For example, signalfx-python-tracing v1.2.0 would add the following tags to all spans:

signalfx.tracing.library = signalfx-python-tracing
signalfx.tracing.version = 1.2.0

This helped us and the customers identify exact version of the tracing library being used when handling SWAT. This also gives us a very good idea about library adoption in the field.

OpenTelemetry semantic conventions have the following resource attributes to identify the Otel SDK and auto-instrumentation agent:

telemetry.sdk.language
telemetry.sdk.name
telemetry.sdk.version
telemetry.auto.version

In addition to these, Otel spans also contain information about the instrumentation library that generate the spans. These are translated to otel.library.name and otel.library.version when exporting the in any format other than OTLP.

With all these attributes in place a span generated by Otel's Falcon instrumentation will look like the following in Splunk APM:

telemetry.sdk.language: python
telemetry.sdk.name: opentelemetry
telemetry.sdk.version: 1.2.0
service.name: test-falcon-svc
telemetry.auto.version: 0.21b0
otel.library.name: opentelemetry.instrumentation.falcon
otel.library.version 0.21b0

As such, it is not possible to tell if a service was instrumented with a Splunk distribution (and it's version), stock Otel or a 3rd party distribution.

---

Proposal

I suggest all Splunk libraries add a new resource attribute called splunk.distro.version to help identify whether a Splunk distro is being used or not.

We can also propose telemetry.distro.name and telemetry.distro.version attributes to OpenTelemetry semantic conventions and switch to them once they're accepted.

[iNikem]

I am sure that telemetry.auto.version can and should be used to report the version of our distribution.

[owais]

I don't think it should be because:

• It is supposed to be the auto-instrumentation agent. Our distro may or may not implement a custom auto-instrumentation agent. Python for example uses opentelemetry-instrumentation as is and should capture the opentelemetry-instrumentation version in this field.
• If we ignore that and capture our library version, then we lose information about which version of auto-instrumentation agent was actually used. Might not be a problem for a language that bundles everything together but for languages that allow any compatible version to be used, it won't be possible to tell which version of the agent was used.
• If we decide that our library must be considered as the auto instrumentation engine, it still does not definitively tell us that our library is being used. Otel ecosystem is still young and it is relatively easy to tell which library is being used by just looking at the version number as versions are somewhat unique but a few months or years into Otel, it'll be impossible to tell for sure whether telemetry.auto.version==1.5 means 1.5 of splunk-otel-python, 1.5 of opentelemetry-instrument or 1.5 of some 3rd party, custom agent.

telemetry.auto.version: 1.5

We can tell which version of auto-instrumentation agent is used ^ but not which agent it is with certainty. As the ecosystem matures, it'll get harder and harder to deduce this information by looking at the version string.

In order to use this attribute we'll either need to add a telemetry.auto.name or add the name to the attribute value so that it looks like one of the following

telemetry.auto.version: splunk-otel-python v1.5

telemetry.auto.name: splunk-otel-python
telemetry.auto.version: 1.5

Neither of these are ideal as we lose out on the actual auto-instrumentation agent being used and it somewhat steps on the toes of Otel conventions.

[pellared]

I think what @owais proposal makes sense.
Java auto-instrumentation is different because it repackages the base OTel. I think most other ecosystems would have distro's as "extensions" or "easy-setup" libraries.

[owais]

PR: https://github.com/signalfx/gdi-specification/pull/94/files