[ https://issues.apache.org/jira/browse/SOLR-14566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136192#comment-17136192 ]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14566: ------------------------------------------------------ Note that Solr already has something similar, the "requestID". it's currently part of the debug component, but maybe it can be moved somewhere else if needed for all requests, I don't know. See https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/DebugComponent.java#L159. Also, if the requestID generation is not optimal there we can fix it there. > Record "NOW" on "coordinator" log messages > ------------------------------------------ > > Key: SOLR-14566 > URL: https://issues.apache.org/jira/browse/SOLR-14566 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Jason Gerlowski > Assignee: Jason Gerlowski > Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Currently, in SolrCore.java we log each search request that comes through > each core as it is finishing. This includes the path, query-params, QTime, > and status. In the case of a distributed search both the "coordinator" node > and each of the per-shard requests produce a log message. > When Solr is fielding many identical queries, such as those created by a > healthcheck or dashboard, it can be hard when examining logs to link the > per-shard requests with the "cooordinator" request that came in upstream. > One thing that would make this easier is if the {{NOW}} param added to > per-shard requests is also included in the log message from the > "coordinator". While {{NOW}} isn't unique strictly speaking, it often is in > practice, and along with the query-params would allow debuggers to associate > shard requests with coordinator requests a large majority of the time. > An alternative approach would be to create a {{qid}} or {{query-uuid}} when > the coordinator starts its work that can be logged everywhere. This provides > a stronger expectation around uniqueness, but would require UUID generation > on the coordinator, which may be non-negligible work at high QPS (maybe? I > have no idea). It also loses the neatness of reusing data already present on > the shard requests. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org