gerlowskija commented on pull request #1574: URL: https://github.com/apache/lucene-solr/pull/1574#issuecomment-648812127
> Perhaps a stupid question, but how does this compare with the jaegertracing / opentracing support? Would not that already provide some request id to follow a request across nodes? I have absolutely no in-depth knowledge of that module so have me excused if the question is far out :) @janhoy It's not a dumb question. The way I look at it, there's two questions to ask about OpenTracing as it relates to this PR: (1) Why do we need this PR if we've got OpenTracing?, and (2) Does OpenTracing have id-generation code we can reuse here? For the first question - the value of this PR is that it gets us very lightweight request correlation out of the box in Solr's logs on all distributed queries. OpenTracing is vastly more powerful, but it requires more setup and more resources: it requires enabling of a contrib (or use of a custom plugin), it requires an external Jaeger server to ship data to (and consumes network bandwidth to do so) , and because it's heavier-weight OpenTracing is typically only run on a sample percentage of requests. It's not reliably present for all requests, unless you crank the sample % up to 100 and take a performance hit. So in practice OpenTracing and the request-id stuff I'm adding here are good for different audiences and use-cases. OpenTracing is going to be primarily useful for teams which want to have ongoing monitoring/tracing on requests coming through their cluster. And of course it's going to appeal more to teams that have the Ops personnel to manage a Jaeger deployment, etc. OTOH, Request-id logging is primarily useful for a Solr expert debugging a small time-window of logs. For the second question - if you can believe it, Solr's OpenTracing integration doesn't have any explicit ID-generation code. Instead the ID-generation is done inside of some Jaeger code (see `JaegerSpanContext.convertTraceId`). Technically we could reuse this code, but it'd require creating a small graph of Jaeger objects. Since it'd couple us directly to Jaeger and would involve extra object creation, I didn't think this was a good way to go. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
