Exclude certain spans from creating a new trace

[mtwo]

I think that we already support this on Ruby or Python, but we should be consistent across languages.

We should create a way for developers to exclude certain URLs, gRPC methods, etc. from creating a new trace. These URLs / methods should still generate spans in ongoing traces.

Examples include excluding health checks, excluding the long poll requests for Stackdriver Profiler, etc.

[rakyll]

Related to #151.

[semistrict]

Is this the client-side equivalent of #151?

An alternative solution to excluding based on URL would be to not start traces from client-side integrations by default at all. i.e. to make the default sampler on client-side integrations effectively Probability(0).

It seems to me that in most cases you will want to start a new trace only from the server-side integration so that it captures the full unit-of-work. If we didn't automatically start traces from the client-side, I think this issue would go away.

[mtwo]

Yep, this is the equivalent to #151 for clients.

I agree about not wanting clients to make the sampling decision, as client-only traces have very little value. However, we do want to see client spans on traces that do reach a backend, even if these spans are the first in a trace.

[rakyll]

Related to #182 which is both for clients and servers.

[codefromthecrypt]

in brave, we have a client sampler which folks can simply set to false to never have (http) client originated traces. This doesn't mean other local roots can't happen.
https://github.com/openzipkin/brave/blob/master/instrumentation/http/src/main/java/brave/http/HttpSampler.java#L38

There's a rather long discussion about local roots which aren't clients here which is indirectly related (mostly for use case thinking though you probably know more than we do) openzipkin/brave#801

(ps I'm restarting watching census repo now as back in a position to do that again)

[rakyll]

Is #182 capturing the requirements of what's requested in this issue? If yes, can we close this?

[semistrict]

I don't think #182 will resolve this. Currently, this is happening because client libraries (e.g. Go GCP SDK) are starting traces. The ability to set GetStartOptions will not help because the Transport is created deep in the client library with no ability for the end user to set GetStartOptions. It will always use the default sampler.

I think we need a different default sampler for client traces vs. server traces. Client traces IMO should have be sampled with Probability(0) (i.e. continue existing traces but don't start any new ones). Server traces should use the existing default.