[translator/jaeger] Add refType as attribute to link when translating Jaeger spans to OTEL #14463
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
alejandrodnm
commented
Sep 23, 2022
| @@ -27,6 +27,7 @@ import ( | |||
| "go.opentelemetry.io/collector/pdata/pcommon" | |||
| "go.opentelemetry.io/collector/pdata/ptrace" | |||
| conventions "go.opentelemetry.io/collector/semconv/v1.6.1" | |||
| conventions1_9 "go.opentelemetry.io/collector/semconv/v1.9.0" | |||
There was a problem hiding this comment.
I would like some guidance on this part. Could we just migrate to v1.9.0?
There was a problem hiding this comment.
Ive no exp with that. @Aneurysm9, @jpkrohling could you give some input (noticed you updated the documentation in the past)?
There was a problem hiding this comment.
If v1.6.1 does not contain the required attribute then migrate to a version that does. There should generally only be one version of the semantic conventions imported into any given module.
There was a problem hiding this comment.
I updated the files to only use v1.9.0
alejandrodnm
changed the title
alejandrodnm
changed the title
alejandrodnm
changed the title
jpkrohling
requested review from
frzifus
and removed request for
bogdandrutu
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Sep 30, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
2 tasks
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Sep 30, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 2, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 3, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
2 tasks
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 3, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 3, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 3, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 4, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 4, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 4, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 5, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 5, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
force-pushed
the
adn/jaeger-reftype
branch
from
1edb6c3
to
b8090ba
Compare
|
I'm adding this to my review queue. |
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 14, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Oct 14, 2022
Jaeger, like OpenTracing, uses identifies the type of references between Spans. There are only two types of references `CHILD_OF` and `FOLLOWS_FROM`. OTEL doesn't have an analogous to Jaeger reference type in their link specification. An OTEL span can have only one parent, and that's set as an attributed of the span instead of an OTEL link. When using the Jaeger to OTEL translator the first reference with type `CHILD_OF` is used to set the OTEL span parent attribute, all other references are converted to links, and since there is no notion of reference type that information is lost. On the reverse transformation, OTEL to Jaeger, the OTEL Span parent is converted to a reference with `CHILD_OF` type, while all the other OTEL links are converted to `FOLLOWS_FROM` references. The problem is that Jaeger, unlike OTEL, supports the notion of multiple parents (one use case is fork/join workloads), running this multi-parent through the translator and back returns a span with a single parent with all the other parents turned into `FOLLOWS_FROM` references. There's an open PR in the translator to keep this information by adding the type as attribute to the links following the semantic convention for OpenTracing compatibility: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#OpenTracing open-telemetry/opentelemetry-collector-contrib#14463 While that gets merge we are going to be manually setting the reference type as an attribute on the links when writing traces. On the retrieving traces side, we'll be using those attributes to set the corresponding reference type when constructing the Jaeger traces responses.
jpkrohling
approved these changes
Oct 18, 2022
|
Sorry for taking so long to review this one. Looks like some checks are failing, once they are addressed, this is ready to be merged. |
alejandrodnm
force-pushed
the
adn/jaeger-reftype
branch
from
b8090ba
to
47870de
Compare
Following OTEL's trace semantic conventions for Opentracing traces. When creating a link the attribute `opentracing.ref_type` will be set with one of the accepted values, either `child_of` or `follows_from`. This enables the translator to maintain reference context that enable features. For example, Jaeger multiple parents for spans. https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#opentracing
alejandrodnm
force-pushed
the
adn/jaeger-reftype
branch
from
47870de
to
9c61b3b
Compare
|
Hi @jpkrohling I need you to approve running the workflow :) There was a breaking change in one of the APIs I was using that was merged to master, that's why it was failing. |
|
CI started. |
|
Thanks @jpkrohling it seems all the tests are passing :) |
codeboten
approved these changes
Oct 27, 2022
shalper2
pushed a commit
to shalper2/opentelemetry-collector-contrib
that referenced
this pull request
Dec 6, 2022
… Jaeger spans to OTEL (open-telemetry#14463) Add refType as attribute to link Following OTEL's trace semantic conventions for Opentracing traces. When creating a link the attribute `opentracing.ref_type` will be set with one of the accepted values, either `child_of` or `follows_from`. This enables the translator to maintain reference context that enable features. For example, Jaeger multiple parents for spans. https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#opentracing
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Dec 23, 2022
This version includes the changes to the Jaeger translator that support multi ChildOf references to the links. open-telemetry/opentelemetry-collector-contrib#14463 We used to do this before translating to OTEL and after translating from OTEL, in order to keep this information and pass the Jaeger certification tests.
2 tasks
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Dec 23, 2022
This version includes the changes to the Jaeger translator that support multi ChildOf references to the links. open-telemetry/opentelemetry-collector-contrib#14463 We used to do this before translating to OTEL and after translating from OTEL, in order to keep this information and pass the Jaeger certification tests.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Dec 23, 2022
This version includes the changes to the Jaeger translator that support multi ChildOf references to the links. open-telemetry/opentelemetry-collector-contrib#14463 We used to do this before translating to OTEL and after translating from OTEL, in order to keep this information and pass the Jaeger certification tests.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Dec 23, 2022
This version includes the changes to the Jaeger translator that support multi ChildOf references to the links. open-telemetry/opentelemetry-collector-contrib#14463 We used to do this before translating to OTEL and after translating from OTEL, in order to keep this information and pass the Jaeger certification tests.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Jan 11, 2023
This version includes the changes to the Jaeger translator that support multi ChildOf references to the links. open-telemetry/opentelemetry-collector-contrib#14463 We used to do this before translating to OTEL and after translating from OTEL, in order to keep this information and pass the Jaeger certification tests.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Jan 11, 2023
This version includes the changes to the Jaeger translator that support multi ChildOf references to the links. open-telemetry/opentelemetry-collector-contrib#14463 We used to do this before translating to OTEL and after translating from OTEL, in order to keep this information and pass the Jaeger certification tests.
alejandrodnm
added a commit
to timescale/promscale
that referenced
this pull request
Jan 11, 2023
This version includes the changes to the Jaeger translator that support multi ChildOf references to the links. open-telemetry/opentelemetry-collector-contrib#14463 We used to do this before translating to OTEL and after translating from OTEL, in order to keep this information and pass the Jaeger certification tests.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following OTEL's trace semantic conventions for Opentracing traces. When creating a link the attribute
opentracing.ref_typewill be set with one of the accepted values, eitherchild_oforfollows_from.This enables the translator to maintain reference context that enable features. For example, Jaeger multiple parents for spans.
https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/compatibility/#opentracing
Testing:
Unittest have been up updated to include the case when a span has 2 parent spans. Assertions are made for:
opentracing.ref_typeto Jaeger traces the correct refType is created.The usage of these attributes and the multiple parents use case was discussed with the Jaeger maintainers, see jaegertracing/jaeger#3919 (comment) for more context.
resolves #14465