-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
tag/span.kind server/client value seems to be reversed when processing Zipkin V1 json #2067
Comments
This indeed seems like a bug. I will have a look at it. |
@apm-opentt could you please paste here Zipkin V1 JSON with client and server span which is causing the issue? |
I wasn't able to reproduce this. This is zipkin spans v1: UI spans Data from ES: |
@pavolloffay Thanks for looking into this issue. I used your spans.txt and I did get the same output as your ui-spans.txt result. However, if I used this Zipkin V1 json I am getting the span.kind reversed. |
@pavolloffay any updates on this defect? Thanks. |
I do not see any error in the data you attached. The
|
I am closing this as it does not seem to be an issue. Feel free to comment/re-open if there is any other issues. |
@pavolloffay Here is the screen shot on Jaeger UI for the zipkin-v1-AtoB.txt https://github.com/jaegertracing/jaeger/files/4192948/zipkin-v1-AtoB.txt. It shows the span.kind being reversed. Can you help take a look? |
Hi @pavolloffay, did you get a chance to look at the screen capture above ^^. It looks like a defect to me. What do you think? If it is defect, can you reopen this issue? Thanks. |
It's not a defect in Jaeger, but in whichever instrumentation you're using. Specifically, in your screenshot the parent span ID is
As you can see, it's reporting itself as a "server" span, via "sr" (Server Receive) annotation. Jaeger is simply translating this into |
@yurishkuro, Thanks for helping to look at this issue. It is fair to question the source and validity of the json I posted to Jaeger collector's http endpoint in my previous comments. So let me use a json from an authoritative source. I am now posting the json from Zipkin's official page for V1 data format. https://zipkin.io/pages/data_model.html. I simply copied and paste the json in this page and send via http to Jaeger collect's v1 endpoint. Here is what Jaeger UI shows. One would expect the parent spans to have span.kind == client and children spans to have span.kind == server. It would be consistent with the behavior for spans that came from Jaeger agents. However, as you can see in screen capture the span.kind is reversed for Zipkin v1 json. (Note: Zipkin v2 json produced spans are consistent with spans from Jaeger agents). |
The last screenshot looks fine to me, while your red annotations are incorrect (and don’t match your diagram). |
I think it is correcnt because span with |
@pavolloffay @yurishkuro Thank you for patiently answering my questions. This may or may not be an issue, but I would like to understand why the span.kind value is different with different input json. I was under the impression that the root span should always have tag span.kind=client. Here I am sending the spans.txt from Pavol's comment to this issue #2067 (comment) and here is the resulting Jaeger UI screen capture. You can see that the root span has span.kind=client and child span has span.kind=server which is different than the screen capture in my previous post. Can you help explain the inconsistency? |
Jaeger does not make decisions which span is client or server, it simply renders what instrumentation reports. The correct value for instrumentation to use depends on the role of the particular span - if you're making an outbound call, the span should be "client" kind. It has no relation to being root or not - root is simply where the trace originates, which can be in either states. |
Requirement - what kind of business use case are you trying to solve?
I am testing sending Zipkin V1 and V2 span json to Jaeger Collector via http. Jaeger converts the Zipkin span json to Jaeger format and stores that in Cassandra. I expected the converted json in Jaeger format to be consistent in meaning for both V1 and V2 Zipkin json.
Problem - what in Jaeger blocks you from solving the requirement?
Consider the scenario service A calls service B. One would expect A's
span.kind
value to beclient
and B'sspan.kind
value to beserver
. Indeed when I send a V2 Zipkin json, this is true. However, When I send a V1 Zipkin json the Jaeger converted span has A'sspan.kind
equal toserver
and B'sspan.kind
equal toclient
.Note: For V1, I posted to
/api/v1/spans
endpoint and for V2 I posted to/api/v2/spans
endpoint.You can reproduce this issue by sending the V1 Zipkin json from https://zipkin.io/pages/data_model.html. Here is the converted span produced by Jaeger. Can you help confirm if this is an issue? If not, can you help explain why V1 Zipkin spans are converted this way?
Proposal - what do you suggest to solve the problem or improve the existing situation?
Any open questions to address
The text was updated successfully, but these errors were encountered: