Как сделать шаблон сопоставления для поля ключевого слова Elasticsearch Query 6.4.2

Question

Проблема:

Данные нашего журнала содержат 27-34 миллиона записей для / event-heartbeat. Мне нужно отфильтровать эти записи, чтобы увидеть только жизнеспособные сообщения журнала в Кибане.

Использование фильтров Kibana с подстановочными знаками не работает. Таким образом, я думаю, что мне придется написать QueryDSL, чтобы сделать это в версии 6.4.2 Elasticsearch, чтобы заставить его отфильтровывать сердцебиение события.

Я искал и не могу найти хороших объяснений о том, как выполнить сопоставление с шаблоном, чтобы найти все записи, которые не содержат / event-heartbeat в сообщении.

Вот лог-сообщение:

@timestamp:
    June 14th 2019, 12:39:09.225
host.name:
    iislogs-production
source:
    C:\inetpub\logs\LogFiles\W3SVC5\u_ex19061412.log
offset:
    83,944,181
message:
    2019-06-14 19:39:06 0.0.0.0 GET /event-heartbeat id=Budrug2UDw 443 - 0.0.0.0 - - 200 0 0 31
prospector.type:
    log
input.type:
    log
beat.name:
    iislogs-production
beat.hostname:
    MYHOSTNAME
beat.version:
    6.4.2
_id:
    yg6AV2sB0_n
_type:
    doc
_index:
    iislogs-production-6.4.2-2019.06.14
_score:
    - 

Сообщение - это ключевое слово, поэтому я могу безболезненно писать его.

Я использовал синтаксис Lucene

NOT message: "*/event-heartbeat*"

This is the anti pattern the kibana filter generates.
{
  "query": {
    "bool": {
      "should": [
        {
          "match_phrase": {
            "message": "*event-heartbeat*"
          }
        }
      ],
      "minimum_should_match": 1
    }
  }
}

Я попробовал предлагаемое решение ниже с помощью huglap. Я также скорректировал свой запрос на основе его комментария и попробовал два способа Я изменил его с помощью слова «слово» вместо «совпадение» и попробовал оба способа, потому что поле технически является ключевым словом, поэтому я мог безболезненно писать сценарии. Запрос по-прежнему возвращает записи журнала пульса событий.

Вот два запроса, которые я пробовал из предложенного ниже решения:

GET /iislogs-production-*/_search
{
   "query":{
      "bool":{
         "must":{
            "match_all":{

            }
         },
         "filter":{
            "bool":{
               "must_not":[
                  {
                     "term":{
                        "message.whitespace":"event-heartbeat"
                     }
                  }
               ]
            }
         }
      }
   }
}

GET /iislogs-production-*/_search
{
   "query":{
      "bool":{
         "must":{
            "match_all":{

            }
         },
         "filter":{
            "bool":{
               "must_not":[
                  {
                     "match":{
                        "message.whitespace":"event-heartbeat"
                     }
                  }
               ]
            }
         }
      }
   }
}

Отображение индекса: https://gist.github.com/zukeru/907a9b2fa2f0d6f91a532b0865131988

Answer 1

Задумывались ли вы о бул-запросе must_not? Поскольку вы работаете со всем набором и не заботитесь о формировании функции релевантности, я предлагаю использовать фильтр вместо запроса. Вы получите лучшую производительность.

{
   "query":{
      "bool":{
         "must":{
            "match_all":{

            }
         },
         "filter":{
            "bool":{
               "must_not":[
                  {
                     "match":{
                        "message.whitespace":"event-heartbeat"
                     }
                  }
               ]
            }
         }
      }
   }
}

В этом примере предполагается, что вы выполняете запрос к текстовому полю, поэтому вместо запроса "term" используется запрос "match". Вы также должны убедиться, что поле проанализировано (действительно токенизировано) в соответствии с вашими целями. Тот факт, что в запросе есть черта, создаст проблемы, если вы используете простой или даже стандартный анализатор. Elasticsearch разбил бы термин в двух словах. Вы можете попробовать анализатор пробелов на этом или просто удалить тире из запроса.