-
Notifications
You must be signed in to change notification settings - Fork 24.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change of behaviour for the "query_string": "*"
filter after upgrading to 8.14
#110133
Comments
Pinging @elastic/es-analytical-engine (Team:Analytics) |
I've been trying for a bit, and I can't get this to reproduce with a more minimal example. Here's the script I just used:
Which returns exactly what I would expect:
i.e. one bucket with three matches. So I don't think @dej611 can you trim this query down to the minimum needed to reproduce the issue, please? If you need help doing that, please reach out to me next week and I can find some time to pair with you on it. Alternatively, that |
I still can't reproduce this locally, but @dej611 was able to get me access to the cluster where this is occurring. Based on analysis on that cluster, I now believe this is an issue with the
I would expect that these would return the same results, however the
I'm going to pull the search team in on this to get some domain expertise about what might be happening here. |
Pinging @elastic/es-search (Team:Search) |
@dej611 for the index settings, is there a |
@dej611 another setting that could change this behavior is |
I can see a
We've checked also any change in the index template used for the integration, and the final index template is derived from this https://github.com/elastic/elasticsearch/blame/main/x-pack/plugin/core/template-resources/src/main/resources/metrics%40settings.json (I see the |
The profile output says it rather clearly: the field target by the query string is not mapped. Can you check the mapping for the Just in case, what happens if you specify message:* in the query string query? |
I managed to have a 8.13.1 instance with the same integration without the issue. Checking it I see that some indexes on the 8.13.1 have a different
Tried to run the profile on both 8.13.1 and 8.14 and I see both
In both cases there's:
0 results in both instances. |
@gizas found this discussion here about removing the |
So, elastic/kibana#178020 is most likely the cause here? Do those vector changes explain the discrepancy? @dej611 what happens if you flip back in 8.14 the default field calculation (just do it manually and update the index settings directly), do you get hits again like you expect? |
I've manually changed the |
If multiple templates are being utilized and the default_field value was previously overwritten so that this metrics template was ignored, that is likely the cause of this failure. |
@dej611 this seems like an unintended behavior change on the Kibana side. No behavior changed directly in the Elasticsearch server core. Do you think we can close this? |
Yes, I think so. Thanks for your help 👍 |
Elasticsearch Version
8.14
Installed Plugins
No response
Java Version
bundled
OS Version
linux
Problem Description
As documented in this Kibana issue an integration dashboard stopped reporting results on 8.14: elastic/kibana#186616 (comment)
The affected visualization produces the following query:
In 8.13.1 this query was returning some results:
In 8.14 it returns:
In 8.14 removing from the
Status > bool > filter
the part with:Then the same response comes back.
The problem is that there are many Kibana Lens visualizations within dashboards applying that
filter
in the query and are affected by this change of behaviour.Steps to Reproduce
See above.
Logs (if relevant)
No response
The text was updated successfully, but these errors were encountered: