Когда мы только начинали, любое сообщение от клиента превращалось в стресс. Звонок: «У нас не работает форма». И дальше вечные расспросы: какое устройство, какой браузер, что именно нажимали? Танцы с бубном вокруг поиска причины занимали часы и съедали нервы.

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

Попытки найти замену

После первых тестов был долгий период экспериментов с аналогами. Самый заметный из них — GlitchTip. В облаке он казался нормальным вариантом, но в self-hosted быстро вскрылись ограничения. Базовые и интуитивные графики, которые есть в Sentry, там просто отсутствовали. Мы страдали с ним месяцев шесть-восемь, но в итоге признали: полноценной заменой это не станет.

Почему не сразу self-hosted Sentry

Казалось бы, ответ на поверхности — подними свой сервер с Sentry и работай. Но тут встаёт проблема ресурсов. Система прожорливая, особенно если у вас десяток проектов, которые могут генерировать по 100 тысяч алертов в день. Сервер ложится, команда нервничает.

Поэтому вначале мы сомневались. Но потом приняли решение: «Гори оно огнём». Подняли свой сервер и развернули self-hosted Sentry. Первые месяцы ушли на оптимизацию: настройка лимитов, перераспределение ресурсов, чистка мусора. Постепенно система стала жить на адекватных мощностях.

Основные блоки Sentry

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

События (Events)
Каждая ошибка или перформанс-проблема фиксируется как событие. В нём хранится полный набор данных: стек вызовов, заголовки, браузер, IP, параметры пользователя.

Алерты (Alerts)
Система умеет настраивать алерты: уведомления в почту, Slack, Telegram или другие интеграции. Это позволяет реагировать на проблемы сразу, а не ждать звонка от клиента.

Issues
Похожие события объединяются в один «Issue» — это удобно, когда один баг воспроизводится сотни раз. Разработчики видят статистику и могут фокусироваться на корне проблемы, а не на разрозненных логах.

Performance Monitoring
Кроме ошибок, Sentry отслеживает скорость работы приложений: медленные запросы, долгие транзакции, узкие места.

Интеграции Sentry

Sentry поддерживает большинство популярных фреймворков и CMS:

• Backend: Laravel, Symfony, Django, Flask, Spring, .NET, Node.js, Ruby on Rails, Go.
• Frontend: Vue.js, React, Angular, Svelte, jQuery.
• CMS: Bitrix, WordPress, Drupal, Joomla.
• Мобильные приложения: iOS (Swift, Objective-C), Android (Kotlin, Java), React Native, Flutter.
• DevOps и инфраструктура: интеграции с Docker, Kubernetes, GitHub, GitLab, Jira, Slack, Telegram.
  
  

Чем удобен self-hosted формат

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

Как мы интегрируем сейчас

На проектах процесс отлажен:
— Laravel и Vue — берёшь мануал и подключаешь туда, где нужен мониторинг.
— Bitrix — ещё проще: ставишь модуль, закидываешь ключи, и все алерты автоматически уходят в Sentry.

В итоге по каждой ошибке у нас полный набор данных: браузер, хосты, заголовки, stack trace, куки. Можно спокойно разбираться, а не притворяться Шерлоком Холмсом.

Чем это обернулось

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

Вывод: self-hosted Sentry — не подарок. Он требует ресурсов, внимания и оптимизации. Но это инструмент, который реально работает. И если выбирать между хаосом и спокойной жизнью команды, выбор очевиден.