Kibana 6.1.4 fieldless search times out when window is several days

Elastic Stack Kibana
1

Hi, I upgraded our nominally working 5.6.4 ELK stack to 6.1.4 (ES, logstash, and Kibana). We did not use xpack before, and we are not yet using xpack on this 6.1.4 upgrade (we have a license, but haven't installed it yet...still figuring out that part). We keep 30 days worth of indexes, and create a new index daily (named logstash-YYYY-MM-DD). Our default index is "logstash-*".

We used to be able to search for random strings without specifying a field and it would find things in a reasonable time frame, a few seconds. Now in 6.1.4, if we search for a string, such as "6d0aed01-4201-3cb9-9925-1c9555540c09" over the last 7 days, the search times out after 30 seconds. If we search for message:"6d0aed01-4201-3cb9-9925-1c9555540c09" over that 7 days, it finds and returns the result set relatively quickly. Search behavior changed something specifically around fieldless searches when upgrading from Kibana 5.x to Kibana 6.x.

I've been googling a lot and read that the _all field is no longer automatically in 6.x.
Do I need to create a new _all field? The page https://www.elastic.co/guide/en/elasticsearch/reference/6.1/mapping-all-field.html seems to imply that it's deprecated, which means to me I shouldn't use it.

I've also read something about "all_fields: true", but it doesn't make sense yet where that might actually be used.

Googling also led me to look at my default search field, currently set to *. I considered setting the default search field to "message", but then it won't find strings in the other fields (the way it used to in 5.6.x searches).

What do I have to add/set up to get the same fieldless search behavior I had in 5.6.x searches?
I'm not sure what to do here. I think I want whatever is the equivalent of the _all field in 6.x.x, but I'm not sure exactly what that would be. Can I get some hints and suggestions please?

Many thanks!

...Todd

2

Hey @Todd_Lyons,

First off, I wanted to say thanks for your detailed post! This makes it a lot easier to help.

You're right that the _all is deprecated, but there is a supported way to create your own. You can update the fields in your index mapping, and indicate they they should be "copied to" another field of your choosing. Using this, you can construct your own version of an _all field, and use that for your searches. Once that is in place, you can further improve the query time by updating the default search field to your new _all field, if you find that the timings aren't what you'd like them to be.

Regarding the all_fields setting: that is only used by the simple_query_string query type in Elasticsearch. I'm researching to see if that has an impact on Kibana searches, and I'll update this once I know more.

3

If I could get a little more guidance on the following piece, I would be most appreciative:

You can update the fields in your index mapping , and indicate they they should be "copied to" another field of your choosing. Using this, you can construct your own version of an _all field, and use that for your searches.

I don't have any index mapping defined other than a _default_ mapping with a few specific fields that are integer indexes. I think the way to address this is to

  1. Define in the _default_ mapping a new field of type text named map_todd1_all.
  2. I've gone through our fields currently in use and of the 1100 (and growing) fields, almost all of them default defined to be type text, and I found 15 that have content that I feel should be generally searchable when no field is specified in the search.
  3. Since all 15 of these fields are not explicity defined, I'll also add those 15 fields to the _default_ mapping, explicitly declaring them as type text, and adding the copy_to "map_todd1_all" there.

Does it sound like my understanding above is headed in the right direction?

Regarding naming, I have seen a lot of messages that say to create a field name with an _ and a lot that don't. Does it matter if the field name does or does not start with an underscore? It feels like an underscore implies something internal to ES, but maybe not.

Thanks for your advice!

...Todd

4

Followup, I did the steps above, and set map_todd1_all as the default field to be searched in Kibana (Advanced setting). It is working, but now I need to figure out the "it's no longer highlighting when it finds records based on the synthesized map_todd1_all field" problem. One piece at a time :slight_smile:

5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.