Більшість команд налаштовує Sentry у перший день проєкту. До третього місяця Slack-канал ворожий. Алерти кожні п'ять хвилин. Stack trace-и, які ніхто не читає. У каналі «production-errors» 4 000 непрочитаних повідомлень.
До шостого місяця команда заглушує канал. До дванадцятого — ніхто не знає, коли щось справді зламано, бо все виглядає зламаним.
Це alert fatigue, і це не вина Sentry. Дефолти ловлять усе; ви маєте навчити їх, що важливо.
Цей пост — конфігурація, що перетворює Sentry (або Bugsnag, або Highlight, або будь-який еквівалент) з генератора шуму на джерело сигналу. П'ять категорій помилок, що з ними робити, і операційна дисципліна за цим.
Чому error tracking іде не так
Три паттерни, які ми бачимо постійно:
Кожен exception — це P1. Команда вмикає Sentry, кожен uncaught exception стріляє алертом, алерти заглушують, і тепер нічого не стріляє алертами.
Front-end і back-end помилки ділять канал. 0.1% JS error rate на high-traffic сайті — це 1 000 алертів/годину. Сигнал з беку (де помилки зазвичай важливіші) ховається.
Без групування. Sentry групує за stack trace за замовчуванням, але команди це вимикають, бо «хочу бачити кожну окремо». Результат: 500 алертів за той самий зламаний database-запит.
Фікс — не інший інструмент. Це конфігурація.
П'ять категорій
Кожна помилка, яку продукує ваш застосунок, потрапляє в одну з цих. Однакове ставлення до всіх — джерело проблеми.
1. Помилки введення користувача
Провали валідації, malformed-запити, очікувані 400-ті. Це не баги; це система, що працює як спроєктовано.
Не алертуйте. Навіть не захоплюйте їх, поки не розслідуєте конкретну проблему. Це шум.
У Sentry: фільтруйте на рівні SDK. Помилки зі статус-кодом 400-499 (більшість з них) не мають доходити до Sentry. 4xx-помилки, що мають значення (401 від авторизованого endpoint, 403 від адмін-endpoint, 404 від глибокого посилання) можуть бути варті захоплення як breadcrumbs, але не як events.
2. Транзитні помилки
Network timeouts, провали third-party API, rate-limit hits. Вони трапляються, ви ретраїте, наступна спроба успішна.
Захоплюйте їх з sample rate (1-5%) для аналізу трендів. Не алертуйте на окремі випадки. Алертуйте лише коли rate перевищує threshold (наприклад, «понад 5% викликів Stripe провалились за останні 5 хвилин»).
У Sentry: тегайте ці помилки атрибутом transient: true. Налаштуйте issue alert, що їх ігнорує. Налаштуйте metric alert на rate.
3. Баги коду
Справжні баги. Null reference, type mismatch, off-by-one, рядок коду, що був неправильним з моменту деплою.
Це ті, на які треба алертувати. Кожна нова поява багу коду має доходити до команди.
Але «кожна нова поява» потребує групування. Дефолтний fingerprinting Sentry (групувати за stack trace) зазвичай правильний. Не вимикайте. Один баг, що продукує 10 000 помилок — це один алерт, не 10 000.
4. Помилки середовища
Database connection refused, disk full, container OOM-killed. Код нормальний; середовище провалилось.
Алертуйте негайно. Це зазвичай вказує на інфраструктурні проблеми, не code-проблеми, і вони схильні каскадувати.
Окремий канал від code-багів. Тріаж для «база лежить» інший, ніж для «у нас null reference».
5. Регресії продуктивності
Повільні завантаження сторінок, повільні API-відповіді, довгі запити. Не помилки самі по собі, але пов'язані.
Відстежуйте окремо (часто поза Sentry, в інструменті типу Datadog або Grafana). Алертуйте на перевищення threshold: «p95 API response time перевищив 1 секунду на 5 хвилин».
Конфігурація, що працює
Конкретне Sentry-налаштування, яке ми відвантажуємо на більшості проєктів:
Sentry.init({
dsn: process.env.SENTRY_DSN,
environment: process.env.NODE_ENV,
release: process.env.GIT_SHA,
tracesSampleRate: 0.1, // 10% trace-ів, більше — просто дорого
beforeSend(event, hint) {
// Категорія 1: фільтр помилок введення користувача
if (hint.originalException?.statusCode && hint.originalException.statusCode < 500) {
return null;
}
// Категорія 2: тегати транзитні помилки (alerting rule ігноруватиме окремі випадки)
if (isTransient(hint.originalException)) {
event.tags = { ...event.tags, transient: 'true' };
// Sample транзитні помилки на 5%
if (Math.random() > 0.05) return null;
}
return event;
},
});
function isTransient(err) {
return err?.code === 'ECONNRESET'
|| err?.code === 'ETIMEDOUT'
|| err?.statusCode === 429
|| err?.statusCode === 502
|| err?.statusCode === 503;
}Це 30 найвпливовіших рядків, які можна додати. Фільтрує 80% «помилок», що шум, тегає 15%, що — періодичні інфраструктурні проблеми, лишає 5%, що — справжні баги, для landing у канал алертів.
Три канали, не один
Більшість команд має один канал помилок у Slack. Розбийте на три:
- #bugs-prod — баги коду (Категорія 3). Нові появи справжньої code-помилки. Команда читає цей канал.
- #infra-prod — помилки середовища (Категорія 4). База лежить, disk full, рестарти контейнерів. On-call читає.
- #metrics-prod — алерти на rate продуктивності і транзитних помилок (Категорії 2 і 5). Лише перевищення threshold. Engineering ревьюїть це щотижня.
Помилки введення користувача (Категорія 1) не отримують канал. Це не events.
Причина для трьох каналів: кожен має іншу терміновість і аудиторію. Баги — для команди тріажити і призначати. Інфра — для on-call. Metrics — для engineering manager помічати тренди.
Один змішаний канал змушує усіх фільтрувати той самий шум, і ніхто не фільтрує консистентно.
Операційна дисципліна
Три звички, що визначають, чи setup лишається корисним:
1. Тріажте кожен алерт у #bugs-prod
Коли новий bug-alert стріляє, хтось призначає його собі і або виправляє, або позначає як не-баг. Issues, що сидять у каналі днями — сигнал, що канал не читають.
У Sentry є кнопка «ignore». Використовуйте. Помітка не-багу як ignored запобігає повторному стрілянню. Канал лишається чистим.
2. Резолвте виправлені issues
Коли баг виправлено у деплої, помітьте resolved у Sentry. Поставте Sentry на «regression» alerting: якщо той самий fingerprint реокурує після резолву — стріляє алерт. Це ловить регресії автоматично.
3. Ревью каналу metrics-prod щотижня
Trend alert-и тихі, поки хтось не подивиться. 15-хвилинне ревью щопонеділка ловить slow-burn issues (rate транзитних помилок повзе вгору, p95 latency дрифтить, новий third-party API стає нестабільним).
Без ревью slow-burn issues стають алертами лише коли стають outage-ами. Тижневе ревью — дешева страховка.
Що моніторити додатково
Sentry ловить помилки. Не ловить усе, що має значення:
Uptime-моніторинг. Pingdom, Better Uptime, UptimeRobot. Б'є по ваших endpoints із зовнішніх локацій, алертує при провалах. Ловить outage-и, де сервер лежить (Sentry не може репортити помилку, якщо не може досягти сервера).
Synthetic-перевірки. Скриптовані user journey-ы («чи можу залогінитись? чи бачу дашборд?») запускаються кожні 5 хвилин з кількох регіонів. Checkly або Datadog Synthetics. Ловлять проблеми, що помилки не ловлять (сторінка, що вантажиться, але зламана).
Real-user monitoring (RUM). Datadog RUM, Replay від Sentry або просто browser performance API, репортовані у вашу аналітику. Ловлять проблеми, що впливають на користувачів, але не кидають помилок (CTA, що не стріляє свій event handler, форма, що тихо провалює submit).
Кожна покриває категорію провалів, яку інші пропускають. Оберіть дві-три, що пасують вашому продукту; не намагайтесь запустити усі.
Розумне налаштування
Конкретний стек, який ми рекомендуємо для типового веб-застосунку:
- Sentry для error tracking. Конфігурація вище. Три Slack-канали.
- Better Uptime для uptime-моніторингу. Б'є головну і /api/health щохвилини. Алертує on-call при двох послідовних провалах.
- Sentry Replay або PostHog Recordings для випадків «користувач репортить дивну проблему». Подивитись, що він насправді робив.
- Кастомний дашборд, що показує error rate, p95 latency і трафік за останні 7 днів. Ми використовуємо Grafana; Datadog теж нормально.
Сумарна ціна: зазвичай під $200/місяць для застосунку з помірним трафіком. Сигнал/шум визначає, чи команда насправді читає алерти, що визначає, чи setup взагалі вартий оплати.
Чого ми перестали робити
Конфігурації, які ми рекомендували раніше і тепер пропускаємо:
- Захоплення кожного console.warn. Додає шум без цінності. Захоплюйте помилки, не warning.
- Захоплення кожного провалу analytics-скрипта. Third-party скрипти провалюються постійно. Фільтруйте на рівні SDK.
- Алерти на окремі front-end помилки. З мільйоном page views у вас мільйон ботів, що кидають дивні помилки. Поставте rate threshold.
- Маршрутизація алертів напряму у email. Email — для речей, які прочитаєте пізніше. Алерти — для зараз. Використайте Slack/Discord/PagerDuty.
Чим простіше налаштування, тим імовірніше воно лишається корисним.
Підсумок
- П'ять категорій помилок, кожна з різним поводженням.
- Фільтр помилок введення повністю.
- Sample транзитних помилок; алерти на rate, не окремі випадки.
- Групувати баги коду за stack trace; алертувати на нові появи.
- Алертувати негайно на помилки середовища.
- Відстежувати продуктивність окремо.
Ціль — не нуль алертів. Ціль — щоб кожен алерт був справжнім сигналом. Команда, що отримує один алерт на тиждень і уважно його читає, виграє у команди, що отримує 50 алертів на день і ігнорує усі.
Якщо хочете веб-застосунок з цим моніторинг-налаштуванням зашитим, подивіться, як ми працюємо з веб-застосунками.