Discover и язык запросов KQL

Главный экран расследования инцидента — Discover — и язык, на котором вы спрашиваете логи.

Discover — раздел Kibana для интерактивного поиска по логам: поток событий, фильтры по полям и временная гистограмма.

Зачем нужен Discover

Discover — это то, ради чего стоял весь конвейер. Здесь вы вводите запрос, выбираете диапазон времени, и Kibana показывает совпавшие события списком, а сверху — гистограмму их распределения во времени. Это рабочее место дежурного инженера: «покажи все ошибки billing за последний час» — три клика и строка запроса.

  +-----------------------------------------+
  | [ KQL: status >= 500 ]   [ last 1h ]    |
  +-----------------------------------------+
  | гистограмма: ||  ||||  |  ||||||| (всплеск)|
  +-----------------------------------------+
  | 14:32 ERROR billing payment failed ...  |
  | 14:32 ERROR billing gateway timeout ... |
  | 14:31 ERROR auth   token expired ...    |
  +-----------------------------------------+

KQL: основа поиска

KQL (Kibana Query Language) — простой язык фильтрации. Базовая форма — поле: значение. Несколько примеров для логов:

Операторы and, or, not комбинируют условия, скобки группируют. Сравнения >, >=, < работают для числовых полей — поэтому так важно было привести status к числу на этапе обработки.

Поиск по trace_id: суперсила корреляции

Вот где окупается сквозной trace_id из урока про три столпа. Один запрос trace_id: "a1b2c3d4" вытаскивает все логи одного пользовательского запроса из всех сервисов в хронологическом порядке. То, что раньше требовало захода на семь машин, теперь — одна строка. Это самый частый приём при разборе инцидента.

Как работает под капотом

Когда вы пишете KQL, Kibana переводит его в Query DSL — родной JSON-язык запросов Elasticsearch — и шлёт в ES. Тот же запрос level: "ERROR" and status >= 500 под капотом превращается примерно в такое:

{
  "query": {
    "bool": {
      "must": [
        { "match": { "level": "ERROR" } },
        { "range": { "status": { "gte": 500 } } }
      ]
    }
  }
}

KQL — это просто удобная обёртка. Понимать связь полезно: сложные запросы и алерты иногда пишут сразу на Query DSL в Dev Tools, а KQL — для быстрого интерактивного поиска.

От поиска к сохранённым запросам

Discover — это не только разовый поиск. Удачно составленный запрос и набор отображаемых столбцов можно сохранить, превратив в готовый «вид» для типовой задачи: «все ошибки платежей», «медленные запросы», «активность подозрительного пользователя». Команда обычно накапливает библиотеку таких сохранённых поисков, и дежурный при инциденте не пишет KQL с нуля, а открывает подходящий вид и лишь сужает время. Это превращает индивидуальное умение «правильно спросить логи» в общий актив команды.

Полезно различать два инструмента сужения в Discover: строку запроса (KQL) и панель фильтров. Они эквивалентны по результату, но фильтры удобнее для быстрого добавления и отключения условий кликом (включил фильтр по сервису, посмотрел, выключил), а KQL — для сложной логики со скобками и операторами. На практике их сочетают: грубое сужение фильтрами, тонкое — выражением KQL. И помните про производительность: даже самый точный KQL по слишком широкому окну времени останется медленным, потому что Elasticsearch всё равно должен просмотреть все индексы периода — сначала время, потом текст запроса.

Частые ошибки

• Слишком широкий диапазон времени. Запрос «за всё время» по большому индексу медленный и грузит кластер. Сначала сузьте время, потом уточняйте KQL.
• Путать text и keyword в фильтрах. По полю text точное service: "billing-api" может не сработать так, как ждёте, из-за токенизации. Для точных совпадений фильтруйте по keyword-версии поля.
• Сравнения по строковому status. Если status остался строкой, status >= 500 даст неожиданный результат. Числовые сравнения требуют числового типа.

Итоги

• Discover — рабочее место для интерактивного поиска по логам с гистограммой во времени.
• KQL фильтрует в форме поле: значение с and/or/not и числовыми сравнениями.
• Поиск по trace_id собирает все логи одного запроса из всех сервисов — главный приём разбора инцидента.
• KQL под капотом транслируется в Query DSL Elasticsearch.