Opentelemetry-specification: How do people use Instrumentation Library?

[anuraaga]

I was reminded this by #989 and it relates to #823. The issue of cost of exporting instrumentation library to zipkin / jaeger came up in #989 so I'm curious - how do people use this field? I personally can't come up with a use case TBH. We have semantic conventions for real data. Handling spans in the backend based on what attributes are present, rather than what instrumentation reported them, seems most practical and fits with best practices we see in the browser like using feature detection instead of user agent parsing.

So curious, how do people use this field? Is it so important that we require non-OTLP exporters to send this information? I'm worried it's cost with no value for these other protocols, that the users end up paying.

Since #823 is marked post GA, does it make sense for non-OTLP export semantics to be kept unstable post GA? That would make me less worried about the story for them.

[Oberon00]

I personally can't come up with a use case TBH.

Please read the OTEP: https://github.com/open-telemetry/oteps/blob/master/text/0016-named-tracers.md

The main use case (which is still only a vision I think) is to be able to disable instrumentations or discard their data based on that. It's a robustness mechanism that would not be needed if everything runs smoothly.

[anuraaga]

It's interesting that the point that made me think about this is because OTel will spam backends like Zipkin with this data :) Can we consider this an aspect of OTLP (if a backend is going to use this for protection, they will speak OTLP) and not deal with it in non-OTLP exporters where presumably the data won't be used?

[iNikem]

It loosely resembles Jaeger "component" tag and can be used as a quick clue during debugging about which component/instrumentation produces such strange data (or does not). Even during development seeing spans from which instrumentation I receive and which not helps me tremendously in understanding, what is going on

[jkwatson]

Echoing what @iNikem said: having the ability to see (in your tracing UI) what instrumentation is causing errant spans, and then to disable that instrumentation by name seems like a huge value-add for people supporting OpenTelemetry installations.

[iNikem]

@anuraaga was your question answered? Can we now close this issue?

[anuraaga]

Yeah I think that's helpful, thanks