Graph construction is unclear with current form of traceparent / tracestate

[falenn]

After reading https://github.com/w3c/trace-context/blob/master/trace_context/HTTP_HEADER_FORMAT.md, it is unclear to me how a directed graph of spans is created without conveying the parentSpanId. My current bias / point-of-view is OpenCensus / Zipkin with B3 header information. Here, the traceparent contains a traceId and spanId among other features, but it is unclear as to how these Ids render a graph.

I take trace-id to be the Id describing the context of a singular end-to-end interaction of services invoked to answer a request initiated by a customer (caller). Each step and possibly sub-steps of that chain of service invocations are called spans, described by their ids. The graph of the trace when exported requires chaining sub-spans to spans and finally to the trace-id. Correct?

If this is correct, I am then confused by the lack of the parentSpan-id in the traceparent.

When reading about the tracestate, I become even more confused.

In my mind, systems implement their own form of tracing. For instance, Netflix has their own tracing apart from something I might build. Vendoring information is interesting, but actually seems irrelevant if all tracing export information flows out-of-band from my system implementation into my tracing correlation system. Of course, the systems I build use an exporter that implement the export format my tracing system handles. I doubt that Netflix would ever contribute internal tracing information into my tracing system, nor would I into theirs. Am I thinking about this correctly?

Secondly, the tracestate contains random info. Is this really the id of the currentspan and the span-id in the traceparent the parentSpan? This is to say, is the vendoring information required to build the graph? Again, B3 spec is my mental model.

Another thought on distributed tracing as a whole. Distributed tracing in a federated enterprise can definitely leverage the vendoring information for system identification and requires concepts of variable sampling participation due to strange-attractor load effects (as networks expose highly-connected vertices). A Federated enterprise would also desire a consolidated, correlated tracing service, implying some form of IT governance and export endpoint advertisement. Distributed tracing in the wild, however, not-so-much. In either case, sparse tracing is still valuable as this tracing should still synthetically expose external service call impact on a trace even if the remote service doesn't participate in the trace, either by empty HTTP response or disregard to export. In this latter case, what is the incentive of the remote service to share its tracing vendor information? I'm probably in need of some clearer Use-Case examples.

Thanks for the effort and your time reading this!!

[roncohen]

Hi @falenn. The parent span id is part of the traceparent: https://github.com/w3c/trace-context/blob/master/trace_context/HTTP_HEADER_FORMAT.md#span-id

[falenn]

Ok, so the parentSpanId from a b3 point-of-view is the span-id in the traceparent. Where is the current span-id?

[yurishkuro]

No, b3.spanId == traceparent.spanId

b3.parentSpanId is an artifact of zipkin's feature where client and server spans share the same id. It is not a feature that tracecontext is planning to support (zipkin can be configured to not use it and always have unique span IDs)

[falenn]

Ah, Thank you. The naming is confusing: traceparent implies to me the particular Id components for provenance from which the impending span will hang from.

I was getting confused by not considering how this information is exported. When a span is exported, for instance having been called by another service, it has at its disposal the traceparent (trace-id, span-id) and its newly generated span-id. With these three components, span information is exported allowing graph construction. Correct?

If this service were to call another service, it passes along its newly generated span-id with the trace-id, etc. like written in the spec.

b3.parentSpanId is an artifact of zipkin's feature where client and server spans share the same id. It is not a feature that tracecontext is planning to support (zipkin can be configured to not use it and always have unique span IDs)

As in the above statement, it's still possible to decorate the span after receiving a response from a dependent service with response codes, etc., but there was no sharing of span-id.

Thank you for clearing this up for me.

[danielkhan]

As agreed in our latest meeting, right now the spec won't be extended with this information.