Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify how exporters should deal with invalid instrumentation library names #1554

Open
Oberon00 opened this issue Mar 17, 2021 · 4 comments
Labels
area:sdk Related to the SDK spec:trace Related to the specification/trace directory

Comments

@Oberon00
Copy link
Member

Oberon00 commented Mar 17, 2021

Since #1534 / #1472, we pass on invalid (i.e. null/empty) instrumentation library names to the exporter. We should specify how specific exporters should deal with it. In my opinion, the goal should be to alert users that they are making a mistake when they decline (not forget: the null/empty string has to be explicitly passed) to specify an instrumentation library name. So I would suggest:

  • OTLP: Probably pass it on as-is, but add SHOULD/MUST-requirement for consumers (e.g. collector when translating to other protocol) to alert users somehow.
  • Jaeger/Zipkin: Replace with "<INSTRUMENTATION LIBRARY NAME MISSING>" or similarly screaming string.
@Oberon00 Oberon00 added area:sdk Related to the SDK spec:trace Related to the specification/trace directory labels Mar 17, 2021
@carlosalberto
Copy link
Contributor

@yurishkuro @anuraaga do you have any opinion about Jaeger and Zipkin handling of this, respectively?

@yurishkuro
Copy link
Member

Jaeger has no requirements on instrumentation library name, it only requires service name. I assume the same holds for Zipkin. So I am not clear what value a long screaming string would provide. I would simply omit setting this on the spans.

@Oberon00
Copy link
Member Author

Jaeger has no requirements on instrumentation library name,

But OpenTelemetry has. And in #1534 / #1472 it was decided that the backend is responsible for showing the error message to the user. Since I don't think Jaeger/Zipkin will add special support for the OTel library names, the last point in the chain where we can add the error message is the exporter.

So I am not clear what value a long screaming string would provide.

It will urge users to put in place an instrumentation library name, therefore stop calling the OpenTelemetry getTracer API with invalid arguments.

@yurishkuro
Copy link
Member

backend is responsible for showing the error message to the user

I don't think this is stated anywhere as a requirement. Most users won't even care about this value, I think the main persona who cares is someone who's investigating instrumentation issues, and for them the absence of this value tells as much as a long screaming string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:sdk Related to the SDK spec:trace Related to the specification/trace directory
Projects
None yet
Development

No branches or pull requests

3 participants