Sentry (self-hosted) на Ubuntu 24.04: пошаговая установка

MAATRIX

Когда приложение падает у пользователя в проде, узнавать об этом из тикета в поддержку — плохая практика. Sentry ловит исключения, стек-трейсы и падения фронтенда и бэкенда в реальном времени, но облачная версия быстро упирается в лимиты бесплатного тарифа и хранит ваши данные (включая куски пользовательского ввода в трейсах) на чужих серверах. Self-hosted Sentry снимает оба ограничения: события хранятся у вас, лимитов по количеству нет, а вы платите только за сервер. Ниже — пошаговая установка на Ubuntu 24.04 через Docker Compose, от голого сервера до первого события в дашборде.

Что такое Sentry self-hosted и зачем он вам

Sentry — это не одно приложение, а стек из десятка сервисов: веб-интерфейс и API на Python/Django, воркеры для обработки событий, Postgres для метаданных, Redis для очередей и кеша, Kafka как шина сообщений, ClickHouse и Snuba для хранения и поиска по событиям, Relay как приёмник событий на границе, Symbolicator для символизации нативных крашей. Официальный репозиторий getsentry/self-hosted собирает всё это в единый docker-compose стек и разворачивает одной командой — вручную поднимать каждый сервис отдельно смысла нет.

Это оправдано, если вы: держите несколько продакшен-приложений и хотите единую точку сбора ошибок; работаете с чувствительными данными и не можете отправлять трейсы на сторонние серверы; упёрлись в лимит событий на бесплатном плане Sentry Cloud. Если нужен разовый мониторинг одного pet-проекта — возможно, хватит и облачного бесплатного тарифа, self-hosted стек всё же требует отдельного сервера и его обслуживания.

Требования к серверу перед установкой

Стек тяжёлый именно из-за Kafka и ClickHouse — они держат много данных в памяти и на диске даже в состоянии покоя. По документации проекта официально рекомендуется от 16 ГБ RAM и 4 vCPU для стабильной установки; это ориентир разработчиков Sentry, а не жёсткий минимум — на 8 ГБ стек тоже может подняться, но шаг миграций ClickHouse во время установки нередко падает по нехватке памяти, и тогда установку приходится перезапускать после добавления свопа. Диска стоит закладывать от 30-40 ГБ на старте: события и трейсы накапливаются быстро, особенно если ретенция настроена на 90 дней.

Практический ориентир для конфигурации сервера:

Если планируете тестовый запуск на минимальных ресурсах, заранее настройте своп — это снимает большинство падений на этапе install.sh. Как это сделать с нуля, разобрано в статье про настройку swap на Ubuntu 24.04.

Устанавливаем Docker и Docker Compose

Sentry self-hosted целиком живёт в Docker, поэтому сначала ставим движок. На чистой Ubuntu 24.04 удобнее всего через официальный скрипт:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg git

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

sudo usermod -aG docker $USER
newgrp docker

Скрипт ставит docker-ce, containerd и плагин docker-compose-plugin, поэтому команда docker compose (без дефиса) сразу доступна. Проверка:

docker --version
docker compose version

Если сервер только что арендован и ещё не настроен вообще, имеет смысл сначала пройти базовую защиту — создать пользователя без root, настроить SSH-ключи и файрвол. Это подробно описано в статье про первичную настройку и безопасность Ubuntu 24.04, а закрыть лишние порты поможет материал по настройке ufw — снаружи должны быть открыты только 22, 80 и 443.

Скачиваем и разворачиваем Sentry

Клонируем официальный репозиторий и запускаем установочный скрипт:

git clone https://github.com/getsentry/self-hosted.git sentry
cd sentry
./install.sh

Скрипт делает всё сам: тянет образы, генерирует .env с секретными ключами, поднимает Postgres/Redis/Kafka/ClickHouse, прогоняет миграции базы и Snuba, а в конце предложит создать первого администратора (email и пароль). Процесс на слабом канале и небыстром диске может занять 15-30 минут — это нормально, торопиться не стоит.

Если установщик упал на середине (чаще всего — на шаге миграций ClickHouse из-за нехватки памяти), не нужно чистить всё с нуля: добавьте своп, при необходимости увеличьте таймауты и запустите ./install.sh повторно — скрипт идемпотентен и продолжит с того места, где смог.

После успешной установки поднимаем стек:

docker compose up -d
docker compose ps

Если контейнеры поднялись, но какой-то из них в статусе restarting, посмотрите логи конкретного сервиса, прежде чем перезапускать всё подряд:

docker compose logs -f web
docker compose logs -f snuba-consumer

По умолчанию Sentry слушает на порту 9000. Локально с сервера можно проверить, что веб-интерфейс жив:

curl -I http://127.0.0.1:9000

Если ответ HTTP/1.1 200 OK (или редирект на страницу логина) — стек поднялся, дальше остаётся настроить внешний доступ по домену.

Настраиваем reverse proxy и SSL для домена

Открывать порт 9000 наружу и вешать самоподписанный сертификат — плохая идея: Sentry получает исключения из прод-приложений, там может оказаться чувствительная информация. Ставим перед ним обратный прокси на 80/443 с автоматическим SSL. Для Nginx конфиг простой:

server {
    listen 80;
    server_name sentry.example.com;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 20m;
    }
}

Дальше — certbot --nginx -d sentry.example.com для сертификата Let's Encrypt. Если раньше не настраивали Nginx как reverse proxy или Let's Encrypt на сервере, подробный разбор есть в статье про Nginx как reverse proxy. Если вместо ручной настройки хочется автоматический SSL из коробки, Caddy с автоматическим SSL заменяет и конфиг, и certbot одним трёхстрочным Caddyfile.

Важный нюанс: после того как Sentry стал доступен по HTTPS-домену, а не по http://IP:9000, нужно поправить SENTRY_URL_PREFIX (или соответствующую переменную в .env/config.yml, в зависимости от версии) на https://sentry.example.com, иначе ссылки в письмах-уведомлениях и в интерфейсе будут вести на старый адрес. После правки — docker compose restart web worker.

Первый вход, создание проекта и подключение SDK

Заходим на https://sentry.example.com, логинимся созданным при установке аккаунтом. Дальше:

1. Создаём организацию (или используете дефолтную из установки).
2. Projects → Create Project, выбираем платформу (Python, Node.js, PHP, JavaScript и так далее) — Sentry сам подставит готовый сниппет для инициализации SDK.
3. Копируем DSN — уникальный URL проекта вида https://<key>@sentry.example.com/<project_id>.

Пример для Node.js:

const Sentry = require("@sentry/node");

Sentry.init({
  dsn: "https://<key>@sentry.example.com/<project_id>",
  tracesSampleRate: 0.2,
  environment: process.env.NODE_ENV,
});

Для Python/Django — аналогично через sentry_sdk.init(dsn=...) в точке входа приложения. Проверить связку просто: вызовите в коде тестовое исключение (Sentry.captureException(new Error("test")) или 1/0 в Python) и убедитесь, что событие появилось в дашборде в течение нескольких секунд. Если событие не приходит — первым делом проверяйте исходящие соединения с сервера приложения до Sentry (файрвол, DNS) и правильность DSN, а не сам Sentry-стек — он к этому моменту уже подтверждённо работает.

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

Обновление. Sentry self-hosted обновляется переключением на нужный тег и повторным запуском установщика:

cd sentry
git fetch --tags
git checkout <нужная-версия>
./install.sh
docker compose up -d

Не пропускайте install.sh при обновлении — он прогоняет миграции базы, без него новый образ веб-сервиса может не подняться на старой схеме БД. Не обновляйтесь через несколько мажорных версий разом — читайте CHANGES.md в репозитории на промежуточные версии, иногда там встречаются breaking changes в схеме конфигурации.

Бэкапы. Критичные данные — том Postgres и том, где Sentry хранит файлы (аватары, артефакты сорсмапов). Минимально:

docker compose exec postgres pg_dump -U postgres postgres > sentry_backup_$(date +%F).sql

Плюс бэкап docker volumes целиком через docker run --rm -v <volume>:/data -v $(pwd):/backup alpine tar czf /backup/volume.tar.gz -C /data . — так восстановление после падения сервера занимает минуты, а не пересборку стека с нуля.

Частые проблемы:

• Установщик падает на шаге ClickHouse/Snuba — почти всегда нехватка RAM, лечится свопом.
• После docker compose up -d часть контейнеров в restarting — смотрите docker compose logs, чаще всего это kafka или zookeeper, не успевшие подняться до того, как к ним обратились зависимые сервисы; повторный docker compose up -d обычно решает.
• Nginx отдаёт 502 — проверьте, что контейнер web действительно слушает 9000 (docker compose ps), а не упал молча.
• Письма-уведомления не приходят — нужно прописать SMTP-параметры (SENTRY_MAIL_HOST, SENTRY_MAIL_PORT, SENTRY_MAIL_USERNAME, SENTRY_MAIL_PASSWORD) в .env и перезапустить web и worker.

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