Сначала сузьте время, потом ищите

Самая частая причина «в логах ничего нет» — не отсутствие записей, а окно времени по умолчанию. Kibana ищет в выбранном интервале, и если там последние пятнадцать минут, а запрос вы отправили полчаса назад, результат будет пустым при полностью рабочем поиске. Возьмите привычку: сначала выставить интервал вокруг момента запроса (пара минут до и после), затем формулировать условие.

Обратная ошибка — слишком широкое окно на большом объёме: запрос выполняется долго и приносит тысячи чужих записей, среди которых свою уже не видно. Минуты вокруг события почти всегда лучше, чем сутки.

Ищите по сквозному идентификатору, а не по тексту

Поиск по фрагменту сообщения кажется естественным, но текст сообщений меняют разработчики, он повторяется у разных запросов и по-разному экранируется. Надёжнее искать по идентификатору, который сопровождает запрос через все сервисы. Обычно он называется traceId, trace_id, X-Request-Id, correlationId или requestId — точное имя зависит от системы, спросите у разработчиков один раз и запомните.

Если такой идентификатор возвращается в заголовке ответа, скопируйте его сразу после запроса — это самый быстрый путь к своим записям:

trace_id: "9f2c41ab7e5d4c02"

Если идентификатора в ответе нет, зацепкой служит уникальное значение из вашего запроса: номер заказа, идентификатор клиента, сумма с копейками. Главное — значение, которое не встречается у соседних запросов.

Минимум синтаксиса KQL, которого хватает

В строке запроса Kibana (язык KQL) достаточно нескольких конструкций:

  • trace_id: "9f2c41ab7e5d4c02" — точное совпадение значения поля.
  • service: "payments" and level: "ERROR" — оба условия одновременно.
  • message: *timeout* — часть строки, когда точного значения нет.
  • not level: "DEBUG" — убрать шум отладочных записей.
  • http.status_code >= 500 — сравнение для числовых полей.

Кавычки важны: без них строка с дефисами и двоеточиями разбивается на части, и поиск находит не то. Если поле не находится вообще, проверьте индекс — в разных индексах поля называются по-разному, и trace_id одного сервиса может быть tracing.id другого.

Что именно сверять с ответом

Найденные записи — это не «галочка, что логи есть», а материал для проверки. Смысл сверки в том, что ответ и логи должны рассказывать одну и ту же историю:

  1. Идентификаторы. Номер операции из ответа встречается в записях, и именно тот.
  2. Суммы и количества. Значение, посчитанное на бэкенде, совпадает с тем, что вернулось клиенту. Расхождение здесь — типичный дефект округления.
  3. Статусы и переходы. Если ответ говорит «оплачено», в логах должен быть переход в это состояние, а не только попытка.
  4. Отсутствие ошибок. Ответ 200 при записи уровня ERROR в тот же момент — повод разбираться, а не радоваться.
  5. Количество записей. Один запрос — одна операция; три записи о списании вместо одной означают повтор.
Логи содержат рабочие данные, поэтому не выкладывайте выгрузки в чаты и задачи целиком: маскируйте номера карт, телефоны и токены. Для отчёта обычно достаточно идентификатора, времени и одной строки записи.

Почему это утомляет и что с этим делать

Проблема ручной сверки не в сложности, а в переключении: отправил запрос в одном окне, скопировал идентификатор, перешёл в Kibana, выставил время, нашёл записи, вернулся к документации, сравнил суммы. Пять переключений на один запрос, и так по кругу каждый релиз. Именно здесь теряется внимание, а вместе с ним и дефекты.

Поэтому в Checkcraft запрос и логи живут в одной проверке: записи из Kibana подтягиваются по идентификатору из ответа, а правила сравнивают их поля с телом ответа автоматически. Результат виден списком: совпало или нет, и если нет — чем именно. Приложение работает на Windows и Linux, данные проекта хранятся локально.

Полезное рядом: рабочий процесс проверки API вместе с логами, правила для JSON и XML, программа для проверки API без кода.