Are there any known ways to simulate the newer X-Opaque-Id
semantics for /_search
requests in older versions of Elasticsearch (specifically 5.3.x)?
One approach I considered is co-opting the _name
field as described in https://stackoverflow.com/questions/42844111/is-it-possible-to-put-a-comment-in-an-elasticsearch-query and https://github.com/elastic/elasticsearch/issues/30576 . However, this approach doesn't work without disruption (requires at least one bool
query) and likely has performance implications associated with matched_queries
processing. Another approach I've thought might make sense is using source.excludes
and including a bogus field that contains a correlation id that can be used for joining with external systems for the purposes of tracing (see How to track user actions (process list)? for similar in later versions).
Any ideas for improvements would be greatly appreciated!
For the benefit of future readers, I see there is another approach using stats
:
Hi @animageofmine ,
stats groups are per request. You define them directly in your query. Copying the example that I gave in the other thread verbatim:
GET /_search
{
"query": {
"match_all": {}
},
"stats" : ["myapplication"]
}
This will show up in the slow query log as:
[2017-05-26 12:12:08,011][INFO ][index.search.slowlog.fetch] [Elven] [old_books][3] took[219.7micros], took_millis[0], types[], stats[myapplication], search_type[QUERY_THEN_FETCH], total_shards[5], source[{…
Igor_Motov
(Igor Motov)
February 4, 2020, 6:48pm
3
I think the best approach is to upgrade. 5.3.x EOLed on September 28, 2018.
Agreed. Unfortunately that's not always viable, or may take some time and thus having an interim solution has a lot of value in our context.
system
(system)
Closed
March 5, 2020, 1:34pm
5
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.