Skip to content

Where could we (in principle at least) allow users to control span creation #180

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

Closed
marcingrzejszczak opened this issue Feb 22, 2016 · 2 comments
Milestone

Comments

@marcingrzejszczak
Copy link
Contributor

The question is about whether or not make it configurable to eagerly start spans. And where to add such a possibility.

If users fully control the span creation then it (span propagation) might be error prone.

Related to:

@codefromthecrypt
Copy link
Contributor

meta topic: Until there's a different issue on the topic, I'd keep discussion there. For example, there's only one use case pattern requested. Jumping between issues loses context and makes having the discussion less relevant unless the actual use case is copy-pasted into the description (which makes it look like the first issue again).

I think the topic, especially relating to the issue, has two parts:

Our tracer api conflates propagation with span creation

The Tracer api has a wrap method which in default form implies eagerly creating a new span. There's a question about this api in general, which is fair as the behavior isn't usual. For example, it seems Finagle, Brave, and HTrace at least don't conflate these things. Most tracer apis concern themselves with propagating context divorced from starting a span. Why do we believe our tracer api should conflate these?

If this can be changed, it would be easier to make custom instrumentation that doesn't create "junk" spans. Regardless, this is so unusual, it should be documented.

For example, TraceCallable says "Callable that passes Span between threads." That's a normal statement, but the actual code eagerly creates a span on run (which is the abnormal part). Such a behavior should be very obvious in docs if we believe our api is correct.

Should our implicit instrumentation eagerly create spans?

This is a different topic, but if depends on the above. For example, if we didn't make eager spans, then we'd likely not get the issue in the first place. I think it is best to address the root api concern before auditing each instrumentation and seeing if it should have an "eager" setting or not.

@marcingrzejszczak
Copy link
Contributor Author

Done via this: #174

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

No branches or pull requests

2 participants