-
Notifications
You must be signed in to change notification settings - Fork 70
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
Did not discover dependencies for Zipkin v1 and v2 spans posted to Jaeger #84
Comments
Hi @albert5190, could you please paste here logs from spark-dependency job which didn't produce any results?
The referenced ticket does not show issues and the conversion to Jaeger model is correct. This repository contains e2e test with Zipkin data model https://github.com/jaegertracing/spark-dependencies/blob/master/jaeger-spark-dependencies-test/src/main/java/io/jaegertracing/spark/dependencies/test/DependenciesTest.java
Is it bookinfo from Istio project? What version? |
Hi @pavolloffay, Here is the spark-dependency job log for the Zipkin V1 json. It din't show anything interesting.
The reference ticket shows the span.kind value being reversed after normalizing from Zipkin v1 to Jaeger native span format. ie. the caller being server and callee being client. In the spark-dependency Java code isServerSpan() and isClientSpan() relies on span.kind value caller being client and callee being server. Yes, booking is from istio project. It is using Zipkin v2 data format. https://istio.io/docs/examples/bookinfo/
|
I don't think it's reserved in any case. See my comment in the thread. |
@pavolloffay I edited the previous comment with
Line 131 in 5828af5
|
Requirement - what kind of business use case are you trying to solve?
Posting Zipkin v1 and v2 spans to Jaeger collector should result in sparc-dependency discovering the dependencs in the incoming spans.
Problem - what in Jaeger blocks you from solving the requirement?
Steps to reproduce the problem:
null
data was added to the dependency table. ie. no dependency was discovered.The same problem occurred for this Zipkin v2 json.
zipkin-v2-bookinfo.txt
Note: Sending native Jaeger spans via Jaeger agent to the collect does not have this problem.
I could be wrong, but I suspect issue jaegertracing/jaeger#2067 may have something to do with it as the sparc-dependency Java code relies on span.kind value to determine the client/server relationship.
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: