[
https://issues.apache.org/jira/browse/SOLR-15283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17320695#comment-17320695
]
David Smiley commented on SOLR-15283:
-------------------------------------
[~caomanhdat] I was looking at JaegerTracerConfigurator to make it more
configurable. Jaeger has some really nice automatic configuration completely
from Java system properties or environment variables –
[https://github.com/jaegertracing/jaeger-client-java/blob/master/jaeger-core/src/main/java/io/jaegertracing/Configuration.java]
see "fromEnv". If we use that, we have less code to maintain and we expose
pretty much anything Jaeger has to the user to configure as they wish. The
configuration in solr.xml would be non-existent for the plugin but it's fine.
At present, the sampler is hard-coded to fully sampled. In this PR, it's
important that it be settable because there is no Solr layer sampling of
Tracing overall. If I don't hear back, I intend to remove the sampling
configuration code and thus simply rely on "fromEnv".
> 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: 10m
> 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
