[
https://issues.apache.org/jira/browse/SOLR-15283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314624#comment-17314624
]
David Smiley commented on SOLR-15283:
-------------------------------------
I haven't heard feedback whatsoever here despite also [publicizing this on our
dev
list|https://lists.apache.org/thread.html/r5e8c80df28fee28fbd0c0d727f4782bd9f0002a7e40352ebb0c8c3ac%40%3Cdev.solr.apache.org%3E]
with CC's to pertinent people -- [~caomanhdat] [~shalin]. I feel very
confident in this direction (despite reversing a past feature), and I've built
on it further at work. I look forward to sending some additional PRs to make
Tracing even better. Later in the week I'll finish up the PR. I intend to
make Jaeger's sampling configurable, and also update the ref guide.
> 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)
>
> 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
