Всем привет. В статье разберём, как с помощью open-source трекера ошибок Хоук восстанавливать цепочку событий перед ошибкой и быстрее понимать, что именно привело к сбою в приложении.
Представим обычную ситуацию: пользователь пишет в поддержку, что нажимает «Оплатить», но ничего не происходит. В мониторинге при этом есть ошибка. Видно, где она произошла в коде, виден URL страницы, браузер, устройство и окружение. Но открытым остается вопрос: что именно пользователь делал перед ошибкой?
Он сразу нажал «Оплатить»? До этого менял способ доставки? Обновлял страницу? Нажал кнопку несколько раз? Был ли перед ошибкой неудачный запрос к API? Без этой последовательности расследование часто превращается в угадывание: ошибка есть, но путь к ней не виден.
В чём проблема обычного расследования
Стек-трейс отвечает на вопрос «где произошла ошибка», а Breadcrumbs — на вопрос «как приложение к ней пришло». Именно эта информация помогает быстрее находить и устранять причины сбоев.
Например, в событии может быть видно:
страница: /checkout,
ошибка в обработчике оплаты,
браузер пользователя,
время возникновения ошибки.
Но при этом может быть непонятно:
с какой страницы пользователь пришёл,
был ли перед этим запрос на расчёт стоимости,
успешно ли сохранился адрес доставки,
какой именно сценарий привёл к падению.
Получается ситуация: мы видим саму ошибку, но не видим путь к ней. Именно эту проблему решают «хлебные крошки».
Что такое Breadcrumbs
Breadcrumbs – это цепочка событий, которые произошли перед ошибкой.
В неё могут попадать:
переходы между страницами,
клики пользователя,
сетевые запросы,
ответы API,
события из бизнес-логики,
важные состояния интерфейса.
Вместо одиночного сообщения «что-то сломалось на checkout» команда получает последовательность действий, которая к этому привела.
Как это выглядит на практике
Возьмём сценарий с оплатой. Пользователь открыл корзину, перешёл к оформлению заказа, выбрал адрес доставки, нажал «Оплатить», после чего приложение отправило запросы на сохранение адреса и создание платежа. Затем произошла ошибка.
navigation: /cart → /checkout
200 GET /api/checkout/order
ui: click "Сохранить адрес"
400 POST /api/checkout/address
ui: click "Оплатить"
logic: payment step submitted
logic: payment create skipped — address not saved
error: Payment failed
Здесь и кроется причина проблемы: заказ загрузился нормально, но при сохранении адреса доставки возникла 400 ошибка, и интерфейс не заблокировал кнопку «Оплатить». Пользователь дошёл до оплаты с неполным заказом, из-за чего упала ошибка в обработчике платежа.
Корень проблемы не в кнопке «Оплатить», а раньше: адрес доставки не сохранился, а UI не отреагировал на ошибку API. Breadcrumbs показывают, где сценарий пошёл не туда – ещё до финальной ошибки.
Что собирается автоматически
Событий браузера, которые записываются в хлебные крошки:
переходы между страницами,
клики по элементам,
fetch/XHR-запросы,
базовую информацию о браузере и окружении.
Такие события уже дают полезный контекст. Если перед ошибкой был запрос к API, его можно увидеть в цепочке. Если пользователь несколько раз нажал одну и ту же кнопку, это тоже будет заметно.
Что стоит добавлять вручную
Мониторинг может зафиксировать клик по кнопке, но не знает, что для вашей системы этот клик означает переход к оплате, подтверждение доставки или отправку формы. Поэтому в важных местах стоит добавлять свои Breadcrumbs:
переход между шагами формы,
отправку заказа,
выбор тарифа,
применение промокода,
успешное сохранение адреса,
начало оплаты,
получение ответа от платёжного сервиса.
Например:
hawk.breadcrumbs.add({ timestamp: Date.now(), type: "logic", category: "checkout.step", level: "info", message: "Пользователь перешёл к оплате", data: { step: "payment", orderId: order.id, }, });
Или для запроса:
hawk.breadcrumbs.add({ timestamp: Date.now(), type: "request", category: "fetch", level: "error", message: "POST /api/checkout/address 400", data: { method: "POST", url: "/api/checkout/address", status: 400, reason: "address_validation_failed", }, });
Такие события делают расследование понятнее: команда видит не просто техническую цепочку, а осмысленный сценарий.
Хлебные крошки на бэкенде
Breadcrumbs помогают показывать последовательность операций и на стороне сервера.
Например:
Вызов методов API
Запросы в базу данных
Обращения к внешним сервисам
Обращения к доменному уровню
Парсинг и обработку данных
Кастомную логику
Как правило, фрагменты хлебных крошек на бэкенде проставляются руками с помощью метода breadcrumbs.add().
Что в итоге
Breadcrumbs не заменяют информацию об ошибке, а добавляют к ней контекст. Сама ошибка отвечает на вопрос: где что-то сломалось. Breadcrumbs помогают ответить на другой вопрос: как пользователь до этого дошёл.
Для команды это означает меньше догадок, меньше ручного воспроизведения и более короткий путь от алерта до исправления бага. Breadcrumbs помогают быстрее выявлять и понимать причины ошибок, сокращая как MTTD (Mean Time to Detect), так и MTTR (Mean Time to Resolve) — ключевые показатели эффективности процесса обработки инцидентов. Разработчики быстрее замечают проблему, быстрее находят её источник и быстрее выпускают исправление.
