Настройка Error Tracking (Sentry) для веб-приложения

Настройка Error Tracking (Sentry) для веб-приложения

Sentry — стандарт de facto для отслеживания ошибок. Но 90% разработчиков ограничиваются установкой SDK, забывая про source maps, release tracking и фильтрацию шума. Результат: тонны ложных срабатываний, потеря критических ошибок и часы на их поиск. Мы настраиваем Sentry под ключ — от интеграции с Laravel (PHP 8.3) и React 18 до алертов в Telegram и автоматической привязки коммитов через CI/CD. Опыт работы над 15+ проектами с нагрузкой до 10k RPS гарантирует, что вы не утонете в шуме, а каждая ошибка будет вовремя замечена.

Недавно на проекте с Laravel и React мы столкнулись с ситуацией: ошибка в production проявлялась только у 1% пользователей. Без Sentry её не могли воспроизвести несколько дней. После настройки нашли причину за 10 минут — проблема с состоянием гонки в Redux. Такая диагностика недоступна при простом логировании.

Почему Sentry лучше простого логирования?

Sentry не просто сохраняет ошибки — группирует их по стеку, показывает частоту, контекст (переменные окружения, breadcrumbs) и историю изменений. В отличие от логов, вы сразу видите, какая ошибка критична, кто её вызывал и в каком релизе она появилась. Это сокращает время поиска причин на 70% — с часов до минут. Sentry работает в 10 раз быстрее традиционных систем мониторинга при выявлении регрессий.

Данные Sentry показывают, что настройка source maps ускоряет отладку на 70%. Типичная экономия от сокращения времени на отладку составляет $200–500 в месяц для среднего проекта.

Сравнение вариантов развёртывания

Как настроить Sentry за 4 шага?

1. Установка SDK: на backend (Laravel) и frontend (React).
2. Настройка source maps: для читаемых стеков в браузере.
3. Фильтрация шума: исключение ботов, ожидаемых ошибок и расширений.
4. Алерты и release tracking: уведомления в Telegram и привязка коммитов.

Установка SDK

Backend PHP/Laravel:

composer require sentry/sentry-laravel
php artisan sentry:publish --dsn=https://[email protected]/project-id

В .env добавьте SENTRY_LARAVEL_DSN и SENTRY_TRACES_SAMPLE_RATE=0.1. SDK регистрируется автоматически.

Frontend React/Next.js:

npm install @sentry/react

Инициализация:

import * as Sentry from '@sentry/react';
Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,
  environment: import.meta.env.MODE,
  release: import.meta.env.VITE_APP_VERSION,
  integrations: [Sentry.browserTracingIntegration(), Sentry.replayIntegration({ maskAllText: false, blockAllMedia: false })],
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.05,
  replaysOnErrorSampleRate: 1.0,
});

Как настроить source maps для отладки?

Без source maps стек вызовов — минифицированный код. Установите плагин @sentry/vite-plugin, затем настройте:

import { sentryVitePlugin } from '@sentry/vite-plugin';
export default defineConfig({
  build: { sourcemap: true },
  plugins: [react(), sentryVitePlugin({ org: 'your-org', project: 'your-project', authToken: process.env.SENTRY_AUTH_TOKEN, sourcemaps: { assets: './dist/**', ignore: ['node_modules'], filesToDeleteAfterUpload: ['./dist/**/*.map'] } })],
});

Source maps загружаются при сборке и удаляются из публичной директории — пользователи их не увидят. Подробнее о настройке source maps читайте в документации Sentry.

Фильтрация шума

По умолчанию Sentry ловит всё: ботов, 404, ошибки расширений. Настраиваем фильтры:

// config/sentry.php
'before_send' => function (\Sentry\Event $event, ?\Sentry\EventHint $hint): ?\Sentry\Event {
    $exception = $hint?->exception;
    if ($exception instanceof \Illuminate\Auth\AuthenticationException) return null;
    if ($exception instanceof \Symfony\Component\HttpKernel\Exception\NotFoundHttpException) return null;
    $userAgent = request()->header('User-Agent', '');
    if (str_contains(strtolower($userAgent), 'bot')) return null;
    return $event;
},

Frontend (JavaScript):

Sentry.init({
  denyUrls: [/extensions\//i, /^chrome:\/\//i, /^chrome-extension:\/\//i],
  ignoreErrors: ['ResizeObserver loop limit exceeded', 'Non-Error promise rejection captured'],
});

Фильтры снижают количество ложных ошибок на 80–90%, оставляя только реальные проблемы.

Release tracking

При деплое создавайте релиз через sentry-cli: sentry-cli releases new "$VERSION", set-commits, finalize и deploys new -e production. Это позволяет видеть, в каком релизе и коммите впервые появилась ошибка.

Типы алертов

Настройте alert rule: New issue — при первом вхождении, Error frequency — >100 раз за час, Regression — ошибка вернулась после resolved. Интеграции: Telegram (через webhook), Slack, PagerDuty. Закажите настройку — мы подключим любой канал за час.

Что входит в работу

• Установка SDK на backend и frontend.
• Source maps для браузерных приложений.
• Фильтрация шума (боты, ожидаемые ошибки, расширения).
• Release tracking в CI/CD.
• Alert-правила в Telegram/Slack.
• Документация и обучение команды.

Сроки и экономия

Базовая настройка SDK, source maps, фильтрация и алерты — 2–4 часа. Полный цикл с CI/CD — до 2 дней. Настройка окупается в среднем за 2–3 месяца, экономя до $300 в месяц на поддержке. Свяжитесь с нами для бесплатной оценки вашего проекта. Закажите настройку Sentry сегодня — и забудьте о потерянных ошибках.

Настройка веб-аналитики: GA4, GTM, Яндекс.Метрика и Amplitude

Мы часто видим: конверсия 1.2 %, трафик растёт, а конверсия стоит. Маркетолог смотрит в Google Analytics и говорит: «пользователи уходят с шага 2 оформления заказа». Разработчик открывает тот же шаг — ошибок нет, в Sentry тишина. Значит, дело не в JS-баге, а в UX или в кривых данных, которые показывает аналитика. Аналитика ломается незаметно: событие перестало трекаться после редеплоя — никто не заметил; GTM-тег стреляет дважды — данные задвоились; фильтр GA4 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.

После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 50 000 сессий в день, где дедупликация purchase вернула 20 % неверно приписанных конверсий.

Почему события GA4 дублируются и как это исправить?

Universal Analytics закрыт, его место заняла событийная модель GA4. В ней нет фиксированных хитов страниц и транзакций — только события с параметрами. Это гибче, но требует правильного дизайна событий.

Автоматические события GA4 собирает сам: page_view, scroll, click, session_start. Рекомендуемые события нужно реализовать самостоятельно: purchase, add_to_cart, begin_checkout, view_item. Google ожидает конкретную схему параметров — если передать product_id вместо item_id, данные попадут в GA4, но не в стандартные отчёты e-commerce. Кастомные события для специфики проекта: filter_applied, video_progress, form_step_completed. Кастомные параметры необходимо зарегистрировать в GA4 Admin → Custom definitions, иначе они не будут доступны в отчётах.

Частая ошибка — событие purchase с дублями. Причина: тег срабатывает на странице /thank-you, пользователь обновляет страницу — второй purchase уходит в GA4. Решение: на бэкенде генерируем уникальный transaction_id и передаём в событие. GA4 de-duplicates по нему (в теории — проверяйте через DebugView). Правильная атрибуция экономит до 20 % рекламного бюджета, который раньше уходил на неверно приписанные конверсии.

Как настроить data layer, чтобы не потерять данные?

GTM — инструмент для управления тегами без деплоя кода. Но «без кода» не значит «без архитектуры». Data Layer — основа всего. Передаём данные из приложения в GTM через dataLayer.push(). Структура: event + контекстные данные. Для e-commerce: перед открытием страницы продукта — push с данными товара. GTM-тег читает из dataLayer, не из DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Название товара',
      price: 1990.00,
      currency: 'RUB'
    }]
  }
});

Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-Side для чувствительных данных — отправка с сервера, не с браузера, обходит блокировщики рекламы, не теряет данные.

Как Яндекс.Метрика дополняет веб-аналитику?

Для российской аудитории Метрика обязательна — особенно Вебвизор. Запись сессии пользователя, который бросил корзину, часто даёт ответ быстрее, чем неделя анализа воронки. Цели в Метрике: событийные (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) или автоматические (клик по кнопке, посещение страницы). Связка с CRM через Метрика Плюс — передача офлайн-конверсий. Наш опыт: в 8 из 10 проектов после настройки Метрики находили скрытые баги в UX, которые не показывали другие системы.

Что даёт product analytics в Amplitude?

Amplitude — продуктовый инструмент, в отличие от маркетинговых GA4 и Метрики. Он заточен под анализ поведения пользователей внутри продукта: воронки, ретеншн, user paths. Amplitude подходит для SaaS-продуктов, мобильных приложений и любых сервисов с зарегистрированными пользователями, где важно понять, как проходят онбординг, на каком шаге уходят, какие фичи используют чаще. Ключевые концепции: identify (связать анонимного пользователя с userId после авторизации), group (аккаунт в B2B SaaS), когорты для удержания. Amplitude Chart — воронка шагов за последние 30 дней с разбивкой по источнику.

Мониторинг качества данных

Аналитика без мониторинга — чёрный ящик. Настраиваем:

• GA4 Realtime — проверяем после каждого деплоя, что ключевые события приходят
• Alerting в GA4 — аномалия в количестве событий purchase (резкое падение = что-то сломалось)
• GTM Preview в staging-окружении перед продакшеном
• Ручные тесты воронок раз в неделю — просто пройти путь покупателя и проверить, что всё трекается

Что проверяем после каждого деплоя

• Все ли рекомендуемые события присутствуют в DebugView
• Нет ли задвоений (считаем количество purchase на 100 сессий)
• Не изменилась ли структура dataLayer после обновления фронтенда

Что входит в работу

Процесс и сроки

1. Аудит текущих тегов и данных (2 дня)
2. Дизайн событийной схемы (2 дня)
3. Разработка Data Layer и настройка тегов (3–5 дней)
4. QA в Preview Mode и на staging (2 дня)
5. Деплой и настройка дашбордов (1 день)

Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.

Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.