-
Notifications
You must be signed in to change notification settings - Fork 569
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
Fix Jaeger exporter to correctly translate span.kind attribute #1329
Fix Jaeger exporter to correctly translate span.kind attribute #1329
Conversation
@@ -226,7 +234,7 @@ def _translate_to_jaeger(spans: Span): | |||
[ | |||
_get_long_tag("status.code", status.status_code.value), | |||
_get_string_tag("status.message", status.description), | |||
_get_string_tag("span.kind", span.kind.name), | |||
_get_string_tag("span.kind", _otlp_to_jaeger_span_kind(span.kind)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be mapping OTLP status values to OpenTracing status values. Most values being the same string with different case is just coincidence or a historical artifact IMO. Also, OTLP defines the values as an enum with numeric values. The name is just a label which may change in future. Considering this, I've replaced kind.name
with a otlp > jaeger mapping even if they look very similar.
cf2b08d
to
0900235
Compare
@@ -299,6 +309,13 @@ def _convert_int_to_i64(val): | |||
return val | |||
|
|||
|
|||
def _otlp_to_jaeger_span_kind(kind: SpanKind) -> str: | |||
jaeger_kind = OTLP_JAEGER_SPAN_KIND.get(kind, "") | |||
if not jaeger_kind: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Would it be better to explicitly check for INTERNAL
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thinking was that some users or distributions might have custom values for the kind attribute so this would take care of all unknown cases including INTERNAL
which is unknown as far as Jaeger/OpenTracing is concerned but looks like the spec and API do not support that (even if it is not enforced). So I'm replacing it with a map and adding a test case to ensure all possible values are mapped.
@@ -299,6 +309,13 @@ def _convert_int_to_i64(val): | |||
return val | |||
|
|||
|
|||
def _otlp_to_jaeger_span_kind(kind: SpanKind) -> str: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests for this function?
@NathanielRN |
@lzchen We should be good, because this exporter stays in this repo. |
7ae7e89
to
3fa551b
Compare
According to opentracing semantic conventions, span.kind attribute should be one of the following four values: "server", "client", "producer", "consumer". The spec does not mention the casing of the strings but all examples show them in lower case. Moreoever, the OpenTelemetry collector recognizes these values only when they are lower case. Today if opentelemetry-python exports a span using the jaeger exporter to the OpenTelemetry collector, it loses the span.kind information. Using the debug logger exporter in the collector prints the following to the screen: Span #0 Trace ID : 31789e02d79452eaedb72769bed5fac7 Parent ID : a6398bc507d8a982 ID : 4a00eaa815e69785 Name : span Kind : SPAN_KIND_UNSPECIFIED Start time : 2020-11-03 18:06:29.684287 +0530 IST End time : 2020-11-03 18:06:29.684344 +0530 IST Status code : STATUS_CODE_CANCELLED Status message : Span #1 Trace ID : 31789e02d79452eaedb72769bed5fac7 Parent ID : ID : a6398bc507d8a982 Name : HelloWorldResource.on_get Kind : SPAN_KIND_UNSPECIFIED Start time : 2020-11-03 18:06:29.683881 +0530 IST End time : 2020-11-03 18:06:29.684421 +0530 IST Status code : STATUS_CODE_CANCELLED Status message : After the patch, span kind is correctly understood and represented by the collector: Span #0 Trace ID : 8e4aeaa621f7e67c813a9cf26c56a202 Parent ID : 13f4cc8db8dfe5b3 ID : e8032193bb9dca98 Name : span Kind : SPAN_KIND_INTERNAL Start time : 2020-11-03 18:03:39.964796 +0530 IST End time : 2020-11-03 18:03:39.964857 +0530 IST Status code : STATUS_CODE_CANCELLED Status message : Span #1 Trace ID : 8e4aeaa621f7e67c813a9cf26c56a202 Parent ID : ID : 13f4cc8db8dfe5b3 Name : HelloWorldResource.on_get Kind : SPAN_KIND_SERVER Start time : 2020-11-03 18:03:39.964335 +0530 IST End time : 2020-11-03 18:03:39.964936 +0530 IST Status code : STATUS_CODE_CANCELLED Status message :
3fa551b
to
41141c9
Compare
According to opentracing semantic conventions, span.kind attribute
should be one of the following four values: "server", "client",
"producer", "consumer". The spec does not mention the casing of the
strings but all examples show them in lower case. Moreoever, the
OpenTelemetry collector recognizes these values only when they are
lower case. Today if opentelemetry-python exports a span using the
jaeger exporter to the OpenTelemetry collector, it loses the span.kind
information. Using the debug logger exporter in the collector prints the
following to the screen:
After the patch, span kind is correctly understood and represented by
the collector:
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: