Как настроить Sentry для сайта и ловить ошибки в 2026 году

Я обычно подключаю Sentry, когда сайт уже начал «сыпать» ошибками, а бизнес узнаёт о проблеме последним. И честно говоря, это плохая схема: в 2026 году нормальная команда должна видеть ошибки раньше клиента, раньше менеджера и раньше того момента, когда падают заявки или оплаты.

Sentry я ставлю и на WordPress, и на Bitrix, и на Laravel. На деле это один из самых полезных инструментов для техподдержки: он показывает не просто факт ошибки, а контекст — какой URL, какой пользовательский сценарий, какая версия кода, какой браузер, какое окружение, какой stack trace. Если у вас есть доработка сайта или регулярная поддержка WordPress, Sentry — это не «приятный бонус», а нормальная часть процесса. А если уже есть всплески 500-х, я сначала советую сделать проверка сайта, а потом встраивать мониторинг ошибок.

Зачем нужен Sentry в 2026 году

Если коротко, Sentry ловит ошибки приложения и собирает их в удобные события. Но на практике его ценность гораздо шире. Он помогает понять, где именно ломается сайт: в PHP-коде, в JavaScript на фронтенде, в API-обмене, в очередях, в cron-задачах или на этапе интеграции с CRM. У меня был клиент на Laravel 11 и PHP 8.3, у которого «иногда не отправлялись формы». В логах сервера — тишина. В Sentry сразу всплыло исключение в обработчике webhook: проблема была в редком пустом поле, которое вручную почти никто не воспроизводил.

Вот за что я люблю Sentry:

• видно не только ошибку, но и путь к ней;
• можно группировать события и не утонуть в шуме;
• легко отлавливать регрессии после обновлений;
• можно связать ошибки с релизами и staging;
• есть алерты в Slack, Telegram через промежуточные интеграции, email, Jira, GitHub Issues.

И ещё момент. Sentry не заменяет серверные логи, uptime-мониторинг и нормальный error log. Он их дополняет. Я обычно ставлю его вместе с логированием и алертами, потому что одна система редко закрывает всё. Кстати, если хотите выстроить более широкую схему наблюдаемости, загляните в Как настроить мониторинг сайта: полное руководство и Настройка логов сайта: мониторинг и анализ ошибок в 2026.

Какой сетап нужен до настройки

Перед тем как подключать Sentry, я всегда проверяю базовую гигиену проекта. Если на сайте уже бардак с версиями PHP, нет staging-среды, не настроены редиректы, а прод и тест живут под одним доменом — Sentry не спасёт. Он поможет увидеть симптомы, но не вылечит архитектуру.

Минимальный набор, с которым я спокойно стартую в 2026 году:

• PHP 8.1, 8.2 или 8.3 — в зависимости от CMS и библиотек;
• MySQL 5.7 или 8.0, желательно с нормальными slow query log;
• отдельное staging-окружение;
• настройка error log на уровне nginx/PHP-FPM;
• понятные окружения: production, staging, local;
• права доступа к Sentry только у тех, кому это нужно.

Если у вас WordPress, я бы отдельно посмотрел на плагины, которые уже могут генерировать ошибки: кеш, минификация, оптимизаторы изображений, security-плагины, интеграции с WooCommerce. Если Bitrix — особенно аккуратно с обработчиками событий, кастомными компонентами и агентами. Если Laravel — сразу проверьте queues, jobs, events и сервис-провайдеры. Для понимания, где у проекта реальные точки боли, полезно свериться с Технический долг сайта: что это и как бороться.

Как создать проект в Sentry и получить ключи

Я обычно начинаю с создания отдельного проекта в Sentry под каждое приложение. Не надо смешивать один и тот же проект для продакшена, staging и локалки, если у вас разные команды или несколько сайтов. Да, можно потом фильтровать по environment, но лучше сразу думать аккуратно.

После регистрации в Sentry вам понадобятся:

• DSN — основной ключ для отправки событий;
• environment — production, staging, development;
• release — версия релиза или git commit;
• при необходимости — auth token для CLI, sourcemaps и API.

На моей практике самый частый косяк — DSN кладут «куда-то в код» и забывают, что он должен отличаться между окружениями. Это особенно критично, если у вас CI/CD и автоматические деплои. Я обычно храню конфиг в переменных окружения. Если нужен более безопасный и системный подход к секретам, посмотрите ещё статью Защита API-ключей на сайте: настройка и хранение 2026.

SENTRY_DSN=https://publicKey@o123456.ingest.sentry.io/987654
SENTRY_ENVIRONMENT=production
SENTRY_RELEASE=webfull-2026.04.18

Если у вас Docker, то ENV можно прокинуть через docker-compose. Если shared-hosting — тогда проще через конфиг CMS или через .env-файл, если движок это поддерживает. Но держать DSN в публичном репозитории я бы не советовал. Это не «секрет уровня root-доступа», но порядок всё равно должен быть.

Настройка Sentry для PHP, Laravel, WordPress и Bitrix

Самый удобный вариант для PHP-проектов — официальный SDK Sentry для PHP. Для Laravel он ставится очень быстро, для WordPress и Bitrix чаще приходится делать обвязку руками, но ничего страшного там нет. Я обычно смотрю на задачу так: если проект современный, ставим SDK и настраиваем middleware/exception handler. Если проект старый, можно хотя бы подключить глобальный обработчик ошибок и исключений.

Для Laravel пример обычно выглядит просто. В 2026 году я чаще работаю с Laravel 10–12 и PHP 8.2/8.3, и там интеграция уже почти без боли:

composer require sentry/sentry-laravel

php artisan sentry:publish --dsn=https://publicKey@o123456.ingest.sentry.io/987654
php artisan config:clear
php artisan config:cache

Потом проверяю, что environment и release заполнены, а исключения не улетают с лишним шумом. Для Laravel полезно логировать не только exception, но и user context, route name, queue job и request id. Тогда при падении конкретной задачи в очереди вы сразу понимаете, где копать.

Для WordPress я часто делаю интеграцию в маленький must-use plugin или в кастомный плагин темы. Смысл в том, чтобы не зависеть от обновлений темы и не потерять код после деплоя. Очень грубо говоря, лучше отдельный файл-подключение, чем правки в functions.php. Для Bitrix можно подключать Sentry на уровне init.php или через автозагрузку, но я предпочитаю не лезть в ядро и держать интеграцию в отдельном модуле или include-файле.

<?php
require __DIR__ . '/vendor/autoload.php';

Sentry\init([
    'dsn' => getenv('SENTRY_DSN'),
    'environment' => getenv('SENTRY_ENVIRONMENT') ?: 'production',
    'release' => getenv('SENTRY_RELEASE') ?: 'unknown',
    'traces_sample_rate' => 0.1,
    'profiles_sample_rate' => 0.0,
]);

set_exception_handler(function (Throwable $e) {
    Sentry\captureException($e);
    throw $e;
});

set_error_handler(function ($severity, $message, $file, $line) {
    throw new ErrorException($message, 0, $severity, $file, $line);
});

Этот пример не идеален для любого продакшена, но как базовая схема — рабочий. Я обычно добавляю фильтрацию, чтобы не отправлять в Sentry заведомо неинтересные notices и предупреждения от сторонних библиотек. И да, если проект уже старый, сначала лучше сделать доработки через доработку сайта, а потом уж подключать мониторинг. Иначе будете тонуть в старых ошибках, которые годами никто не чинил.

Как правильно настроить фильтры и отбор событий

Если не настроить фильтрацию, Sentry превращается в склад мусора. Это я вижу постоянно. Боты, шумные сторонние скрипты, CSS/JS 404, ошибки аналитики, случайные трейс-артефакты от расширений браузера — всё это может забить вам очередь событий и усыпить бдительность.

Я обычно фильтрую события по нескольким признакам:

• environment — не смешивать dev и prod;
• тип ошибки — исключения важнее notice/warning;
• URL — игнорировать служебные страницы;
• пользователь — исключать админские тестовые действия, если нужно;
• боты — при возможности отсекать мусорный трафик;
• известные ошибки сторонних сервисов — помечать, но не алертить каждую минуту.

У меня был случай на интернет-магазине на Bitrix, где Sentry начал присылать события из-за сломанного JS у внешнего чат-виджета. Ошибка была не наша, а от стороннего скрипта. Если бы мы не сделали фильтр по stack trace и домену, алерты стали бы бесполезными. В таких проектах я часто параллельно читаю про критические уведомления о сбоях сайта, чтобы отделять действительно важные вещи от шума.

Вот простой пример фильтрации на уровне SDK:

Sentry\init([
    'dsn' => getenv('SENTRY_DSN'),
    'before_send' => function (Sentry\Event $event): ?Sentry\Event {
        $message = $event->getMessage();

        if ($message && str_contains($message, 'ResizeObserver loop limit exceeded')) {
            return null;
        }

        $request = $event->getRequest();
        if ($request && isset($request['url']) && str_contains($request['url'], '/wp-admin/admin-ajax.php')) {
            return null;
        }

        return $event;
    },
]);

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

Sourcemaps, релизы и отладка фронтенд-ошибок

Если у вас есть хоть немного JavaScript на сайте, sourcemaps — это must have. Без них Sentry будет показывать минифицированные куски кода, и толку от этого мало. Особенно если вы используете сборку через Vite, Webpack или отдельный frontend bundle. На деле связка «релиз + sourcemaps» экономит часы, а иногда и дни.

Я обычно делаю так: на каждом деплое создаю новый release, загружаю sourcemaps и только потом перевожу трафик на прод. Тогда Sentry связывает ошибку с конкретной версией, а не с абстрактным «latest». Это удобно и для отката, и для анализа. Если вам интересна похожая дисциплина изменений, посмотрите Версионирование и откат обновлений сайта: настройка 2026.

Для фронтенда принцип такой: карты исходников не должны быть доступны всем подряд в открытом виде, но Sentry должен их уметь принимать. Я обычно закрываю лишнее nginx-правилами и отдаю sourcemaps только в контур релиза. Примерно так:

location ~* \.(map)$ {
    deny all;
    return 404;
}

location / {
    try_files $uri $uri/ /index.php?$args;
}

Если у вас SPA или SSR, отдельное внимание нужно событиям на клиенте. На одном проекте с Next.js и PHP API мы нашли ошибку только потому, что Sentry показал цепочку: на фронте запрос ушёл с неправильным CSRF-токеном, а дальше сервер ответил 419. Без sourcemaps и релиза это выглядело бы как «иногда не работает кнопка оплаты». А это, мягко говоря, слишком расплывчато.

Как связать Sentry с nginx, PHP-FPM и логами

Я всегда говорю клиентам одну простую вещь: Sentry — это не повод забить на серверные логи. Наоборот, он должен дополнять nginx access/error log, PHP-FPM log и application log. Когда всё связано, диагностика идёт быстро. Когда нет — начинаются гадания.

На сервере я обычно проверяю:

• nginx error log — чтобы видеть 502, 504 и upstream-проблемы;
• PHP-FPM slowlog — чтобы находить тяжёлые запросы;
• application logs — бизнес-ошибки и exception trace;
• Sentry — агрегированную картину и контекст пользователя.

Если у вас часто всплывают 502 или прокси-ошибки, отдельной статьёй я бы держал под рукой Как исправить 502 Bad Gateway и ошибки прокси на сайте. Потому что Sentry может показать падение приложения, но если Nginx не достучался до PHP-FPM, искать нужно уже на уровне инфраструктуры.

Практический пример nginx-конфига, который помогает не терять диагностику:

server {
    listen 443 ssl http2;
    server_name example.com;

    error_log /var/log/nginx/example.error.log warn;
    access_log /var/log/nginx/example.access.log main;

    root /var/www/example/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 120s;
    }
}

Если проект на Apache, можно подключать и через .htaccess, но я честно говоря предпочитаю серверный конфиг, а не магию на уровне каталога. .htaccess годится для части shared-hosting сценариев, но для серьёзной настройки логирования и безопасности лучше nginx или полноценный vhost.

Настройка открытых и критических уведомлений

Sentry ценен тогда, когда ошибки не просто накапливаются в панели, а превращаются в действия. Я обычно настраиваю алерты по серьёзным исключениям, росту новых ошибок и всплескам в определённом release. Если ошибка повторилась 1-2 раза — это не всегда пожар. Если она пошла серией после деплоя — это уже проблема.

Из практики: у одного клиента после обновления WordPress с 6.5 на 6.6 и смены версии PHP с 8.1 на 8.3 пошли ошибки в кастомной оплате. Без алертов проблему заметили бы только после жалобы покупателя. С Sentry мы увидели первые падения через 8 минут после релиза. Это очень хороший результат.

Я обычно делю события на три уровня:

1. critical — падения оплаты, авторизации, отправки форм, личного кабинета;
2. high — ошибки на ключевых страницах и в API;
3. medium — разовые проблемы, которые пока не бьют по конверсии.

Если на сайте уже есть поведенческий или uptime-мониторинг, Sentry становится вторым слоем. Uptime скажет: «сайт недоступен». Sentry скажет: «вот конкретная ошибка в коде, вот релиз, вот URL и стек». Это намного полезнее, чем просто красная лампочка. В этом смысле статья Настройка uptime-мониторинга сайта в 2026 году хорошо дополняет тему.

Распространённые ошибки при внедрении Sentry

Самая частая ошибка — подключить Sentry и ничего не настроить сверху. Второй косяк — не проверять, какие события реально улетают. Третий — забыть про staging. И четвёртый, любимый: ставят мониторинг ошибок, но не чинят причину. Это уже не техническая, а организационная проблема.

Вот что я вижу чаще всего:

• один проект Sentry на всё подряд;
• отсутствие release-меток;
• нет фильтрации ботов и мусора;
• нет связки с деплоем;
• включили frontend, но забыли о sourcemaps;
• поставили SDK и не проверили, отправляется ли тестовое событие.

У меня был случай на интернет-магазине с Bitrix и Redis-кешем: Sentry был подключён, но ошибки из фоновых агентов почти не приходили, потому что обработчик был поставлен только на web-запросы. А реальные сбои происходили в cron. Пришлось отдельно подключать обёртку для CLI-задач. Если у вас есть фоновые процессы, очереди или крон, это однозначно стоит проверить.

Кстати, если после настроек вы видите, что ошибок всё ещё слишком много, стоит пройтись по общей диагностике из статьи Как исправить ошибки на сайте: чек-лист. Там удобно отлавливать базовые системные проблемы до того, как они превращаются в шум в Sentry.

Как внедрить Sentry без большого риска

Я обычно рекомендую запускать внедрение в три этапа. Сначала подключаем на staging и смотрим, какие события приходят. Потом включаем на проде, но только для критических исключений. И уже потом расширяем покрытие на frontend, очереди, CLI, cron и интеграции. Это нормальный путь. Быстрые «всё включили сразу» обычно заканчиваются шумом и раздражением команды.

Если у вас сайт на старом движке, сначала проверьте совместимость. Иногда лучше сначала обновить PHP до 8.1 или 8.2, убрать устаревшие плагины, навести порядок в логах и только потом ставить мониторинг. Иначе Sentry покажет вам не проблему, а исторический архив технического долга. А это, по опыту, мало кому нравится.

С точки зрения стратегии, Sentry хорошо работает вместе с:

• резервными копиями;
• staging-средой;
• автообновлением только после проверки;
• CI/CD и откатом релизов;
• регулярной проверкой логов и скорости сайта.

Если нужна не просто настройка одного инструмента, а нормальная системная настройка силами специалиста, я бы не тянул с этим до первых серьёзных сбоев. На деле дешевле один раз аккуратно собрать схему мониторинга, чем потом в авральном режиме искать, почему отвалилась форма заявки, личный кабинет или выгрузка в CRM. Для финансовой оценки таких работ можно открыть калькулятор стоимости сайта и прикинуть объём задач.

И ещё один практический совет. После внедрения я всегда проверяю Sentry тестовой ошибкой. Например, временно бросаю исключение в dev/staging или запускаю пробный JS error в закрытом контуре. Если событие не пришло — значит, интеграция сломана уже на этапе подключения. Это лучше поймать сразу, чем через месяц после запуска.