Export noopSpan type

[honghzzhang]

Can we export noopSpan type or let me know how else I could check whether a given span is a noopSpan?

[jcchavezs]

I guess what you need is that somehow determine whether a span context is noop or not. I would instead add the Span::IsNoop method instead like in brave: https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/Span.java

Thoughts @basvanbeek ?

[basvanbeek]

Is this needed because having a sampled span implies needing to do additional expensive computation?

I kind of want to make sure we don't add things as long as they are not really needed. I would like to hear about a proper use case for this.

[honghzzhang]

I am trying to convert a Java project which uses zipkin tracing to Go. In the java project, it calls the brave API Span.isNoop() to determine whether to propagate the span and I was trying to find the equivalent API from the zipkin-go project.

[jcchavezs]

I'd recommend that you don't check the noop and propagate the context (with X-B3-SAMPLED=0) as the recipient will create noop spans instead but I am curious whether there is another use case behind that. @adriancole can you think on a use case for this?

[honghzzhang]

If I propagate the context (with X-B3-SAMPLED=0), will the recipient always create noop span or it knows to only create noop spans when applicable?

[basvanbeek]

Ok, so one of the most important aspects to propagation is to always propagate! How would a downstream service otherwise know that the trace was not sampled? It could start a new trace because without propagation it thinks it is the trace root.

[jcchavezs]

True but IMO if context contains sampled=false we should create noop spans. I raised an issue to discuss this: #49

[codefromthecrypt]

I would treat noop different than sampled knowing what I know now. Here is why.. in firehose mode we will collect regardless of sample flag, but look at the context to see if we should report to zipkin or not. It is only because we have isNoop that we can do this without breaking people..

[jcchavezs]

I see but isn't firehose mode magic happening when reporting? Can we just use sampling=100% for firehose mode instead of creating real spans for sampled=false?

If the reason why is firehose them we probably need to do the same in other libraries, otherwise if one of our libraries creates a noop object we will miss that piece. Is this something already happening in brave?

[codefromthecrypt]

I see. If the reason why is firehose them we probably need to do the same in other libraries, otherwise if one of our libraries creates a noop object we will miss that piece.

In census I think this is called "always record events" or similar. In brave, the isNoop guard is regularly used to prevent parsing expensive things, so yeah if you want to capture all data you need a mechanism to opt-out when it is pointless (ex when unsampled and there is no other sort of listener, it is pointless to spend time creating data only to be thrown on the floor)

Is this something already happening in brave?

it isn't done yet. first to do this way py_zipkin

[basvanbeek]

There is merit in knowing when a span is recording items or if not (ex. noopSpan). As said above this helps with avoiding expensive computations and unnecessary burning of cpu cycles.

I do want to have this be part of the bigger scope of work on firehose mode. So closing here.

Firehose mode is discussed in #58