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

Add translation of InstrumentationLibraryInfo to Jaeger #801

Merged
merged 4 commits into from Aug 19, 2020

Conversation

iNikem
Copy link
Contributor

@iNikem iNikem commented Aug 13, 2020

Changes

Add rules for translating InstrumentationLibraryInfo from OTLP to Jaeger.

@iNikem iNikem requested review from a team as code owners August 13, 2020 19:29
@tigrannajaryan
Copy link
Member

See my comment #800 (comment)

I think it is best to define conventions for all OTLP fields that will be applicable to all other protocols, instead of defining it individually for every protocol (which results in a duplicate like we can see here for Jaeger and in the other PR for Zipkin).

@bogdandrutu
Copy link
Member

@tigrannajaryan some fields are duplicate indeed, but majority are not. And some protocols needs a specific translation for a field "foo" as attribute in a Span but others may have "Process" like Jaeger.

@tigrannajaryan
Copy link
Member

@tigrannajaryan some fields are duplicate indeed, but majority are not. And some protocols needs a specific translation for a field "foo" as attribute in a Span but others may have "Process" like Jaeger.

How about we have a "common" section that is applicable to all protocols, and then individual sections for each protocol that has some specific handling (like Jaeger's Process)?

@iNikem
Copy link
Contributor Author

iNikem commented Aug 14, 2020

@tigrannajaryan @bogdandrutu Is it Ok if I create a follow up issue about extracting common translation rules (I may assign it myself) and in the meantime we can merge this and #800 ? I think these two PRs are already useful and make a small step forward. Preparing common document will take more time from me to familiarise myself with protocols.

@SergeyKanzhelev
Copy link
Member

I will close and re-open PR for auto-assignment

@tigrannajaryan
Copy link
Member

@tigrannajaryan @bogdandrutu Is it Ok if I create a follow up issue about extracting common translation rules (I may assign it myself) and in the meantime we can merge this and #800 ? I think these two PRs are already useful and make a small step forward. Preparing common document will take more time from me to familiarise myself with protocols.

Sounds good. I can also help with that issue.

@iNikem
Copy link
Contributor Author

iNikem commented Aug 14, 2020

Created #806 as a follow-up

@iNikem
Copy link
Contributor Author

iNikem commented Aug 14, 2020

@SergeyKanzhelev do you still want to block this PR?

@SergeyKanzhelev
Copy link
Member

swapped issue with @yurishkuro as Yuri might have more context here to merge

@bogdandrutu
Copy link
Member

@yurishkuro can you confirm is ok? Not too much text but we can have this as a starting point :)

specification/trace/sdk_exporters/jaeger.md Outdated Show resolved Hide resolved
| OpenTelemetry | Jaeger |
| ------------- | ------ |
| `InstrumentationLibrary.name`|`otel.instrumentation_library.name`|
| `InstrumentationLibrary.version`|`otel.instrumentation_library.version`|
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not follow why we need to change the naming convention when translating to Jaeger. Jaeger backend has very few semantic conventions that it recognizes, this one is certainly not one of them, so it would make no difference if the attributes were to be translated as is. Not to mention that we plan to align Jaeger with OTel data model and conventions directly in the future.

Separately, where did the strings InstrumentationLibrary.name come from? I spot-checked https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/trace/semantic_conventions and they all seem to use snake_case.snake_case naming, not PascalCase.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

InstrumentationLibrary.name is not an attributes. InstrumentationLibrary is a class that Tracer hold on to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand what do you mean by "change the naming convention when translating to Jaeger"?

First, as Sergey answered above, InstrumentationLibrary is not an attribute, this is a separate field in InstrumentationLibrarySpans protocol message.
Second, the same translation, to the same attribute names, was proposed, accepted and merged for OTLP->Zipkin transaltion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yurishkuro is this clear now?

@arminru arminru linked an issue Aug 19, 2020 that may be closed by this pull request
@yurishkuro yurishkuro merged commit a6dd3a1 into open-telemetry:master Aug 19, 2020
@iNikem iNikem deleted the library-info-jaeger branch August 19, 2020 18:59
MrAlias pushed a commit to open-telemetry/opentelemetry-go that referenced this pull request Sep 3, 2020
* Add InstrumentationLibrary info to Zipkin/Jaeger exporters

This addresses spec issues
 open-telemetry/opentelemetry-specification#800
 open-telemetry/opentelemetry-specification#801
and opentelemetry-go issues
 #1086
 #1087

* Reflect change in CHANGELOG
evantorrie added a commit to evantorrie/opentelemetry-go that referenced this pull request Sep 10, 2020
…metry#1119)

* Add InstrumentationLibrary info to Zipkin/Jaeger exporters

This addresses spec issues
 open-telemetry/opentelemetry-specification#800
 open-telemetry/opentelemetry-specification#801
and opentelemetry-go issues
 open-telemetry#1086
 open-telemetry#1087

* Reflect change in CHANGELOG
TommyCpp added a commit to TommyCpp/opentelemetry-rust that referenced this pull request Oct 4, 2020
TommyCpp added a commit to TommyCpp/opentelemetry-rust that referenced this pull request Oct 4, 2020
…ent version for Jaeger.

According to spec open-telemetry/opentelemetry-specification#800 and open-telemetry/opentelemetry-specification#801, We MUST export instrumentation library information for Jaeger and Zipkin exporter.

Use crate version as default Jaeger instrumentation library version in consistent with Zipkin.
jtescher pushed a commit to open-telemetry/opentelemetry-rust that referenced this pull request Oct 6, 2020
…ent version for Jaeger. (#243)

According to spec open-telemetry/opentelemetry-specification#800 and open-telemetry/opentelemetry-specification#801, We MUST export instrumentation library information for Jaeger and Zipkin exporter.
shbieng added a commit to shbieng/opentelemetry-go that referenced this pull request Aug 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add instrumentation library info as semantic convention attributes
6 participants