opencensus-specs icon indicating copy to clipboard operation
opencensus-specs copied to clipboard

Change Span name after starting a span.

Open g-easy opened this issue 7 years ago • 7 comments

Currently, the Span name can be set at start time, but (in Java and C++) can't be changed afterwards.

opencensus-go has Span.SetName.

Others have this functionality, e.g. Zipkin.

Envoy uses this functionality to sometimes change the span name if a "decorator" is configured.

We should decide whether Span names can be changed after starting a span. And also how this will interact with z-pages.

g-easy avatar Dec 12 '18 05:12 g-easy

cc @SergeyKanzhelev

g-easy avatar Dec 12 '18 05:12 g-easy

yep in a lot of our instrumentation, names are resetable until late. This is because often a better span name isn't available, yet. For example, the route name of an http request is usually not available until late in processing, sometimes not until the response.

codefromthecrypt avatar Dec 12 '18 05:12 codefromthecrypt

The only question should sampling be re-run as sampler today receives a span name as an argument. So potentially a name-based sampling decision may have already been done or worse - other decision needs to be done based on the proper name like route

SergeyKanzhelev avatar Dec 19 '18 17:12 SergeyKanzhelev

Enabling sampling after starting a span is mentioned in #218 also.

A potential problem I can see is: if sampling_enabled is stored in the SpanContext, and the SpanContext has been copied, there isn't a reasonable way of updating all the copies with the new sampling decision.

Maybe a better approach would be to start a new span after the routing decision is made.

g-easy avatar Dec 20 '18 02:12 g-easy

@g-easy the problem with two spans is a bad query and analysis experience. Basically two spans will only differ in most cases in a few milliseconds of duration and a name. We can just call this potential problem an edge case and ignore it.

SergeyKanzhelev avatar Dec 20 '18 07:12 SergeyKanzhelev

On the flip side: would it be a better approach to delay starting the span until the name is known?

g-easy avatar Dec 20 '18 08:12 g-easy

@SergeyKanzhelev modifying the "SpanContext" (a.k.a. data that are propagated to the child spans) may cause undefined behaviors (like a child span started and can cause incomplete traces). I think another option is to allow start Span to accept a start_time maybe if the sampler needs to run with the new name.

So viable options that I can see here (these will not cause problems):

  1. Allow custom start/end time.
  2. Allow changing the Span name without re-running the Sampler.

What do you think? We can also support both if that is needed.

bogdandrutu avatar Dec 20 '18 13:12 bogdandrutu