You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Jason Gerlowski (Jira)" <ji...@apache.org> on 2020/07/08 18:13:00 UTC

[jira] [Resolved] (SOLR-14566) Record "request-id" on coordinator log messages

     [ https://issues.apache.org/jira/browse/SOLR-14566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Gerlowski resolved SOLR-14566.
------------------------------------
    Fix Version/s: 8.7
                   master (9.0)
       Resolution: Fixed

> Record "request-id" 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
>             Fix For: master (9.0), 8.7
>
>          Time Spent: 6h 10m
>  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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org