Как найти root cause инцидента за 5 минут с Konso

Шаг 1. Откройте алерт и зафиксируйте временной диапазон

Перейдите в раздел Метрики в вашем проекте Konso. Найдите метрику, вызвавшую алерт — обычно это error_rate или http_errors_count. Посмотрите на график и определите точный момент начала роста ошибок: это ваша точка отсчёта. [скриншот: график метрики с видимым всплеском ошибок, курсор указывает на момент начала] Запомните или скопируйте время начала инцидента — оно понадобится на следующем шаге.

Шаг 2. Установите временной фильтр

В правом верхнем углу интерфейса Konso установите временной диапазон: начало — за 2–3 минуты до всплеска, конец — текущий момент или время окончания инцидента. Узкий диапазон критичен — он сократит объём данных в 10–20 раз и позволит видеть только релевантные события. [скриншот: выбор временного диапазона в интерфейсе Konso с установленным кастомным периодом]

Шаг 3. Перейдите в раздел Логи и примените фильтры

Откройте раздел Логи. Примените следующие фильтры: • Уровень: Error, Critical (снимите Warning и Info — это шум на этапе диагностики) • Сервис или endpoint: введите название сервиса или путь /api/payments [скриншот: интерфейс логов Konso с применёнными фильтрами по уровню и сервису] Вы увидите только ошибки из нужного сервиса за выбранный период — именно то, что нужно.

Шаг 4. Найдите первую ошибку и откройте детали

Отсортируйте логи по времени по возрастанию — первая ошибка в списке, скорее всего, и есть источник проблемы. Кликните на запись, чтобы раскрыть детали. [скриншот: развёрнутая запись лога с полями: message, exception, stackTrace, userId, correlationId, timestamp] Обратите внимание на: • message и exception — описание ошибки • stackTrace — конкретная строка кода • correlationId — идентификатор запроса для поиска всей цепочки • userId — кто из пользователей пострадал первым

Шаг 5. Проследите цепочку запроса по correlationId

Скопируйте значение correlationId из открытой записи. В поле поиска логов введите этот correlationId. Снимите фильтр по уровню — теперь вам нужны все записи с этим ID, включая Info. [скриншот: результаты поиска по correlationId — хронологическая цепочка событий одного запроса] Вы увидите полный путь запроса: от входа в систему до места сбоя. Это покажет, на каком именно шаге произошёл отказ — например, timeout внешнего API, отсутствие записи в БД или нарушение валидации.

Шаг 6. Оцените масштаб через Value Tracking

Перейдите в раздел Value Tracking. Найдите событие, соответствующее упавшей операции — например, payment.completed или payment.failed. Установите тот же временной диапазон. [скриншот: дашборд Value Tracking с графиком payment.completed за период инцидента — видимое падение] Это ответит на вопрос «какой ущерб»: сколько оплат не прошло, в какой момент всё упало и восстановилось ли уже.

Шаг 7. Сформулируйте root cause

У вас теперь есть всё необходимое для чёткого описания инцидента: • Когда началось — из метрики • Что именно упало — из первого Error-лога • Где в коде — из stackTrace • Почему — из цепочки по correlationId • Ущерб — из Value Tracking Пример формулировки: «В 14:23 UTC начался рост ошибок на /api/payments. Root cause: timeout при обращении к fraud-check сервису (>3000ms). Затронуто 47 оплат за 12 минут. Сервис восстановился в 14:35 после рестарта fraud-check.»