Sentry self-hosted на VPS или dedicated: когда это хорошая идея, а когда сервер быстро умирает

Sentry нужен, когда приложение уже нельзя чинить “по жалобам пользователей”. Ошибки в backend, frontend, mobile app, API, платежах, cron-задачах и интеграциях должны попадать в одно место: с stack trace, release, пользователем, окружением, частотой и историей. Для этого Sentry подходит хорошо. Но self-hosted Sentry — это не маленькая панель мониторинга, которую можно поставить на самый дешёвый VPS.

Главная ошибка — думать, что Sentry это “ещё один Docker-контейнер”. На практике self-hosted Sentry поднимает целый стек: web, workers, cron, Relay, Snuba, ClickHouse, Kafka, Redis, PostgreSQL, PgBouncer, symbolicator, storage и другие сервисы. Поэтому типовая боль после установки такая: всё запустилось, первые ошибки приходят, а через день CPU 100%, RAM почти закончилась, ClickHouse грузит диск, Sentry показывает Service Unavailable, события приходят с задержкой или вообще пропадают из интерфейса.

Эта статья объясняет, когда Sentry можно ставить на VPS, когда лучше сразу брать dedicated server, какие ресурсы важны и какие ошибки чаще всего ломают self-hosted Sentry в production.

Когда self-hosted Sentry вообще имеет смысл

Self-hosted Sentry имеет смысл, если вы хотите хранить ошибки приложений на своей инфраструктуре, контролировать retention, не отправлять stack traces и часть технических данных во внешний SaaS, подключить несколько проектов, отслеживать ошибки backend/frontend/mobile и иметь единый центр диагностики.

Нормальные сценарии:

у компании несколько production-приложений;
нужен централизованный error tracking для backend и frontend;
есть требования к хранению данных внутри своей инфраструктуры;
команда хочет видеть ошибки по release, environment и пользователям;
нужно отслеживать не только факт ошибки, но и повторяемость;
есть DevOps/администратор, который будет обслуживать Sentry;
есть готовность выделить ресурсы под ClickHouse, Kafka, PostgreSQL и Redis.

Плохой сценарий — ставить Sentry self-hosted “потому что бесплатнее SaaS”. Бесплатным он будет только на бумаге. Сервер, диск, backup, обновления, мониторинг, retention, диагностика ClickHouse/Kafka и время администратора тоже стоят денег.

Для тестовой установки или небольшого внутреннего проекта можно начать с VPS Hostyrex: https://hostyrex.net/ru/vps.html. Для production Sentry с реальным потоком событий чаще разумнее смотреть dedicated server: https://hostyrex.net/ru/servers.html.

Что люди реально ищут, когда Sentry self-hosted начинает ломаться

Обычно человек ищет не “купить сервер под Sentry”, а конкретную проблему:

Sentry self-hosted на VPS
Sentry на VPS требования
Sentry self-hosted RAM usage
Sentry ClickHouse high CPU
Sentry Kafka memory usage
Sentry Service Unavailable self-hosted
Sentry events not showing
Sentry self-hosted disk full
Sentry retention не очищает диск
Sentry docker compose backup
Sentry upgrade failed migrations
Когда нужен dedicated для Sentry

То есть клиент уже столкнулся с болью: ошибки приложений надо собирать, но сам инструмент мониторинга стал отдельным production-сервисом, который тоже требует ресурсов и обслуживания.

Главная правда: Sentry self-hosted тяжёлый

Self-hosted Sentry тяжёлый не потому, что “плохо написан”. Он тяжёлый потому, что делает много работы: принимает события, обрабатывает их, группирует ошибки, пишет данные, индексирует, хранит историю, показывает поиск, работает с релизами, sourcemaps, stack traces и фоновыми задачами.

Внутри есть несколько ресурсоёмких компонентов:

ClickHouse — активно использует CPU, RAM и диск, особенно при поиске, агрегациях и большом потоке событий.
Kafka — брокер сообщений, который требует памяти, диска и стабильного I/O.
Snuba — слой аналитики и запросов к ClickHouse.
PostgreSQL — хранит часть основной мета-информации.
Redis — используется для кэша и внутренних очередей.
Workers — обрабатывают события, задачи, уведомления, релизы и фоновые операции.
Relay — принимает события от SDK и передаёт их дальше.

Поэтому установка на VPS 2–4 GB RAM — почти всегда ошибка. Оно может даже запуститься, но это не значит, что будет жить под реальным потоком событий. Для Sentry опасна не только средняя нагрузка, но и всплески: сломанный release может начать отправлять тысячи ошибок за несколько минут.

VPS или dedicated: как выбрать

Sentry можно поставить на VPS, если это тест, staging, маленькая команда, небольшой поток событий и есть понимание retention. Но VPS должен быть не минимальный. Для self-hosted Sentry нужно считать не только RAM, но и CPU, NVMe, disk I/O, swap, retention и скорость роста событий.

Практический ориентир:

VPS до 8 GB RAM — не стоит использовать для production Sentry. Максимум тест или очень маленькая внутренняя установка без серьёзного потока событий.
VPS 16 GB RAM + swap — минимальный разумный старт для небольшой self-hosted установки, если события идут умеренно и диск быстрый.
VPS 32 GB RAM — более нормальный вариант для небольшой команды и нескольких проектов, но всё равно нужно следить за I/O, retention и ingestion rate.
Dedicated server — лучше для production Sentry, где есть несколько приложений, реальные пользователи, много событий, sourcemaps, performance data, replay/profiling или дорогой простой.

Если Sentry нужен для бизнеса, а не для эксперимента, dedicated часто честнее. У Sentry много stateful-компонентов, а ClickHouse и Kafka не любят плохой диск, перегруженный host node и непредсказуемый I/O. На dedicated server проще контролировать CPU, RAM, NVMe и нагрузку без соседей.

Если нужен VPS под тестовую установку Sentry, смотрите Hostyrex VPS: https://hostyrex.net/ru/vps.html. Если планируется production error monitoring для нескольких приложений, лучше начинать с dedicated servers: https://hostyrex.net/ru/servers.html.

Почему Sentry на маленьком VPS сначала работает, а потом умирает

Самый коварный сценарий: установка прошла успешно, интерфейс открылся, первый проект создан, события приходят. Владелец думает, что всё готово. Через сутки или неделю начинается: CPU 100%, RAM закончилась, swap постоянно используется, ClickHouse грузит диск, Docker-контейнеры рестартятся, UI тормозит, события появляются с задержкой.

Причины обычно такие:

слишком маленький VPS;
медленный диск или высокий iowait;
слишком длинный retention;
нет лимитов на количество событий;
приложение отправляет мусорные ошибки в цикле;
включили performance monitoring, replay или profiling без расчёта ресурсов;
не настроили cleanup;
Docker logs разрослись;
ClickHouse занял диск;
backup делается на тот же диск и добивает место;
обновления Sentry не проверяются на тестовой установке.

Проблема не в том, что “Sentry плохой”. Проблема в том, что Sentry сам является production-сервисом. Его нужно обслуживать так же, как базу данных, очередь сообщений или аналитическую систему.

Disk I/O важнее, чем кажется

Для Sentry быстрый диск критичен. ClickHouse, Kafka, PostgreSQL, Redis, Docker volumes и логи постоянно работают с диском. Если диск медленный, интерфейс может тормозить даже при свободной RAM. Если iowait высокий, CPU вроде бы есть, но процессы ждут диск.

Что важно:

использовать NVMe, а не медленный HDD;
следить за iowait;
не хранить backup на том же диске как единственную копию;
контролировать Docker volumes;
настроить log rotation;
следить за ростом ClickHouse;
заранее считать retention.

Если Sentry нужен для production и поток событий уже есть, выделенный сервер с NVMe часто будет стабильнее, чем дешёвый VPS с неизвестным I/O-профилем.

Retention: почему диск всё равно заполняется

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

Важно понимать: Sentry хранит не только “текст ошибки”. Событие может содержать stack trace, breadcrumbs, контекст, теги, release, environment, user data, request data, sourcemaps, attachments, performance traces и другую информацию. Если приложение начало массово отправлять одну и ту же ошибку, объём данных растёт быстро.

Перед запуском нужно решить:

сколько дней хранить события;
нужны ли performance traces;
нужны ли session replay и profiling;
сколько проектов будет подключено;
есть ли лимит событий на проект;
что делать при error storm после плохого release;
как очищаются старые данные;
как мониторится свободное место.

Плохая стратегия — “оставим всё навсегда, потом разберёмся”. Для Sentry это почти гарантированный путь к заполненному диску.

Error storm: главный враг self-hosted Sentry

Error storm — ситуация, когда приложение начинает массово отправлять одинаковые ошибки. Например, после неудачного release frontend начинает сыпать JavaScript exceptions, backend ловит ошибку в cron-задаче каждую секунду, mobile app отправляет crash loop, а API валится на каждом запросе.

В SaaS-версии часть рисков закрывается тарифами, лимитами и защитой платформы. В self-hosted всё ложится на вашу инфраструктуру. Если лимиты не продуманы, один плохой release может загрузить Sentry сильнее, чем обычный трафик за неделю.

Что нужно предусмотреть:

лимиты на ingestion;
sampling для performance data;
фильтрацию мусорных ошибок;
отключение шумных проектов при аварии;
alerts по резкому росту событий;
monitoring очередей и задержек обработки;
быстрый rollback приложения, которое генерирует шторм ошибок.

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

Docker Compose: удобно, но не значит “не надо администрировать”

Self-hosted Sentry обычно разворачивают через Docker Compose. Это удобно: один репозиторий, готовые сервисы, install script, volumes и стандартная схема запуска. Но Docker Compose не отменяет администрирование.

Нужно понимать:

где лежат Docker volumes;
как делать backup volumes;
как обновлять Sentry;
что будет при нехватке диска;
как смотреть логи конкретного контейнера;
как проверить Kafka, ClickHouse, Snuba и workers;
как восстановить установку на другом сервере;
что делать, если upgrade не прошёл.

Плохой подход — “docker compose up -d и забыть”. Sentry нельзя забывать. Его нужно мониторить, обновлять, чистить, бэкапить и проверять после каждого upgrade.

Какие симптомы говорят, что VPS уже не справляется

Переходить с VPS на dedicated стоит не тогда, когда всё уже лежит, а раньше. Есть признаки, что текущий VPS стал слабым:

Sentry UI регулярно показывает Service Unavailable;
events приходят с задержкой;
ClickHouse постоянно грузит CPU;
iowait высокий;
RAM почти всегда заполнена;
swap используется постоянно;
Docker containers рестартятся;
очереди растут быстрее, чем обрабатываются;
поиск и issue details открываются медленно;
после обновлений Sentry долго не возвращается в норму;
диск заполняется быстрее, чем ожидалось;
cleanup не спасает ситуацию;
один error storm кладёт весь мониторинг.

Если Sentry стал критичным инструментом для разработки и поддержки, он не должен жить на сервере “по остаточному принципу”. Для production-команды error monitoring — это часть инфраструктуры, а не игрушка.

Когда нужен dedicated server для Sentry

Dedicated server нужен, если Sentry используется не как тест, а как основной инструмент отслеживания ошибок.

Выделенный сервер стоит рассматривать, если:

подключено несколько production-приложений;
есть backend, frontend и mobile errors одновременно;
используются sourcemaps, performance monitoring, replay или profiling;
событий много или они приходят всплесками;
важна скорость поиска по ошибкам;
команда регулярно работает в Sentry UI;
retention больше нескольких дней;
простои Sentry мешают support и разработке;
нужен предсказуемый NVMe I/O;
нужно хранить данные внутри своей инфраструктуры;
планируется подключать много проектов или команд.

Dedicated server не делает Sentry автоматически беспроблемным. Но он даёт контролируемые CPU, RAM, диск и I/O. Для ClickHouse и Kafka это часто важнее, чем просто “ещё 2 GB RAM”.

Что проверить перед заказом сервера под Sentry

Перед оплатой VPS или dedicated нужно ответить на конкретные вопросы:

Сколько приложений будет подключено?
Сколько событий в день ожидается?
Есть ли frontend sourcemaps?
Будут ли performance traces?
Будет ли session replay?
Будет ли profiling?
Какой retention нужен: 7, 14, 30, 90 дней?
Нужен ли SMTP для уведомлений?
Где будут храниться backup?
Кто будет обновлять Sentry?
Есть ли staging для проверки обновлений?
Какой объём NVMe нужен с запасом?
Нужен ли отдельный диск под данные?
Нужен ли monitoring самого Sentry?
Что делать при error storm?
Кто отвечает за firewall, SSL и безопасность?

Если вы не знаете ответы, не стоит брать минимальный VPS и надеяться. Лучше описать задачу до заказа: количество проектов, примерный поток событий, retention, нужные функции Sentry и требования к хранению данных. Связаться с Hostyrex можно здесь: https://hostyrex.net/ru/contacts.html.

Firewall и безопасность Sentry

Sentry содержит чувствительные данные: stack traces, request URLs, headers, user identifiers, environment variables, release data, иногда fragment payload, технические детали backend и frontend. Поэтому его нельзя ставить как открытую публичную админку без защиты.

Минимально наружу обычно нужны:

80/tcp для HTTP и выпуска SSL;
443/tcp для HTTPS;
22/tcp для SSH, лучше только по ключам и с ограничением по IP;

Внутренние порты ClickHouse, Kafka, Redis, PostgreSQL, Docker services и админские интерфейсы не должны быть доступны из интернета. Если нужен доступ команды, лучше использовать VPN, IP allowlist, reverse proxy с авторизацией или отдельные правила firewall.

Также нужно аккуратно настроить проекты в Sentry: не отправлять лишние персональные данные, токены, пароли, cookies, Authorization headers и приватные payload. Sentry помогает находить ошибки, но если SDK настроен плохо, вы сами начнёте собирать чувствительные данные в своём мониторинге.

Если проект связан с пользовательскими данными, high-risk сервисами, большим трафиком или нестандартной нагрузкой, заранее проверьте условия использования и abuse policy: https://hostyrex.net/ru/terms.html.

Backup: что нужно сохранять у self-hosted Sentry

Backup Sentry сложнее, чем backup обычного сайта. Недостаточно сохранить один каталог с кодом. Важны данные в Docker volumes и состояние нескольких сервисов.

Нужно думать о backup для:

PostgreSQL;
ClickHouse;
Kafka data, если потеря очереди критична;
Redis, если в нём есть важное состояние;
uploaded files, attachments, sourcemaps, debug symbols;
конфигурации Sentry;
.env и секретов;
reverse proxy и SSL-конфигурации;
Docker Compose setup и версии self-hosted репозитория.

Плохой backup — это архив на том же сервере, который лежит рядом с production volumes. Если диск умер, сервер удалён, VPS скомпрометирован или место закончилось, такой backup может не спасти.

Минимально нужно:

хранить backup вне основного сервера;
иметь retention backup-копий;
делать backup перед upgrade;
проверять восстановление на отдельном сервере;
понимать, какие данные можно потерять, а какие нельзя;
не делать upgrade без свежего backup.

Обновления Sentry: почему нельзя годами не трогать установку

Self-hosted Sentry нужно обновлять. Но обновление Sentry — это не “обновить один пакет”. Там могут быть миграции, изменения схемы, новые контейнеры, изменения в ClickHouse/Snuba/Kafka, новые переменные и изменения в конфигурации.

Рискованные ошибки:

обновляться сразу на production без backup;
перепрыгивать через много версий без проверки release notes;
не читать breaking changes;
не проверять свободное место перед upgrade;
делать upgrade на слабом VPS, где миграции не могут нормально завершиться;
обновлять Docker/Docker Compose и Sentry одновременно;
не иметь rollback-плана.

Правильнее иметь тестовую установку или хотя бы snapshot/backup перед обновлением. Для production-команды Sentry должен обновляться контролируемо, а не в панике, когда старая версия уже начала ломаться.

Monitoring самого Sentry

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

Минимум, который нужно отслеживать:

доступность Sentry UI по HTTPS;
доступность ingest endpoint;
HTTP 500/502/503/504;
RAM и swap;
CPU load;
iowait;
свободное место на диске;
размер Docker volumes;
статус контейнеров;
ClickHouse health;
Kafka health;
PostgreSQL health;
Redis health;
очереди и задержки обработки событий;
успешность backup;
срок SSL-сертификата.

Если мониторинг проверяет только “открывается ли веб-интерфейс”, этого мало. Sentry может открываться, но уже не принимать события, не обрабатывать очереди или показывать старые данные с задержкой.

Когда self-hosted Sentry не подходит

Self-hosted Sentry не подходит, если вы хотите “поставить и забыть”. Также он плохо подходит, если нет человека, который понимает Docker, Linux, backup, disk I/O, обновления и troubleshooting.

Лучше не ставить self-hosted Sentry, если:

у вас один маленький проект и нет требований к self-hosting;
нет администратора или DevOps;
нет бюджета на нормальный VPS/dedicated;
нет backup-плана;
вы не готовы обновлять Sentry;
вы не хотите следить за disk usage;
вы не готовы ограничивать retention и ingestion;
вы ожидаете, что Sentry будет работать как лёгкий PHP-скрипт;
вы не готовы разбираться с ClickHouse, Kafka и Docker volumes.

В таких случаях проще использовать SaaS-версию Sentry или более лёгкую альтернативу. Self-hosted Sentry стоит выбирать, когда контроль инфраструктуры действительно важен и вы готовы обслуживать эту инфраструктуру.

Короткий checklist перед запуском Sentry self-hosted

Сервер имеет минимум 4 CPU и 16 GB RAM + swap для небольшого старта.
Для production рассматривается 32 GB RAM или dedicated server.
Диск — быстрый NVMe, а не медленный HDD.
Есть запас по месту под ClickHouse, Kafka, Docker volumes и backup.
Настроен retention событий.
Продуманы лимиты на ingestion и error storm.
Решено, нужны ли performance, replay и profiling.
Внутренние сервисы не открыты в интернет.
Sentry закрыт HTTPS и нормальным доступом.
SDK не отправляет токены, cookies, пароли и лишние персональные данные.
Backup хранится вне основного сервера.
Backup проверяется восстановлением.
Перед upgrade делается свежий backup.
Docker logs и system logs имеют rotation.
Мониторятся RAM, swap, CPU, iowait, disk, containers, ClickHouse, Kafka, PostgreSQL и Redis.
Есть план перехода с VPS на dedicated, если поток событий вырастет.

Как Hostyrex может помочь с Sentry self-hosted

Hostyrex предоставляет VPS и dedicated servers для self-hosted Sentry, error monitoring, DevOps-инфраструктуры, логов, backend-сервисов и внутренних инструментов разработки. Для тестовой установки или небольшой команды можно начать с VPS: https://hostyrex.net/ru/vps.html. Для production Sentry с реальным потоком событий, ClickHouse, Kafka, Snuba и долгим retention чаще разумнее dedicated server: https://hostyrex.net/ru/servers.html.

Если вы не уверены, что выбрать, не заказывайте сервер вслепую. Опишите количество проектов, ожидаемый поток событий, retention, необходимость performance/replay/profiling, требования к backup и кто будет администрировать Sentry. Связаться с Hostyrex можно здесь: https://hostyrex.net/ru/contacts.html. Если нужно администрирование, перенос или сопровождение, смотрите managed services: https://client.hostyrex.net/store/managed-services.

FAQ

Можно ли поставить Sentry self-hosted на VPS?

Да, но не на маленький VPS. Self-hosted Sentry требует CPU, RAM, swap и быстрый диск. Для теста можно использовать VPS, но для production с реальными событиями лучше сразу рассматривать мощный VPS или dedicated server.

Сколько RAM нужно для Sentry self-hosted?

Минимально стоит ориентироваться на 16 GB RAM + swap. Для production и нескольких проектов практичнее 32 GB RAM и выше. Если включены performance, replay, profiling или идёт большой поток событий, лучше смотреть dedicated server.

Почему Sentry self-hosted ест много RAM?

Потому что это не одно приложение. Внутри работают ClickHouse, Kafka, Snuba, PostgreSQL, Redis, workers, Relay и другие сервисы. Каждый компонент использует память, а ClickHouse и Kafka особенно чувствительны к ресурсам.

Почему Sentry показывает Service Unavailable?

Частые причины: нехватка RAM, высокий iowait, проблемы ClickHouse, Kafka или Snuba, переполненный диск, рестарт Docker-контейнеров, большой поток событий или неудачный upgrade. Проверять нужно не только web-контейнер, но весь стек.

Почему события не появляются в Sentry UI?

События могут приниматься Relay, но застревать в очередях или не обрабатываться Snuba/ClickHouse. Также проблема может быть в DSN, project key, rate limits, internal errors, Kafka, workers или заполненном диске.

Можно ли поставить Sentry на VPS 4 GB RAM?

Для production — нет. Для эксперимента, возможно, что-то запустится, но это плохая база для реального мониторинга ошибок. Sentry может работать первые часы, а потом упереться в RAM, swap, ClickHouse или диск.

Когда нужен dedicated server для Sentry?

Dedicated нужен, если Sentry используется командой как основной инструмент error monitoring, подключено несколько production-проектов, много событий, нужен долгий retention, быстрый поиск, performance data или стабильная работа без зависимости от соседей на VPS node.

Что важнее для Sentry: CPU, RAM или диск?

Важны все три, но диск часто недооценивают. ClickHouse, Kafka, PostgreSQL и Docker volumes активно используют I/O. Медленный диск или высокий iowait могут сделать Sentry медленным даже при нормальной RAM.

Нужно ли делать backup Sentry?

Да. Нужно сохранять PostgreSQL, ClickHouse, важные volumes, конфигурацию, secrets, sourcemaps, attachments и reverse proxy/SSL-конфиги. Backup должен храниться вне основного сервера и проверяться восстановлением.

Можно ли хранить backup Sentry на том же VPS?

Можно как временную локальную копию, но это не полноценный backup. Если сервер удалён, диск сломан или место закончилось, локальный backup может пропасть вместе с production-данными.

Какой retention выбрать для Sentry?

Зависит от команды и объёма событий. Для маленькой установки лучше начинать с короткого retention и смотреть рост диска. Долгий retention без расчёта объёма быстро приводит к заполнению хранилища.

Нужно ли открывать Sentry наружу?

Web-интерфейс и ingest endpoint могут быть доступны по HTTPS, если это нужно приложениям и команде. Но внутренние сервисы — ClickHouse, Kafka, Redis, PostgreSQL и Docker-порты — не должны быть открыты в интернет.

Почему Sentry сам нуждается в мониторинге?

Потому что Sentry может перестать принимать или обрабатывать события, даже если интерфейс частично открывается. Нужно мониторить контейнеры, очереди, ClickHouse, Kafka, PostgreSQL, Redis, RAM, swap, диск, iowait, HTTP ошибки и backup.

Что спросить у провайдера перед заказом сервера под Sentry?

Уточните CPU, RAM, NVMe, I/O-профиль, объём диска, возможность upgrade, backup, firewall, локацию, условия по трафику, managed support и что лучше выбрать под ваш поток событий: VPS или dedicated server.

Категории