Sentry не спасает продукт, если в него сливать всё подряд: вот как настроить шум

Sentry не спасает продукт, если в него сливать всё подряд: вот как настроить шум

Sentry полезен не как «лог ошибок», а как фильтр: он показывает, где падает пользовательский путь. Но если без дисциплины, через неделю там будет 10 тысяч одинаковых алертов, и команда начнёт игнорировать вообще всё.

Что обычно ломают:
— не ставят release и environment, поэтому прод, стейдж и локалка смешиваются;
— ловят исключения на каждом try/catch, вместо того чтобы отсекать ожидаемые ошибки;
— не настраивают sampling и breadcrumbs, из-за чего тяжело понять контекст;
— не группируют события по реально важному ключу, и один баг распухает в десятки инцидентов.

Минимальный рабочий набор: 1) отправляй только неожиданные ошибки; 2) помечай релиз, окружение и пользователя; 3) добавляй теги по фиче, роуту и платёжному сценарию; 4) сразу включай алерты только на то, что влияет на деньги или вход в продукт. Тогда Sentry превращается из мусорки в карту рисков.

Отдельная ловушка — фронт и бэк живут в разных правилах. На фронте полезнее видеть цепочку действий пользователя, на бэке — точный stack trace и payload. Если не разделить эти два потока, в расследовании начнётся лишняя археология.

Лучше один аккуратный проект в Sentry с понятными тегами, чем пять проектов, где никто не знает, куда смотреть.