[
https://issues.apache.org/jira/browse/SOLR-14566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136667#comment-17136667
]
Jason Gerlowski commented on SOLR-14566:
----------------------------------------
Huh, didn't know about that. And yeah, that raises some questions.
My primary drive here is to have something that's recorded by default. Having
information recorded by the DebugComponent is nice, but in practice customers
are unlikely to have it configured when a QTime spike or other performance
problem happens on their live cluster. Whoever is tasked with looking at their
logs after the fact and intuiting a cause isn't going to benefit from
DebugComponent.
So whatever we want this key to look like - whether it's a UUID, whether it's
the NOW timestamp, whether it's the format that DC uses
({{hostName-coreName-millisSinceEpoch-requestCounter}}), I'd really like to see
it recorded by default and not limited to an infrequently used Component.
If no one objects, I can move the requestId stuff out of DC and into
SearchHandler where the NOW logic currently lives. But I wonder if there won't
be objections - presumably whoever wrote DC put stuff in there because there
was a consensus at the time that it _shouldn't_ be recorded by default,
probably for perf reasons. That's why I initially proposed using the NOW
timestamp - because it sidesteps the question of id-gen perf entirely. But
maybe no one cares - in which case I'll update this PR in a few days to use
DC's "requestId" format. Or at least do a perf test to see if there's any
noticeable difference 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
