[
https://issues.apache.org/jira/browse/SOLR-15367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742523#comment-17742523
]
David Smiley commented on SOLR-15367:
-------------------------------------
I would recommend doing SOLR-16536 first if you are up for it. If you don't
and if you implement this issue (requiring an OpenTracing impl), it'll make
SOLR-16536 harder as it would mean porting it to OpenTelemetry. But that's
okay; perhaps won't be much work.
I suggest the first impl here be pretty basic and we can review / examine then
iterate as needed. Only one ID. Not necessary to touch MDC or logging config;
trace IDs are _already_ logged.
Your proposal to accept an existing trace is interesting but with OpenTracing
that requires an existing plugin which could vary and have different headers.
I think OpenTelemetry would result in standardizing on solving that.
> Convert "rid" functionality into a default Tracer
> -------------------------------------------------
>
> Key: SOLR-15367
> URL: https://issues.apache.org/jira/browse/SOLR-15367
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
>
> Solr's "rid" (request ID) functionality added in SOLR-14566 could be
> converted into a distributed-tracing OpenTracing Tracer (Solr
> TracerConfigurator) plugin, more or less. Such an implementation, enabled by
> default, would merely generate IDs and pass them along in a custom HTTP
> header. Solr's existing tracing support would then ensure that this ID is in
> MDC in the "t:" log prefix, and thus would fit in nicely. "rid" is kind of a
> cheap bolt-on by comparison, duplicative with tracing but far fewer features.
> Solr's tracing support is growing, supporting more Solr-to-Solr interaction
> than "rid" which is only in a search request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
