Разбор инцидента по логам

Соберём всё изученное в один практический навык: как от сигнала «что-то сломалось» дойти до корневой причины по логам.

Разбор инцидента — методичное движение от симптома к корневой причине через сужение времени, фильтрацию и корреляцию логов разных сервисов.

Зачем нужна методика

В стрессе инцидента легко начать хаотично листать логи и утонуть в миллионах строк. Методика превращает панику в алгоритм: каждый шаг сужает область поиска. Это разница между «полчаса тыкаемся» и «за пять минут нашли виновный сервис и причину».

Шаг 1: зафиксировать симптом и время

Инцидент с чего-то начался: алерт «всплеск 5xx», жалоба «не оплачивается с 14:30». Первое — поставить в Discover диапазон времени вокруг события (14:25–14:40) и не искать по всей истории. Узкое окно времени — главный множитель скорости.

Шаг 2: найти ошибки в окне

Фильтруем шум, оставляем сбои:

status >= 500 and @timestamp >= "2026-06-24T14:25:00"

Смотрим на гистограмму: всплеск начался ровно в 14:31. Уже знаем точное время начала — сужаем окно ещё.

Шаг 3: локализовать сервис

Строим (или открываем готовый) агрегат «ошибки по сервисам» за окно. Видим: 90% ошибок в billing, остальные сервисы спокойны. Виновник локализован — billing. Теперь фокусируемся на нём:

service: "billing" and level: "ERROR"

Шаг 4: ухватиться за trace_id

Открываем любую ошибку billing, берём её trace_id и разворачиваем весь путь этого запроса по всем сервисам:

trace_id: "a1b2c3d4"

Теперь перед нами хронология одного запроса: gateway → auth (ок) → billing → внешний платёжный шлюз. И в логе billing: "gateway timeout after 30000ms". Корневая причина: внешний платёжный шлюз перестал отвечать, billing висит на таймауте и отдаёт 500.

  СИМПТОМ: всплеск 5xx с 14:31
     |  (сузили время)
  ОШИБКИ: status>=500 --> начало 14:31
     |  (агрегат по сервисам)
  СЕРВИС: billing 90% ошибок
     |  (trace_id одного запроса)
  ПРИЧИНА: таймаут внешнего платёжного шлюза

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

Каждый шаг — это применение одного из изученных механизмов: сужение времени опирается на @timestamp и Data View, фильтр ошибок — на числовой status (вот зачем был :int), агрегат по сервисам — на terms по keyword-полю, корреляция — на сквозной trace_id. Инцидент-разбор не отдельная магия, а связка всех ранее изученных кирпичиков в нужном порядке: воронка от широкого симптома к точечной причине.

После того как причина найдена

Разбор инцидента не заканчивается на нахождении корневой причины — он заканчивается на том, чтобы этот инцидент стало легче ловить в следующий раз. Полезная привычка: завершив разбор, спросить, можно ли было обнаружить проблему раньше и автоматически. Если виновником был таймаут внешнего шлюза, стоит завести алерт именно на этот паттерн, чтобы в следующий раз система предупредила сама, а не пользователи. Так каждый разобранный инцидент превращается в новый алерт или дашборд-панель, и наблюдаемость системы постепенно растёт. Логи здесь — не только инструмент тушения пожара, но и источник знаний о том, какие пожары вообще случаются.

Стоит также честно признать пределы логов в разборе. Логи отвечают на «что и почему случилось», но плохо отвечают на «почему именно сейчас» и «насколько это распространено» — здесь нужны метрики и трейсы. Зрелый разбор инцидента редко идёт по одному столпу: метрика показала аномалию, лог объяснил причину, трейс подтвердил, где в цепочке теряется время. Умение переключаться между тремя источниками и не пытаться выжать из логов то, для чего они не предназначены, — признак опытного инженера эксплуатации.

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

Искать по всей истории. Запрос без сужения времени медленный и тонет в нерелевантном. Сначала окно, потом фильтры.
Застрять на одном сервисе. Ошибка в billing может быть следствием проблемы выше или ниже. trace_id показывает всю цепочку — смотрите её целиком, а не только «шумящий» сервис.
Путать корреляцию с причиной. Сервис с наибольшим числом ошибок не всегда виновник — иногда он лишь первым «закричал». Проверяйте причинно-следственную цепочку по времени и trace_id.

Итоги

Разбор инцидента — воронка: симптом → сужение времени → ошибки → виновный сервис → trace_id → причина.
Сужение окна времени — главный ускоритель; не ищите по всей истории.
trace_id разворачивает весь путь запроса по сервисам и ведёт к корню.
Методика — это связка всех ранее изученных механизмов в правильном порядке.