Search behavior in Kibana

[anhlon]

Hi,

I am using FileBeat to collect logs from docker containers, the logs are sent to logstash and eventually end up in ES for viewing in Kibana. Given the two log entries below;

2018-07-18 21:28:26.760  INFO [foo-service,ef48be8c13ae0d81,192d6982b1eeca95,false] 6 --- [nio-8087-exec-1] a.s.r.foo.controllers.FooController    : doFooThings() duration (ms): 14
2018-07-18 21:28:26.383  INFO [bar-service,ef48be8c13ae0d81,f468cbb60ed98371,false] 6 --- [io-8085-exec-10] a.s.r.foo.controllers.BarController        : doBarThings(): duration (ms): 10

In Kibana, I enter "message: ef48be8c13ae0d81" to search, however, only the 2nd line (with "ef48be8c13ae0d81,f468cbb60ed98371") is returned. When I enter "message: ef48be8c13ae0d81*" both are returned.

Another behavior I am noticing is when I use "message: ef48be8c13ae0d81*", the result text is highlighted as below;

• ef48be8c13ae0d81,192d6982b1eeca95 --- this string is highlighted (first log entry)
• ef48be8c13ae0d81 --- only this string is highlighted (second log entry)

Questions:

1. It looks like it can do partial text search, but why doesn't it return the 2 results as "ef48be8c13ae0d81" is in the two log entries?
2. The highlighting, why is it different?

Thanks in advance for any suggestions you may have.

[jen-huang]

There's a couple of different pieces at play here that results in the behavior you are seeing:

1. Your message field is likely a full text field using standard analyzer, if you have not configured a custom analyzer in the index mapping or default settings. Information about standard analyzer here.

2. Let's check how the standard analyzer parses your two example messages.

The first one:

POST _analyze
{
  "analyzer": "standard",
  "text": "foo-service,ef48be8c13ae0d81,192d6982b1eeca95,false"
}

{
  "tokens": [
    {
      "token": "foo",
      "start_offset": 0,
      "end_offset": 3,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "service",
      "start_offset": 4,
      "end_offset": 11,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "ef48be8c13ae0d81,192d6982b1eeca95",
      "start_offset": 12,
      "end_offset": 45,
      "type": "<ALPHANUM>",
      "position": 2
    },
    {
      "token": "false",
      "start_offset": 46,
      "end_offset": 51,
      "type": "<ALPHANUM>",
      "position": 3
    }
  ]
}

The second:

POST _analyze
{
  "analyzer": "standard",
  "text": "bar-service,ef48be8c13ae0d81,f468cbb60ed98371,false"
}

{
  "tokens": [
    {
      "token": "bar",
      "start_offset": 0,
      "end_offset": 3,
      "type": "<ALPHANUM>",
      "position": 0
    },
    {
      "token": "service",
      "start_offset": 4,
      "end_offset": 11,
      "type": "<ALPHANUM>",
      "position": 1
    },
    {
      "token": "ef48be8c13ae0d81",
      "start_offset": 12,
      "end_offset": 28,
      "type": "<ALPHANUM>",
      "position": 2
    },
    {
      "token": "f468cbb60ed98371",
      "start_offset": 29,
      "end_offset": 45,
      "type": "<ALPHANUM>",
      "position": 3
    },
    {
      "token": "false",
      "start_offset": 46,
      "end_offset": 51,
      "type": "<ALPHANUM>",
      "position": 4
    }
  ]
}

3. You can see that the analyzer breaks the second message after ef48be8c13ae0d81, but didn't for the first one. There are 4 tokens for foo, and 5 for bar.

4. The query bar in Kibana uses the Elasticsearch Query string query in conjunction with highlighting.

5. The query string query, and all other full text queries, understand how the field being queried is analyzed and will apply each field’s analyzer to the query string before executing.

6. The difference in tokens from the standard analyzer results in query and highlight behavior you are seeing.

   message: ef48be8c13ae0d81 looks for an exact match value from the tokens. Only "token": "ef48be8c13ae0d81") matches.

   message: ef48be8c13ae0d81* is a wildcard match against the tokens. Both "token": "ef48be8c13ae0d81" and "token": "ef48be8c13ae0d81,192d6982b1eeca95" match.