[
https://issues.apache.org/jira/browse/SOLR-15283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308960#comment-17308960
]
David Smiley commented on SOLR-15283:
-------------------------------------
Also, let's not bother with Solr having it's own "GlobalTracer"; let's use the
one by the same name in OpenTracing. I've done this locally and am close to
providing a PR. There are two issues I've seen with this:
* GlobalTracer cannot reset itself back to an initial state, which is rather
essential in tests. I solved this via Java reflection in the test.
* GlobalTracer.get() always returns a delegating Tracer (class GlobalTracer),
not the actual backing Tracer (e.g. for Jaeger/Zipkin). Not a big deal; I had
to adjusts the tests a bit. It does mean that GlobalTracer.get() will *never*
implement NoopTracer, even if the backing impl does... but that is ameliorated
by having callers that care call GlobalTracer.isRegistered() instead.
That said, as advised in the javadocs, more of our code ought to have a
"Tracer" instance as a field so that use of GlobalTracer is minimized.
CoreContainer & SolrRequest, for example, should have it.
Removing the sampling also removed a needless ZK dependency, and thus tracing
ought to work in standalone mode (though I didn't test).
> Remove Solr trace sampling; let Tracer configuration/impl decide
> ----------------------------------------------------------------
>
> Key: SOLR-15283
> URL: https://issues.apache.org/jira/browse/SOLR-15283
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Blocker
> Fix For: main (9.0)
>
>
> GlobalTracer should always have the Tracer produced by the
> TracerConfiguratorPlugin. Solr should not intervene by substituting a no-op
> version sometimes, and thus needn't have its ThreadLocal tracking either
> (which doesn't work well). The special {{samplePercentage}} cluster property
> should be removed.
> Background: When someone configures tracing (supplying TracerConfigurator
> plugin), Solr will "sample" tracing if an incoming request has no tracing
> information. By default this is 10% and is only configurable via a
> {{samplePercentage}} cluster property. If you're in the 90%, this results in
> a no-op Tracer -- no trace IDs. This is really confusing & annoying because
> Tracers themselves have notions of sampling, which means "reporting"
> (sending) the trace to a tracing server where it can be
> stored/analyzed/visualized. The point of a non-sampled trace is propagating
> IDs for logging (trace ID in MDC) -- very light-weight. Zipkin and Jaeger
> (and others?) have their own samplers. When Solr receives a request with a
> trace ID, in Zipkin it also includes the binary sampling decision (it's
> another header). The expectation is that if the trace says to sample, then
> this sampling decision is propagated downstream and thus the whole call tree
> is fully sampled (reported to a server).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
