[
https://issues.apache.org/jira/browse/SOLR-15283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17329251#comment-17329251
]
ASF subversion and git services commented on SOLR-15283:
--------------------------------------------------------
Commit 69b41878551a0598c870f925deb501aa4d4acb1c in solr's branch
refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=69b4187 ]
SOLR-15283 Tracing overhaul (#52)
* Solr's GlobalTracer is gone. Use OpenTracing's GlobalTracer, or even better:
getters on CoreContainer, SolrQueryRequest, etc.
* No more "samplingThreshold" cluster property. Instead, configure sampling
specific to the plugin.
* Ensure the active span is visible from all threads by using ExecutorUtil
* JaegerTracerConfigurator is now configured via sys props / env vars
> 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
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Blocker
> Fix For: main (9.0)
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
