Consider exposing parentId from SpanContext

[thegreystone]

In 0.32.0 it is being considered to expose the traceId and the spanId from the SpanContext. There are many tracer implementations that will not easily be able to expose these, and I assume that was why they weren't part of the API at all.

Now, since traceId and the spanId are being added, and since it is assumed that tracers will return null for those if the data cannot be provided, I think it is reasonable to consider also added parentId. That would allow projects like java-jfr-tracer to reconstruct the span DAG off-line.

[yurishkuro]

As I have mentioned on other threads:

• please explain in detail the use case that requires this feature
• we have no semantic definition of a parent id anywhere in the spec, we would need to start with that before discussing the API change (immediate hurdle - joins in a DAG have more than one "parent").

[thegreystone]

Is there a semantic definition of span id and trace id in the spec?

[yurishkuro]

https://github.com/opentracing/specification/blob/master/rfc/trace_identifiers.md#specification-changes

[thegreystone]

Oooh, the spec has indeed changed. Well, in that case I agree, a spec update would need to be discussed first.

[thegreystone]

Here is the detailed use case: Person A uses a distributed tracer (say Jaeger) to realise that operation O is taking a long time. Person A dumps the flight recorder which contains contextual scope and span events detailing what was going on. Person A decides to send the dump to expert Person B for a second opinion.

Now, if the parent id is available, the expert Person B could have the trace (or span) of interest visualised as a DAG, making it easier to see the relationship between the spans. From there he could drill down into what was going on in the various threads in the JVM during e.g. very specific scopes (thread local span activations), or during very specific spans.

[yurishkuro]

I don't recall if the spec itself changed, the link is to the RFC, but the RFC defines the semantics.

[yurishkuro]

If we put the flight recorder tracer aside for the moment, and just look at the normal tracer implementation - it does not require anything extra because it already receives all the data from instrumentation, e.g. when the new span is started, the parent span is passed as a reference. The tracing backend is able to build the DAG from the data collected.

So the question is - what is special about the flight recorded tracer that it needs parent-id from span context?

[thegreystone]

You sir, are entirely correct. Of course I can keep that information around myself. I was just lazy, and I will close this and shut up. ;)

[yurishkuro]

it was not my intention to shut anyone up, I am always interested in new ideas and use cases (but they do not always warrant API changes).

[thegreystone]

Haha. Just a figure of speech. Didn’t mean literally. Thanks for pointing this out.