Skip to content

Conversation

@chrisparrinello
Copy link
Contributor

@chrisparrinello chrisparrinello commented Oct 27, 2025

Add search request attributes context to:

  • es.search.shards.phases.can_match.duration.histogram

- es.search.shards.phases.can_match.duration.histogram
@elasticsearchmachine elasticsearchmachine added v9.3.0 needs:triage Requires assignment of a team area label labels Oct 27, 2025
@chrisparrinello chrisparrinello changed the title Can match phase shard metric with context Can match phase shard APM metric with search request context Oct 27, 2025
@chrisparrinello chrisparrinello added >enhancement Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch :Search Foundations/Search Catch all for Search Foundations and removed needs:triage Requires assignment of a team area label labels Oct 27, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search-foundations (Team:Search Foundations)

@elasticsearchmachine
Copy link
Collaborator

Hi @chrisparrinello, I've created a changelog YAML for you.

responses.add(new CanMatchNodeResponse.ResponseOrFailure(canMatch(shardSearchRequest)));
indexShard.getSearchOperationListener().onCanMatchPhase(System.nanoTime() - shardCanMatchStartTimeInNanos);
indexShard.getSearchOperationListener()
.onCanMatchPhase(shardSearchRequest, System.nanoTime() - shardCanMatchStartTimeInNanos);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dove deeper at the overhead and I am thinking that we are wasting time reanalyzing the same search request over and over when many shards are allocated to the same data node.

Even if we create a new shard search request every time for the purpose of calling can match, the source is always the same, and so are the other arguments that are needed to extract the attributes. I would do that analysis only once for all the shards if possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense to me. I'll update.

canMatchPhaseMetric,
tookInNanos,
shardSearchRequest,
null // we don't have the time range filter info at this point in the search
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that getting the time range may be ok to do actually. We already collect it, but we just don't propagate it. I looked deeper at this and came up with #137314 . What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked at the other PR and I think taking advantage of that would require moving where we're recording this (the CanMatchContext hasn't been created yet) but I think based on our conversation on Wednesday about the coordinator level phase, we should be doing this anyway to cover all of the calls to canMatch (in the can-match phase, the query phase, etc.).

javanna added a commit that referenced this pull request Oct 30, 2025
…37314)

We recently introduced metrics attributes to track search latencies at the
shard and coord level.

With #137196 we are introducing such attributes to the can match phase latency
metrics. The time range filter is not currently accessible when recording the metrics. 
This commit exposes it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>enhancement :Search Foundations/Search Catch all for Search Foundations Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v9.3.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants