The default sampler should not sample all operations

[carterkozak]

What happened?

If I create a simple application and include http-remoting, every requests is sent with X-B3-Sampled: 1 due to our usage of AlwaysSampler by default. Even if my demonstration application does not write trace data to disk, it will cause other services to do so.

What did you want to happen?

I am proposing that we update the default sampler to new RandomSampler(.01f) to sample 1% of actions unless another sampler is specified. I have no strong opinion regarding 1% in particular, but would prefer that we do not sample everything. This value is used elsewhere, so it should be a reasonable default.

[markelliot]

The goal of AlwaysSampler was to force deliberate configuration -- a roughly equivalent, but easier for your scenario, semantic would be a NeverSampler, which I think would be preferable to a preconfigured RandomSampler

[carterkozak]

That's reasonable, will build shortly.

In the default case I'd prefer not to inform the target system whether or not to sample, but defer to its sampler. Implementation likely isn't worth the complexity though.

[uschi2000]

Yeah, I think I may have screwed that up in the Trace API: it doesn't account for "observability hasn't been decided" and thus the cannot choose to not set the SAMPLED header and defer the decision to the next node.

[carterkozak]

There are a number of java api changes I'd like to propose for a major version revision. Where is the best place to track them, given that I don't have cycles to implement in the near future?

Examples:

• Observability is undecided
• Tracing API and Observer API should be isolated. Instrumenting a system with tracing should not require knowledge of Trace object.
• Creating a new trace should always open a new span
• Opening a span returns a token used to safely close that span, it should not be possible to close the wrong span.
• span completion should not return the completed span (fastCompleteSpan semantics). When observation is disabled, there's no reason to profile execution.

[uschi2000]

I think it's fine to write up issues and tag them as major revision or 3.0.0 or similar. note that this will be particularly nasty to implement and roll out because of the interplay of static state (should keep same classes and packages in order avoid duplication) and API changes (should move to new packages like com.palantir.tracing3)...

[carterkozak]

Great, thanks. Any chance I can get permissions to create GH milestones or labels?

[carterkozak]

Closing in favor of #32