[
https://issues.apache.org/jira/browse/SOLR-14566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135976#comment-17135976
]
Robert Muir commented on SOLR-14566:
------------------------------------
IMO, there are two separate concerns: 1) propagating an existing id from any
incoming request to any additional requests, and 2) creating a new one.
As far as #1 goes, it means the user is already giving you an ID (e.g. from
their search backend). And there is kind of an adhoc standard to put it these
into a header such as x-request-id or X-Amzn-Trace-Id and there is support out
there (e.g. AWS ELB) to set it. if theres a little flask web service as part of
the architecture you can add something like
https://pypi.org/project/flask-request-id-header/ to make use of it, as an
example. so I think that might be improved over using a URL parameter for
better interoperability.
#2 is less interesting to me (e.g. generating an ID if the incoming request
isn't marked by one). UUID is unfriendly to me anyway (e.g. starting with a
timestamp portion will make the IDs roughly sortable which can be handy for
ad-hoc debugging).
> 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
