Error tracking

Чем error tracking отличается от логов

Error tracking специализируется на исключениях и сбоях приложения: собирает stack trace и контекст, группирует повторения, связывает ошибку с release и поддерживает workflow исправления.

Логи описывают самые разные события, а error tracking создаёт управляемую очередь проблем. Метрика показывает рост error rate, но обычно не содержит конкретный stack trace. Для диагностики все три сигнала дополняют друг друга.

Grouping и fingerprint

Одна и та же ошибка может возникать тысячи раз с разными request ID, пользователями и параметрами. Grouping объединяет события по fingerprint: тип исключения, стек, сообщение и другие правила.

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

Полезные поля проблемы:

число событий и затронутых пользователей;
first seen / last seen;
environment и release;
browser/runtime/OS при необходимости;
trace/request ID и связанные логи;
статус: новая, назначенная, resolved, regression, ignored.

Releases и regressions

Release связывает появление ошибки с конкретным изменением. Если проблема исчезла после исправления, а затем снова возникла, система отмечает regression вместо потери истории.

Для читаемого stack trace может понадобиться загрузка source maps или символов. Их публикация должна быть ограничена: открытый исходный код и внутренние пути не всегда можно отдавать наружу.

Workflow исправления

Новая проблема → оценка влияния → контекст и воспроизведение
             → владелец/ticket → исправление → release
             → resolved → наблюдение за regression

Критичная массовая ошибка может инициировать инцидент, но каждое исключение не должно становиться отдельным звонком дежурному. Оповещения обычно строят по новой проблеме, резкому росту частоты или затронутому сценарию.

Приватность и безопасность

В исключении могут оказаться SQL, токены, cookies, персональные данные и содержимое форм. Нужны server-side scrubbing, allowlist полей, ограничение breadcrumbs и контроль доступа к event details. Маскирование только в интерфейсе недостаточно, если исходные данные уже сохранены.

Критерии выбора решения

поддержка нужных SDK и рантаймов;
настраиваемый grouping;
releases, regressions и source maps;
связь с tracing и логами;
интеграции с issue tracker и incident workflow;
контроль объёма событий, retention и стоимости;
self-hosted или регион обработки при требованиях к данным.

Типовые ошибки

Отправка всех логов как исключений и потеря фокуса.
Группировка только по сообщению с переменными параметрами.
Resolved без проверки следующего release.
Отсутствие environment: staging и production смешаны.
Хранение чувствительного request body в событии.

Связанные инструменты

Sentry — SDK, grouping, releases и контекст ошибок.
GlitchTip — открытая система с поддержкой Sentry SDK.
Better Stack — error tracking в связке с телеметрией и инцидентами.

Связанные материалы

Real User Monitoring — влияние frontend-ошибок на сессии.
Tracing — ошибка внутри цепочки запроса.
CI/CD — release и доставка исправления.

Материалы и источники

Sentry: Documentation — события, issues, releases и SDK.
Better Stack: Error tracking — Sentry-compatible сбор, grouping и incident workflow.
GlitchTip: Documentation — открытое отслеживание ошибок и Sentry SDK.