Sentry на VPS: установка, требования и что ломается

Ошибка в корзине интернет-магазина стоит дороже, чем кажется: покупатель не напишет в поддержку, он просто уйдёт. Sentry нужен, чтобы такие сбои всплывали в панели через минуту после первого случая, с файлом, строкой и версией сборки. Всё остальное — логи, journalctl, алерты по 500-м — показывает факт, но не место в коде.

Ниже — установка self-hosted Sentry на собственный сервер: что подготовить, где он съест память, как не потерять базу при обновлении. Сразу главное: полный Sentry просит 16 ГБ RAM и 4 ядра, это заметно больше обычного сайтового VPS. Если у вас 4–8 ГБ, дочитайте до раздела про лёгкие трекеры — там варианты, которые реально влезут.

Что Sentry умеет, если коротко

Приложение ловит исключение и отправляет его на сервер по адресу DSN. В панели появляется карточка: стек вызовов с точной строкой, версия релиза, браузер или устройство, у скольких пользователей повторилось. Тысяча одинаковых сбоев схлопывается в одну запись со счётчиком — читать список из одной строки проще, чем тысячу.

Термины, без которых инструкция не читается:

Событие — один конкретный сбой, отправленный SDK.
Issue — группа похожих событий. С ней работают: назначают ответственного, закрывают после фикса.
SDK — библиотека внутри приложения, перехватывает ошибки. Есть для Python, PHP, JS, Go, Java, Ruby, .NET.
DSN — адрес проекта, куда SDK шлёт события. Меняется одной строкой в конфиге.
Релиз — метка версии приложения. Позволяет увидеть, что сбой пошёл после конкретного деплоя.

Разница с логами принципиальная. Лог пишет всё подряд, и чтобы найти причину, надо уже знать, что искать. Sentry сам решает, что произошло нештатного, и прикладывает контекст.

Почему ставят свой экземпляр, а не облако

10 сентября 2024 года Sentry закрыл доступ к облаку для пользователей из России: платные аккаунты расторгнуты, оплата не принимается. У части команд до сих пор живут старые проекты, но это вопрос времени, а не стратегии.

Self-hosted версия снимает зависимость от чужого решения:

событий и пользователей столько, сколько выдержит ваш сервер, платы за каждую тысячу нет;
отчёты об ошибках содержат IP-адреса и идентификаторы устройств, то есть потенциально персональные данные — они остаются внутри вашего периметра (сама по себе установка на своём сервере соответствие 152-ФЗ не обеспечивает, но кто имеет доступ к данным, вы знаете точно);
SDK те же, что для облака, — переезд сводится к замене DSN.

Лицензия — Functional Source License. Разворачивать у себя имеет право компания любого размера, а вот перепродавать Sentry как сервис нельзя. Спустя два года после выхода версия переходит под Apache 2.0.

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

Из чего состоит Sentry и почему он такой прожорливый

Внутри — не один процесс, а полтора десятка контейнеров. Путь ошибки выглядит так:

SDK отправляет событие на DSN.
Relay принимает запрос, проверяет, к какому проекту он относится, и отсекает мусор.
Событие кладётся в Kafka — чтобы не потеряться при всплеске.
Обработчики группируют похожие события, Symbolicator разворачивает минифицированный стек в читаемый.
Данные расходятся: события в ClickHouse, пользователи и настройки в PostgreSQL, поиск по событиям через Snuba.
Веб-интерфейс показывает issue, воркеры рассылают уведомления.

Плюс Redis для кэша и очередей, плюс фоновые задачи. Всё это живёт на одной машине, поэтому память заканчивается раньше, чем процессор. Отсюда два профиля установки:

feature-complete — всё, включая мониторинг производительности, трейсы и дашборды. Включён по умолчанию.
errors-only — трейсы и дашборды отключены, остаются приём сбоев, группировка похожих, поиск и уведомления.

Официальный минимум: 4 ядра, 16 ГБ RAM, 16 ГБ swap, 20 ГБ свободного диска, Docker 19.03.6+ и Compose 2.32.2+. Разработчики советуют 32 ГБ, но допускают 16, если swap лежит на быстром диске. Процессор при этом обычно простаивает: узкое место — память и случайные обращения к диску.

Про диск отдельно. Если iowait в top держится выше 10%, Sentry не «немного тормозит», а разваливается по таймаутам: Kafka не успевает сбрасывать сегменты, воркеры копят очередь. SATA SSD на дешёвом VPS это чувствует быстро, NVMe — норма.

Какой сервер брать под это

Считайте от профиля, а не от цены.

errors-only, до сотни тысяч событий в месяц — 4 ядра, 8–12 ГБ RAM, 16 ГБ swap, NVMe от 80 ГБ.
feature-complete или несколько проектов — 4 ядра, 16 ГБ RAM, NVMe от 100 ГБ. Меньше 16 ГБ брать бессмысленно: контейнеры начнут падать по OOM, и вы будете чинить не приложение, а мониторинг.

У Tenku сейчас верхний тариф — 6 ядер, 12 ГБ RAM и 100 ГБ NVMe за 1 249 ₽ в месяц. Полный Sentry в него не влезет, errors-only — влезет с swap и оговорками. Если нужен полный набор с трейсами, честнее взять отдельный сервер с 16–32 ГБ: держать Sentry на одном VPS с боевым приложением — плохая идея хотя бы потому, что при OOM вы теряете и мониторинг, и сервис одновременно.

Ориентиры по тарифам Tenku (октябрь 2026): 1 ядро / 2 ГБ / 15 ГБ NVMe — 299 ₽, 2 ядра / 4 ГБ / 40 ГБ — 399 ₽, 4 ядра / 8 ГБ / 80 ГБ — 849 ₽. Для Sentry интересны последние два, как считать — в разборе выбора тарифа.

Ещё два условия, которые часто забывают:

ОС. Ubuntu 22.04/24.04 или Debian 12. С семейством RHEL бывают сюрпризы с зависимостями, Alpine не поддерживается вовсе.
Виртуализация. Нужен нормальный Docker. На некоторых хостингах с урезанным ядром Sentry ставится, но контейнеры периодически перезапускаются без причины — ищите такого соседа сразу по графикам.

Шаг 1. Подготовка сервера

Ubuntu 24.04, вход по SSH, пользователь с sudo. Дальше — обновление, swap и файрвол.

sudo apt update && sudo apt upgrade -y

sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Swap обязателен даже при 16 ГБ: Sentry умеет короткими всплесками съедать всю память, и без swap OOM-killer выберет самый жирный контейнер — обычно PostgreSQL или Kafka.

Файрвол: наружу только 22, 80 и 443. Порт 9000, на котором слушает веб Sentry, в мир не смотрит никогда.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

У регистратора заранее заведите A-запись поддомена — например, sentry.example.ru на IP сервера. Сертификат Let's Encrypt без неё не выпустится, а без сертификата не заработают вход и интеграции.

Шаг 2. Docker и зеркало реестра

Docker ставьте из официального репозитория, не из apt Ubuntu: там Compose бывает версии 1.x, и установщик Sentry остановится с Expected minimum version.

docker --version
docker compose version

Вторая команда должна показать 2.32.2 или новее. Если меньше — обновляйте, пока не поздно: install.sh проверяет версию на входе и падает.

С мая 2024 года Docker Hub не отдаёт образы российским IP. Признак — docker pull висит и заканчивается context deadline exceeded. Лечится зеркалом реестра в /etc/docker/daemon.json:

{
  "registry-mirrors": ["https://зеркало.example"]
}

После правки — sudo systemctl restart docker. Проверьте на любом образе: docker pull busybox.

Шаг 3. Установка Sentry

Ветку master не берите: там код в разработке. Нужен последний релизный тег.

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}

До запуска установщика проверьте две строки в .env — они определяют, что именно вы получите:

# только ошибки, без трейсов и дашбордов
COMPOSE_PROFILES=errors-only

# веб-интерфейс слушает только локальный адрес
SENTRY_BIND=127.0.0.1:9000

SENTRY_BIND не косметика. Docker публикует порты через свою цепочку iptables в обход ufw, поэтому при настройке по умолчанию порт 9000 окажется открыт наружу — с формой входа и без HTTPS. Строка выше закрывает его на localhost, а наружу выставляет только прокси.

Запуск:

./install.sh --no-report-self-hosted-issues

Скрипт скачает образы (первый раз это долго — несколько гигабайт), создаст базы, прогонит миграции и попросит логин с паролем администратора. Флаг --no-report-self-hosted-issues отключает отправку телеметрии об установке — на мой взгляд, лишнее по умолчанию в закрытом контуре.

Если установка падает на середине, не начинайте заново: сначала docker compose ps и dmesg -T | tail -50. В 9 случаях из 10 там OOM — не хватило памяти, и лечится это не переустановкой, а добавлением swap или RAM.

Шаг 4. Первый вход, домен и HTTPS

После установки поднимите сервисы и дождитесь, пока все контейнеры станут Up или healthy:

docker compose up --wait
docker compose ps

Пока домена нет, веб доступен только с сервера. Проброс порта на свою машину:

ssh -L 9000:127.0.0.1:9000 user@IP-сервера

и открыть http://127.0.0.1:9000. Мастер спросит адрес сервиса и предложит разрешить самостоятельную регистрацию — выключите её, коллег приглашайте вручную.

Дальше — прокси. Nginx или Caddy принимает 443 и передаёт на 127.0.0.1:9000, обязательно с исходным протоколом и реальным IP клиента. Готовый рецепт с сертификатом — в гайде по Nginx и Let's Encrypt, здесь только то, что специфично для Sentry.

В sentry/config.yml:

system.url-prefix: 'https://sentry.example.ru'

В sentry/sentry.conf.py — блок для работы за прокси:

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
USE_X_FORWARDED_HOST = True
CSRF_TRUSTED_ORIGINS = ['https://sentry.example.ru']

Без этого вход зацикливается на форме, а настройки интеграций падают с ошибкой CSRF — самая частая жалоба после первого запуска. После правки: docker compose restart.

Проверка здоровья — https://sentry.example.ru/_health/. Код 200 — всё живо; 500 с текстом — там прямо написано, какой компонент не отвечает.

Шаг 5. Почта

Без SMTP Sentry не отправит ни приглашение коллеге, ни письмо о новой ошибке. Встроенный сервер есть, но письма с нового IP крупные сервисы режут в спам: у домена нет репутации, PTR и SPF.

Подключайте внешний SMTP в config.yml:

mail.from: 'sentry@example.ru'
mail.host: 'smtp.example.ru'
mail.port: 587
mail.username: 'sentry@example.ru'
mail.password: 'пароль'
mail.use-tls: true

Порт 25 у большинства хостеров закрыт, и Gmail на нём отправку не принимает — 587 с TLS рабочий вариант. После настройки отправьте тестовое письмо из админки: не «должно работать», а именно письмо себе.

Шаг 6. Подключение приложения

Создайте проект, выберите платформу — Sentry покажет готовый сниппет с вашим DSN. Для JS это одна строка в инициализации, для Python — sentry_sdk.init(dsn=...) до создания приложения. Проверка: вызовите ошибку руками, она должна появиться в списке issues в течение минуты.

Дальше — то, что отличает рабочую настройку от формальной:

Передавайте релиз. release: "backend@1.4.2" или коммит-хеш. Без релиза вы не отличите новую ошибку от старой после деплоя.
Разделяйте окружения. environment: production / staging. Иначе тестовые сбои тонут в боевых.
Включите tunnel для фронтенда. Блокировщики рекламы режут запросы к sentry.io и к домену со словом sentry в имени: часть ошибок из браузера просто не дойдёт. Опция tunnel отправляет события через ваш домен — по тому же пути, что и API приложения.
Не отправляйте лишнего. Настройте beforeSend, чтобы вырезать пароли, токены и номера карт из запросов. Отчёт об ошибке — это ещё и лог тела запроса.

Обслуживание: обновления, бэкапы, место

Это та часть, из-за которой self-hosted Sentry чаще всего и бросают. Три правила, которые дешевле соблюдать, чем расхлёбывать.

Обновляйтесь по календарю. Релизы выходят раз в месяц, 15-го числа, номер — год и месяц: 26.7.0 это июль 2026-го. Перепрыгивать обязательные версии нельзя: в них миграции базы. На октябрь 2026 года hard stops — 24.8.0, 25.5.1, 26.5.0, 26.7.0; отдельно документация советует пропускать 25.9.0, 25.12.0 и диапазон 26.3.0–26.4.0. Список меняется, сверяйтесь с официальными docs перед каждым шагом.

Сам процесс незамысловатый:

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

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

Бэкапьте то, что не восстановить. Встроенный экспорт сохраняет пользователей, организации, проекты и настройки — событий в нём нет. Копирование Docker-томов официально не поддерживается, но работает. Рабочая схема: раз в сутки экспорт настроек, снимок сервера перед каждым обновлением, раз в квартал — пробное восстановление на отдельной машине. Бэкап, который ни разу не разворачивали, бэкапом не считается; общие принципы — в статье про бэкапы VPS.

Следите за диском. Срок хранения событий задаётся в .env:

SENTRY_EVENT_RETENTION_DAYS=30

По умолчанию 90 дней. Когда диск заполнится, Sentry не «замедлится» — он перестанет принимать события, молча. df -h раз в неделю и алерт на 80% закрывают вопрос. Если событий много, хранилище выносят в S3-совместимое.

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

Что ломается чаще всего

Собрал по симптомам, которые повторяются из установки в установку.

Контейнеры перезапускаются по кругу, установка не доходит до конца. Не хватило памяти, OOM-killer убивает процессы. Проверить: dmesg -T | tail -30. Лечить: swap 16 ГБ, затем RAM.
Интерфейс вязнет, события приходят с задержкой в минуты. Диск. iostat -x 1 покажет загрузку выше 80% и большой await. Только переезд на NVMe, настройками это не лечится.
install.sh падает на проверке версий. Старый Compose из репозитория Ubuntu. Ставить Docker из официального репо.
Образы не скачиваются. Docker Hub недоступен с российского IP. Зеркало реестра.
После подключения HTTPS — ошибка CSRF при входе. Не прописаны system.url-prefix и блок SSL в sentry.conf.py.
Не приходят приглашения. SMTP не настроен, порт 25 закрыт, письма режет спам-фильтр. Внешний SMTP на 587 и тестовое письмо.
Обновление упало на миграции. Пропущен hard stop. Откат из снимка и проход по обязательным версиям по порядку.
События перестали поступать совсем. Проверьте свободное место. Это первое, что смотрят, и почти всегда оно.
Часть ошибок с фронта не доходит. Блокировщик режет запросы к домену с «sentry». Опция tunnel через свой домен.

Если сервер слабее 16 ГБ: три альтернативы

Полный Sentry на 4–8 ГБ не поедет, и уговаривать его бесполезно. Но SDK-совместимых трекеров хватает:

GlitchTip — открытый, MIT. Рекомендуют 512 МБ RAM, минимально рабочий — 256 МБ. Умеет принимать события Sentry SDK.
Bugsink — один контейнер, по умолчанию SQLite. Разработчик тестировал на 2 vCPU и 4 ГБ. Самый простой вариант «поставил и забыл» для небольшого проекта.
Hawk — российский сервис, оплата по счёту для юрлиц. Вариант, когда свой сервер держать не хочется совсем.

Все три меняются сменой DSN в приложении. Если нужны трейсы, дашборды и интеграции уровня Sentry — придётся выделять машину с 16 ГБ и выше; серединного варианта тут нет.

Частые вопросы

Сколько RAM нужно Sentry на самом деле?

Официально 16 ГБ и столько же swap, для полного профиля советуют 32 ГБ. На 8 ГБ с профилем errors-only он запустится, но будет жить на грани: любой всплеск событий или параллельное обновление уронит контейнеры.

Можно ли поставить Sentry на тот же сервер, где работает приложение?

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

Sentry бесплатный?

Self-hosted — да, в рамках Functional Source License: использовать в компании любого размера можно, продавать как сервис нельзя. Ограничений на число событий и пользователей нет — только ресурсы вашего сервера.

Что будет с историей ошибок при обновлении?

Данные переживают обновление, если проходить обязательные промежуточные версии и делать снимок перед каждым шагом. Прыжок через hard stop почти гарантированно ломает миграции, и восстанавливаться придётся из снимка.

Нужен ли Sentry, если есть система логирования?

Это разные инструменты. Логи отвечают на вопрос «что происходило», Sentry — «где именно сломалось и у кого». Для отладки инцидента нужны оба, но начинают обычно с Sentry: он сам сообщает о новом сбое, не дожидаясь, пока кто-то пойдёт читать логи.

Как не потерять события при всплеске?

Kafka в составе Sentry для этого и стоит: при наплыве события буферизуются, а не теряются. Но если диск закончился, не поможет ничего — поэтому ретенция и алерт на заполнение диска обязательны.

Можно ли вынести Sentry в закрытый контур без интернета?

Да. Установка идёт через прокси или переносом образов с другой машины, а параметр SENTRY_AIR_GAP отключает внешние сетевые обращения. Внутренние ошибки не покидают периметр, но обновления придётся возить руками.

Коротко

Sentry на своём сервере снимает вопрос с недоступностью облака и даёт полный набор функций без платы за события. Цена — 4 ядра, 16 ГБ RAM, NVMe и регулярное обслуживание: обновления по календарю, бэкапы настроек, контроль диска.

Если сервер нужен под это отдельно — смотрите тарифы Tenku: для errors-only хватает старших конфигураций, для полного Sentry с трейсами понадобится машина от 16 ГБ, и это нормально держать на другом сервере, а не на том, где живёт приложение. Перед установкой убедитесь, что есть swap, свободный домен и закрытый порт 9000 — три вещи, которые чаще всего забывают, а потом чинят сбои после переезда.