Методичка: Работа с логами в Kibana

0. Введение

Эта методичка поможет техподдержке самостоятельно искать логи, диагностировать проблемы и оформлять баг-репорты для разработчиков. Работаем в kibana93.logan.wellsoft.pro (Kibana 9.3, Elasticsearch 9.3).

Что вы научитесь делать

Искать записи через AI-агента и руками в Discover
Фильтровать по проекту (fields.ProjectName), уровню (level), времени и Request ID (fields.RequestId)
Отличать Information от Warning и Error
Понимать, почему старых логов нет (ILM-политика удаляет)
Оформлять issue со ссылками на конкретные записи (Single Document)

Совет: проходите модули по порядку. В каждом есть интерактивная задача — попробуйте решить её сами, прежде чем смотреть ответ.

🎯 Задание «Разведка»

Зайдите в Kibana → AI-агент и задайте вопрос: «Какие последние ошибки были у проекта legion за последние 15 минут?». Затем откройте вкладку Discover, выберите DataView ascore и найдите хотя бы одну запись за последние 15 минут.

Это задание выполняется в рабочей системе, здесь только самопроверка.

Я открыл Discover и увидел записи

1. AI-агент

AI-агент — чат-бот, встроенный в Kibana 9.3. Подключён к документации Kibana/Elastic и знает структуру наших индексов ascore-*. Модель — MiniMax с большим контекстным окном, поэтому длинные логи переваривает нормально.

Когда использовать

Нужен быстрый первичный анализ ошибки
Не уверены, какой DataView/поле искать
Хотите сформулировать запрос на естественном языке
Надо собрать цепочку по RequestId через несколько компонентов

Ограничения: агент путает названия проектов — у нас внутренний ключ в fields.ProjectName часто отличается от «человеческого» имени (comfortCity, а не «Комфорт-Сити»; pskDom, а не «ПСК Дом»). Пишите ключ в кавычках и в правильном регистре. Ответ приходит за 15–20 секунд — не тыкайте «ещё раз».

🎯 Задание «AI vs Руки»

Клиент жалуется: «Не проходит оплата в Легионе». Какой порядок действий оптимален?

Сразу писать разработчику, ничего не искать Сначала спросить AI-агента (fields.ProjectName:"legion", level:Error, последние 30 мин), затем сверить найденное в Discover по RequestId Ждать, пока агент найдёт всё сам, и передать его ответ клиенту Искать только по слову «оплата» без фильтров

2. Поиск в Kibana (Discover)

Вкладка Discover — основной инструмент. По умолчанию показывает последние 15 минут. Интервал меняется абсолютно (от-до) или относительно (последние N часов/дней).

DataView, которые реально есть

ascore — все индексы ascore-*, основной для общих поисков. Поле времени @timestamp.
ascore-errors — только ошибки (ascore-errors-*). Сюда пишутся исключения/ошибки отдельно.
ascore-oauth — логи авторизации (ascore-oauth-*). Поле времени timestamp (без @).

Ключевые элементы интерфейса

Строка поиска — KQL (Kibana Query Language) или Lucene
Фильтры (+) — точные фильтры по полям (fields.ProjectName, level, fields.RequestId, fields.Environment)
Временной селектор — календарь или пресеты
Раскрытие строки — стрелка слева → Single Document, видны все поля

🎯 Задание «Найди интервал»

Клиент сообщил об ошибке 16 апреля около 14:00. Какой временной диапазон выставить, чтобы не промахнуться и не ждать долгой выборки?

Последние 15 минут 16 апреля 00:00 — 20 апреля 23:59 16 апреля 13:00 — 16 апреля 15:00 За последние 30 дней

Памятка: если дата известна точно, сужайте интервал до 1–2 часов — поиск быстрее и меньше шума. Если не уверены, начинайте с суток и сужайте.

3. Фильтры и синтаксис поиска

Основные поля для фильтрации

`fields.ProjectName`	Внутренний ключ проекта: `legion`, `comfortCity`, `enco`, `ukDrevo`, `pskDom`, `usi` и др.
`level`	Уровень: `Information`, `Warning`, `Error` (`Fatal` — редко, у нас в основном в `ascore-errors-*`)
`fields.RequestId`	GUID запроса: `800124e2-0018-db00-b63f-84710c7967bb`
`fields.Environment`	`Production` / `Staging` / `Development`
`fields.Type`	`HttpRequest`, `HttpResponse`, `syncjob` и т.д.
`message` / `messageTemplate`	Текст лога и его шаблон

Синтаксис KQL

fields.ProjectName : "legion" and level : "Error"    — ошибки только в Легионе
fields.RequestId : "800124e2-0018-db00-b63f-84710c7967bb"  — все логи одного запроса
message : *timeout*                                  — подстрока (wildcard)
level : "Error" and not fields.Type : "HttpResponse" — ошибки без HTTP-шума
fields.ProjectName : ("legion" or "comfortCity")     — несколько проектов сразу

Важно: значения в кавычках — точное совпадение токена. Без кавычек KQL тоже сработает, но хуже при спецсимволах. Для поиска подстроки — звёздочки: *timeout*.

🎯 Задание «Собери запрос»

Найти все записи с уровнем Error по проекту comfortCity с конкретным RequestId rq-998. Составьте KQL-запрос:

Пример правильного ответа: fields.ProjectName : "comfortCity" and level : "Error" and fields.RequestId : "rq-998"

🎮 Симулятор поиска

Попробуйте фильтры. Введите, например, level:Error или legion и нажмите Search.

DataView: Время:

Введите запрос и нажмите Search...

4. Типы логов и хранение

Уровни логирования

Information — штатное событие. Обычно HTTP-запрос/ответ. В проде их 99.86% от всех логов.

Warning — стоит обратить внимание, но не критично. Предвестник. ~0.14% объёма.

Error — что-то отвалилось, нужен разбор. ~0.003% объёма, но именно это важно.

Fatal — полный крах. Крайне редко, обычно попадает в индекс ascore-errors-*.

Политика хранения (целевая)

Поскольку 78% объёма — это HttpRequest/HttpResponse на уровне Information (нужны только для real-time диагностики), а Error-ов 0.003% (нужны долго) — храним их по-разному:

Что	Индекс	Срок
HTTP-шум (Info + Type:HttpRequest/HttpResponse)	`ascore-http-*`	3 дня
Остальной Information	`ascore-logs-*`	7 дней
Warning	`ascore-logs-*`	14 дней
Error / Fatal	`ascore-errors-*`	30 дней

Вывод: если клиент жалуется на событие недельной давности — HttpRequest-логов уже нет, но Error-запись скорее всего осталась в ascore-errors-*. Если и там пусто — ошибки просто не было, и дело в клиенте/интеграции.

Переходный период: пока политика по уровням не раскатана, действует общая — 7 дней на всё (ILM ascore-logs-ilm-policy). Следите за объявлениями в канале DevOps.

🎯 Задание «Что осталось?»

Сегодня 21 апреля. Клиент сообщил о странном поведении 3 апреля. Какие логи гарантированно ещё есть (после внедрения целевой политики)?

Только Error и Fatal в ascore-errors-* Information, Warning, Error — всё на месте Ничего не осталось, всё удалено Только логи авторизации в ascore-oauth-*

5. Dashboard: быстрая диагностика

Дашборд показывает только ошибки (Error/Fatal из ascore-errors-*) по проектам. Не замена детальному поиску, но за секунды отвечает: есть ли массовый сбой.

Как читать дашборд

График ошибок по времени — всплеск = инцидент
Таблица снизу — группировка по паттерну ошибки. Например: «TimeoutException — 30 раз за 10 минут»
Если на проекте 0 новых ошибок за сутки, а клиент жалуется — проблема на стороне клиента или интеграции, а не в платформе

Лайфхак: если клиент звонит и кричит «всё отвалилось», откройте дашборд за последние 15 минут. Нет всплеска? Спокойно: «По системным логам сбоев не зафиксировано, проверим ваше подключение».

🎯 Задание «Интерпретация»

На дашборде видно: у проекта enco ошибки растут плавно в течение 3 часов, а у legion — 1 резкий скачок и тишина. Что сказать коллегам?

Оба проекта сломаны одинаково, нужен один общий тикет enco — вероятно, деградация (утечка/зависание), legion — единичный сбой Дашборд врёт, ничему не верить Нужно ждать ещё 24 часа перед любыми выводами

6. Практические кейсы

Кейс А: «Житель не может оплатить»

Клиент прислал скриншот. В тикете есть лицевой счёт и сумма. Что делать?

Discover → DataView ascore, интервал ±1–2 часа вокруг обращения
Фильтр fields.ProjectName : "legion" (или нужный ЖК)
Поиск по лицевому счёту в message: message : *лс123456*
Если пусто — по сумме: message : *1500* (без запятой)
Если нашли запись — копируете fields.RequestId, ищете по нему всю цепочку
Если ничего нет — смотрите в ascore-errors-* по тому же проекту и времени

# Пример рабочей цепочки поиска:
fields.ProjectName : "legion" and message : (*лс123456* or *150000*)
→ нашли запись, скопировали fields.RequestId: 800124e2-...
→ fields.RequestId : "800124e2-..."
→ видим входящий HttpRequest и HttpResponse "200 OK"
→ но следом Error в ascore-errors-* по тому же RequestId? Ставим задачу разработчику

Кейс Б: Ответ "OK", но действие не выполнилось

Иногда запрос принят успешно (HTTP 200), но дальнейшая обработка (очередь, интеграция) отвалилась молча. В Kibana видно факт приёма, но не факт доведения до конца.

Ищите по тому же fields.RequestId записи уровня Error/Warning — часто бывают следом.
Ищите в ascore-errors-* по этому RequestId — туда пишется отдельно.
Если связанных ошибок нет — проблема вне Ascore (очередь, внешний сервис, клиент).

🎯 Задание «Следопыт»

Вы нашли запись в ascore-logs-* с fields.RequestId : "pay-777", ответ HttpResponse 200 OK, но клиент говорит, что деньги не прошли. Где ещё искать?

Правильный подход: искать тот же fields.RequestId в DataView ascore-errors, искать записи уровня Error/Warning по этому ID, смотреть следующие записи по времени в этом же проекте. Если связанных ошибок нет — проблема в очереди, валидации или внешней системе.

🎯 Задание «Оформление задачи»

Вы нашли подозрительный лог. Как правильно передать его разработчику?

Скопировать текст лога в чат Telegram Создать issue: ссылка на View Single Document + fields.RequestId + проект + время + описание Просто сказать устно: «Там что-то в логах красное» Сделать скриншот экрана и отправить на почту

7. Итоговый тест

Ответьте на 5 вопросов. Чтобы пройти, нужно минимум 4 правильных.

1. AI-агент гарантирует 100% точность названий проектов?

Да, он всегда прав Нет, может путать регистр / кириллицу-латиницу (comfortCity vs «Комфорт-Сити»)

2. Как правильно найти подстроку в поле message?

Просто ввести слово без звёздочек Использовать wildcard: message : *timeout* Только через regex

3. Information-логи уровня HttpRequest от 10-дневной давности скорее всего...

На месте, хранятся 30 дней гарантированно Уже удалены ILM-политикой — HTTP-шум держится максимум несколько дней Доступны только через AI-агента

4. Поле fields.RequestId позволяет...

Найти только первый лог запроса Связать все логи одного пользовательского действия в цепочку во всех индексах ascore-* Удалить логи из системы

5. На дашборде нет всплеска ошибок, но клиент жалуется. Что делать?

Сказать клиенту, что у него глюки Искать по message (лицевой счёт/сумма), по fields.RequestId, проверить ascore-errors-* и внешние интеграции Ждать, пока ошибки появятся на дашборде