Same SpanID, ParentID and TraceID in every span in different services about zipkin-js

[eirslett]

That's correct behavior. When you have only one span, all the ids in the trace will be the same. There are two services/nodes (I'll call them nodes, since not all points in the graph have to be services) here, but only one span, because a span represents the interaction between two nodes.
If you introduce a third node, for example a web browser, which calls the first service, then there will be two spans in the trace.

[codefromthecrypt]

Great explanation, Eirik

On 30 Aug 2016 3:50 am, "Eirik Sletteberg" [email protected] wrote:

That's correct behavior. When you have only one span, all the ids in the
trace will be the same. There are two services/nodes (I'll call them nodes,
since not all points in the graph have to be services) here, but only one
span, because a span represents the interaction between two nodes.
If you introduce a third node, for example a web browser, which calls the
first service, then there will be two spans in the trace.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#38 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD61x-GF2yp6vfraB8mBV5S5mrI15H9ks5qkzftgaJpZM4Jvj6a
.

[eirslett]

Usually, you would see a setup like this:

browser -> front-facing webapp -> microservice 1 -> microservice 2 -> database

Then, the root span would be "front-facing webapp" in the Zipkin UI. So even if the trace is triggered by the browser, the span starts at the first service.

[ppwfx]

Ah awesome, got it, thanks :)

However, the Zipkin UI span detail does not seem as expressive as imagined to me. Intuitively I would have expected the root span to be the top span. Right now the only way to see what's the root service is by looking at the url or opening the top span.

Also the metadata of the spans are emitted twice.

I can totally live with both, I just want to make sure that it's the intended behaviour. Can you confirm that?

Btw, it's an awesome tracing solution, happy I came across!

[codefromthecrypt]

mind posting your example? or modifying this?
openzipkin/zipkin-js-example#1

You should see a root span, for sure..

On Tue, Aug 30, 2016 at 4:51 PM, 21stio [email protected] wrote:

Ah awesome, got it, thanks :)

However, the Zipkin UI span detail does not seem as expressive as imagined
to me. Intuitively I would have expected the root span to be the top span.
Right now the only way to see what's the root service is by looking at the
url or opening the top span.
[image: screen shot 2016-08-30 at 10 47 52]
https://cloud.githubusercontent.com/assets/17232576/18082445/48b3ab58-6e9f-11e6-9ddd-c2818ac2520f.png

Also the metadata of the spans are emitted twice.
[image: screen shot 2016-08-30 at 10 48 00]
https://cloud.githubusercontent.com/assets/17232576/18082456/4db2968c-6e9f-11e6-8764-4f021bad6313.png

I can totally live with both, I just want to make sure that it's the
intended behaviour. Can you confirm that?

Btw, it's an awesome tracing solution, happy I came across!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#38 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD610QvOHnaqnaC-1Y3NUgo2Om1bfDqks5qk-8ugaJpZM4Jvj6a
.

[ppwfx]

Hey,

I ran another test I finally understood how it's working. The service that will be hit first is the root span even if the service that triggers the request itself is traced.

root service is root span
Browser -> root service -> child_one -> child_two

child_one is root span
root service -> child_one -> child_two

Thanks a lot guys! :)