Azure Monitor Exporter: treat UNSPECIFIED span kind as INTERNAL #844
Conversation
This file contains hidden or 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
The Azure Monitor exporter translates spans to different objects depending on the span kind. It used to return an error if the span kind is set to UNSPECIFIED. This makes sense, because we don't know how to translate those spans. However this can cause problems when trying to get 3rd party applications to participate in the distributed tracing. One example is NGINX, which supports OpenTracing through the nginx-opentracing plugin. However it does not report a span kind, which means spans reported by NGINX are not exporter to Azure Monitor. This changes the Azure Monitor exporter to treat unspecified span kinds as INTERNAL. While this is not perfect, it does at least report some data for these spans.
Codecov Report
@@ Coverage Diff @@
## master #844 +/- ##
==========================================
+ Coverage 88.17% 88.25% +0.08%
==========================================
Files 232 232
Lines 12404 12404
==========================================
+ Hits 10937 10947 +10
+ Misses 1114 1108 -6
+ Partials 353 349 -4
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
I'm good with this change because I'm struggling with this exact problem myself with nginx! I made this decision based on how I read the spec. For HTTP, gRPC, Database calls, etc. SpanKind is definitely required, but for other types possibly not yet hard to tell. |
pcwiese
approved these changes
Aug 28, 2020
pjanotti
approved these changes
Aug 29, 2020
dyladan
referenced
this pull request
in dynatrace-oss-contrib/opentelemetry-collector-contrib
Jan 29, 2021
Translation was replicated from existing jaeger -> OC -> internal logic.
ljmsc
referenced
this pull request
in ljmsc/opentelemetry-collector-contrib
Feb 21, 2022
…matic Github workflow (#844)
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.
Description:
The Azure Monitor exporter translates spans to different objects depending on the span kind. It currently returns an error if the span kind is set to UNSPECIFIED. This makes sense, because we don't know how to translate those spans.
However this can cause problems when trying to get 3rd party applications to participate in the distributed tracing. One example is NGINX, which supports OpenTracing through the nginx-opentracing plugin. However it does not report a span kind, which means spans reported by NGINX are not exported to Azure Monitor.
This changes the Azure Monitor exporter to treat unspecified span kinds as INTERNAL. While this is not perfect, it does at least report some data for these spans.
@pcwiese Does this change make sense for you? What was the original reason to return an error for unspecified span kind?
Testing:
Added unit test to check that spans with unspecified span kind are treated like internal spans.