Как по фрагменту лога с ошибкой определить, в какую сторону копать дальше при диагностике проблемы?

Короткий ответ

Нужно последовательно выделить: что именно произошло (тип ошибки/исключения), где это произошло (сервис, модуль, строка/функция), когда (временная метка — совпадает ли с ростом метрик ошибок) и есть ли идентификатор для связи с другими сигналами (trace_id, order_id) — это и определяет следующий шаг диагностики.

Как это работает подробнее

большинство логов ошибок содержат структуру "что сломалось" (тип исключения, код ошибки), контекст (какой сервис, какая операция) и иногда stack trace с конкретным местом в коде. Сопоставление временной метки лога с графиком метрик (например, ростом error rate в тот же момент) подтверждает, что это не единичный случай, а часть более широкой проблемы.

Пример кода

example.txtКопировать

2024-05-01T10:02:11Z ERROR checkout: NullPointerException at CheckoutService.applyDiscount(line 142)
caused by: discount_code lookup returned null for code="SUMMER24"

Что использовать на практике

• Практика. первый шаг — понять частоту: это единичная ошибка (можно отложить) или массовая (требует немедленной реакции), для чего смотрят агрегированные метрики ошибок за тот же период. Второй шаг — если есть trace_id, посмотреть полный путь запроса в системе трассировки, чтобы понять, что было до ошибки. Третий шаг — проверить, не связана ли ошибка с недавним деплоем (по времени совпадает с релизом).
• Практика. Из этого фрагмента видно: сервис checkout, конкретная функция applyDiscount, причина — отсутствующий код скидки SUMMER24; следующий шаг — проверить метрику частоты этой ошибки (rate(errors_total{type="NullPointerException"}[5m])) и узнать, не истёк ли промокод в базе данных, прежде чем делать вывод о баге в коде.

Подводные камни

• Частые ошибки. сразу чинить код по одному сообщению об ошибке, не проверив, насколько массовое это явление; игнорировать временную корреляцию с деплоем или изменением конфигурации; не смотреть на уровень (WARN vs ERROR) и полный контекст сообщения, делая поспешные выводы по одной строке без деталей (например, по сокращённому сообщению без стека вызовов).