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

Телефон сообщает: доля 5xx на оплате выросла. Поддержка пишет «заказы не оплачиваются». Самая опасная реакция: увидеть слово timeout и объявить банк виноватым. Детектив сначала собирает время, место и свидетельства, потом проверяет версии. Дежурный делает то же самое с логами и трейсами.

Сначала сузь сцену

1. Проверь окружение и окно события: 30 июня, около 19:40 UTC, то есть 22:40 в Москве.
2. Найди внешний симптом в nginx: какой endpoint, коды и длительности.
3. Перейди в приложение: сервис, тип ошибки, зависимость.
4. Выбери один trace.id и восстанови последовательность.
5. Сравни до, во время и после. Одна строка не описывает масштаб.

Сохраняй исходные временные метки в UTC. Время компьютера дежурного и время интерфейса могут отличаться. Кроме того, часы серверов могут расходиться: порядок соседних строк не всегда причинный.

Внешний симптом

В учебном наборе вне окна 19:40 до 20:05 5xx нет. Внутри него ошибки идут на /api/payments; долгие 504 соседствуют с более быстрыми 502. Это говорит о сбое тракта оплаты, но ещё не говорит, на чьей стороне он начался.

Один запрос крупным планом

Это оплата заказа 104549: предупреждение о повторной попытке, затем сообщение о таймауте шлюза. В Discover таблица по умолчанию показывает свежие записи первыми. Для хронологического чтения используй консоль с sort: [{"@timestamp":"asc"}] или настрой направление в настоящей Kibana.

Не ожидай, что каждый сервис напишет строку с этим trace. В наборе этот идентификатор связывает записи payments. Отсутствующая строка orders не доказывает, что запрос не проходил через orders: логирование могло не записать этот этап. Также нет сетевого доступа к самому банку.

Факт отдельно от версии

Наблюдение	Что пока нельзя утверждать
payments записал BankTimeoutException	банк упал, а не сеть или пул соединений
nginx вернул 504 через около 30 секунд	таймаут настроен неправильно
ошибки прекратились после 20:05	исправление точно стало причиной восстановления

Таймлайн

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

После восстановления

Запиши воздействие на клиентов, интервал, доказательства, принятые меры и что подтвердилось. Сравни ошибки с числом попыток оплаты, а не с числом всех log events. Отдельно проверь повторные списания: retry мог успеть выполнить платёж, даже если ответ потерялся.

В следующем уроке посмотрим, как сохранить поиск работоспособным, когда инцидент сам генерирует поток ошибок.