Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: adds support for isNoop check on spans. #181

Merged
merged 3 commits into from
Nov 11, 2020

Conversation

jcchavezs
Copy link
Contributor

@jcchavezs jcchavezs commented Nov 4, 2020

Span.IsNoop is specially usefull to avoid expensive operations when the tags or logs are not being recorded e.g. if you are about to read the body and process it to obtain certain tags, the check would save that computation as no changes will take effect.

References:

Ping @adriancole @basvanbeek

Span.IsNoop is specially usefull to avoid expensive operations when the tags or logs are not being recorded e.g. if you are about to read the body and process it to obtain certain tags, the check would save that computation as no changes will take effect.
@@ -39,6 +39,9 @@ func spanName(rti *stats.RPCTagInfo) string {

func handleRPC(ctx context.Context, rs stats.RPCStats) {
span := zipkin.SpanFromContext(ctx)
if span.IsNoop() {
return
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in go I guess we don't need to apply the context (to ensure sampled false is carried down stream)?

Copy link
Contributor Author

@jcchavezs jcchavezs Nov 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a good question. My idea was that even if sampled=false is propagated we still get a trace ID and client could choose to ignore that and continue the trace? Not sure this is a valid use case but secondary sampler came to my mind.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we had problems in brave where we early exited instead of making the span part of the context on noop. I suppose here is not responsible for making the span.. something else did, hence you are checking isNoop... iotw I think you already addressed this concern.

@coveralls
Copy link

coveralls commented Nov 4, 2020

Coverage Status

Coverage decreased (-0.8%) to 73.59% when pulling 28ec13b on adds_support_for_noop into b98d756 on master.

@basvanbeek
Copy link
Member

another way to solve could be a package level method testing if it is a noop span (or non existent) and not add it to the Span interface. you could internally in the package test if the actual noopSpan implementation is in play.

@jcchavezs
Copy link
Contributor Author

I see @basvanbeek, something like fun IsNoop(s Span): bool. Sounds good to me but wondering pros cons vs adding a method.

…basvanbeek's suggestion

IsNoop is more of the concern of the tracer and not necessarily of the span's concern, hence turning this method into a function.
@jcchavezs
Copy link
Contributor Author

PTAL @basvanbeek

Copy link
Member

@basvanbeek basvanbeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jcchavezs jcchavezs merged commit f113cc0 into master Nov 11, 2020
@jcchavezs jcchavezs deleted the adds_support_for_noop branch November 11, 2020 12:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants