Почему Sentry шумит не из-за багов, а из-за плохой настройки фильтров

Почему Sentry шумит не из-за багов, а из-за плохой настройки фильтров

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

Базовый чек-лист настройки:
— разделите проекты по средам, а не сваливайте staging и production в один поток;
— отфильтруйте ошибки, которые уже пойманы обработчиком;
— отключите шум от ботов, health-check'ов и известных интеграций;
— задайте теги для релиза, окружения и пользователя, чтобы быстро искать паттерн.

Если алертят всё подряд, проблема почти всегда в одном из трёх мест: слишком широкий capture, нет ignore rules, или в коде бросают исключение там, где нужен контролируемый ответ. Sentry не чинит архитектуру, но очень быстро показывает, где у вас «ошибка» стала обычным сценарием.

Ещё одна типовая ошибка — смотреть только на stack trace. Полезнее сначала проверить частоту, окружение и путь пользователя до падения. Тогда один и тот же баг перестаёт выглядеть как десять разных инцидентов.

Держите Sentry как фильтр сигнала, а не как склад исключений: меньше мусора в потоке, быстрее triage, меньше ложных тревог.