open-telemetry
Add a onSpanNameUpdated method in SpanProcessor
What are you trying to achieve?
Add a onSpanNameUpdated method in SpanProcessor，when Span.updateName is called, onSpanNameUpdated will be called too.
What did you expect to see?
Additional context. I currently have scenarios where I need to apply special handling to spans with specific names, such as modifying their sampling rates or filtering out certain spans to prevent them from being reported.
Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
@trask see SpanProcessor specification https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#span-processor
Additional user story:
In most cases, users tend to use a Sampler with a 0.1 sampling rate to prevent excessive data from being reported. However, for certain applications, some traces with specific names or attributes are significantly more important, to the extent that users would like to record all such traces completely.
A possible good approach would be to implement a custom Sampler that decides whether to sample based on the span name or some attributes. However, in Java, the span name or route may change multiple times after the span has started, making it difficult to achieve this goal with a custom Sampler.
Adding a callback mechanism in the SpanProcessor could be one viable option. A more interesting question to explore is whether to allow re-sampling for specific spans — even in cases where some downstream spans may have already been marked for dropping at the time of re-sampling.
This wouldn't be enough, as several SDKs (at least Go) initiatialize a noop span when a no-sample decision was made. Changing that decision would mean having to regenerate a full span.
In your case, I believe tail-based sampling (either with a custom processor that makes sampling decisions in OnEnd, or a collector processor) would be a better way to achieve this.
As a side note, if we go this route, why only the span name? Setting some attributes could regenerate a sampling decision. Marking a span as error could too.
This wouldn't be enough, as several SDKs (at least Go) initiatialize a noop span when a no-sample decision was made. Changing that decision would mean having to regenerate a full span.
In this case, the Sampler should alway perform a RECORD_ONLY action for no-sample trace，the SpanProcessor will finally decide whether export this trace or not
In your case, I believe tail-based sampling (either with a custom processor that makes sampling decisions in
OnEnd, or a collector processor) would be a better way to achieve this.
There are some diffrences，Tail-sampler with SpanProcessor can only export spans in current process 4 no-sample trace bcause it does't change sample flag, And I don't like tail-sampler In Collector, it's bad
As a side note, if we go this route, why only the span name? Setting some attributes could regenerate a sampling decision. Marking a span as error could too.
It’d be even better to have this.
Tail-sampler with SpanProcessor can only export spans in current process 4 no-sample trace bcause it does't change sample flag
Yes. If you do tail-sampling in the span processor, you can't (reliably) do head-sampling as well. It seems that's what you're saying in your previous comment though.
Then, if the span processor has to make a final decision, you don't need computation when data is changed. You can analyze the span at its end only.
Yes. If you do tail-sampling in the span processor, you can't (reliably) do head-sampling as well. It seems that's what you're saying in your previous comment though.
That's not quite accurate. What I want to implement is: when the spanName of an HttpServerSpan changes, if the new spanName meets certain conditions, update the sampling flag so that all subsequent spans in this trace will be reported, even those that cross process boundaries.
@pepeshore if you'd like to present your idea, you can join the Spec Meeting on Tuesday and get some feedback for it!
