[
https://issues.apache.org/jira/browse/SOLR-14566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17139557#comment-17139557
]
Jason Gerlowski commented on SOLR-14566:
----------------------------------------
I ended up using the DebugComponent as Tomas suggested. It uses a format
similar to what Robert pointed to as well. So 2 birds with one stone.
In terms of implementation I waffled a bit between putting the logic in its own
SearchComponent impl that fires all the time, and just bundling it in to
SearchHandler. The former is simpler and easier to test, but I'm not sure that
such a trivial Component impl really fits what that abstraction is intended
for. I implemented both methods since they were both small changes.
The Component-based approach is on a branch in my personal fork here:
https://github.com/gerlowskija/lucene-solr-1/tree/SOLR_14566_move_rid_into_separate_component.
I've updated the existing Github PR to use the SearchHandler impl, since I
was leaning slightly in that direction:
https://github.com/apache/lucene-solr/pull/1574
Once I choose an approach I still plan on adding a feature flag to disable it,
and some tests (easier said than done for SearchHandler, but maybe I just need
to sleep on it.)
Again, appreciate any feedback on the approach if people prefer one over the
other. A part of me still likes the simplicity of the {{NOW}} based impl, but
oh well.
> 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
