Как установить и настроить Sentry (self-hosted) на VPS

MAATRIX

Облачный Sentry быстро упирается в лимиты бесплатного тарифа — 5 тысяч событий в месяц исчезают за первый день, если у приложения есть баги под нагрузкой, а платные планы считают события в долларах, которые ещё нужно суметь оплатить из России. Self-hosted Sentry на собственном VPS снимает оба ограничения: событий сколько угодно, данные лежат у вас, а тратите вы только на сервер. Ниже — рабочий способ поднять его через Docker Compose, без плясок с зависимостями.

Что реально нужно от сервера

Sentry self-hosted — это не один контейнер, а связка из полутора десятков сервисов: сам веб-интерфейс, Postgres, Redis, Kafka, ClickHouse, Zookeeper, воркеры для обработки событий (relay, snuba, symbolicator) и ещё несколько вспомогательных. Официальный докер-компоуз поднимает всё это одной командой, но ресурсы съедает заметные.

Ориентир, с которым Sentry действительно работает без постоянных OOM-килов:

На 4 ГБ RAM Sentry формально стартует, но Kafka и ClickHouse начинают конкурировать за память, и первые же нагрузочные всплески укладывают контейнеры в перезапуск по кругу. Если проект небольшой и вы просто хотите ловить исключения из одного-двух сервисов — берите VPS с 8 ГБ RAM и 4 ядрами как стартовую точку, это компромисс между ценой и стабильностью. Точных цифр по времени отклика или пропускной способности не привожу намеренно — они сильно зависят от потока событий и конкретного железа, лучше замерить на своей нагрузке.

Понадобится домен (Sentry без него неудобен — придётся ходить по IP:9000) и открытые порты 80/443 наружу. Если DNS ещё не настроен на новый сервер, сначала разберитесь с настройкой домена и DNS — Sentry ставится поверх уже работающего домена.

Подготовка сервера и Docker

Всё делаем от пользователя с правами sudo, не от root.

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

# Docker Engine + Compose plugin
curl -fsSL https://get.docker.com | sh
usermod -aG docker $USER
newgrp docker

docker --version
docker compose version

Проверьте, что версия Docker Compose именно plugin-формата (docker compose, без дефиса) — официальный установщик Sentry рассчитан на неё, а не на старый docker-compose.

Если сервер будет держать несколько контейнерных стеков и вы ещё не настраивали продакшен-конфигурацию Compose — стоит сначала пройтись по Docker Compose для продакшена, там разобраны лимиты ресурсов и restart-политики, которые пригодятся и здесь.

Увеличьте лимиты для Kafka и Elasticsearch/ClickHouse — без этого контейнеры падают на старте с ошибкой max virtual memory areas vm.max_map_count is too low:

echo "vm.max_map_count=262144" >> /etc/sysctl.conf
sysctl -p

Установка self-hosted Sentry

Официальный репозиторий getsentry/self-hosted содержит скрипт установки, который сам собирает нужные образы и генерирует конфиги.

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

# фиксируем стабильную версию, а не bleeding-edge master
git tag | tail -20
git checkout 24.9.1   # подставьте актуальный релиз на момент установки

Не берите master в продакшен — это ветка разработки, там встречаются breaking changes между коммитами. Смотрите список тегов и берите последний стабильный релиз.

Запускаем установщик:

./install.sh

Скрипт спросит:

• создавать ли аккаунт администратора (да, сразу задайте email и пароль);
• отправлять ли анонимную телеметрию в Sentry (можно отключить);
• сгенерирует .env с секретным ключом SENTRY_SECRET_KEY — не теряйте его, он завязан на шифрование данных в базе.

Установка занимает от 10 до 30 минут в зависимости от скорости диска и сети — скачиваются образы Kafka, ClickHouse, Snuba, Relay и ещё десяток сервисов суммарно на несколько гигабайт.

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

docker compose up -d
docker compose ps

Дождитесь, пока все контейнеры перейдут в healthy или хотя бы running — на первом старте snuba-* сервисы могут перезапускаться пару раз, пока миграции ClickHouse не отработают до конца. Смотрите логи проблемных контейнеров:

docker compose logs -f web
docker compose logs -f snuba-api

Nginx как reverse proxy и SSL

Sentry по умолчанию слушает 9000 на localhost внутри Docker-сети. Наружу его пускаем через nginx с HTTPS — так же, как для любого другого веб-сервиса за прокси.

server {
    listen 80;
    server_name sentry.example.com;
    return 301 https://$host$request_uri;
}

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

    ssl_certificate     /etc/letsencrypt/live/sentry.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sentry.example.com/privkey.pem;

    client_max_body_size 20m;

    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;
        proxy_read_timeout 90s;
    }
}

client_max_body_size увеличен намеренно — события с большими стектрейсами и source maps иногда превышают дефолтные 1 МБ nginx, и клиент получает 413 вместо успешной записи события.

Если nginx как reverse proxy для вас в новинку — подробный разбор с базовыми конфигами есть в статье Nginx как reverse proxy. Сертификат получаем стандартно через certbot; если сомневаетесь между certbot и acme.sh — сравнение есть в статье certbot или acme.sh.

apt install -y certbot python3-certbot-nginx
certbot --nginx -d sentry.example.com

После выпуска сертификата обновите SENTRY_URL_PREFIX в .env на https://sentry.example.com и перезапустите веб-контейнер:

docker compose restart web worker cron

Первый проект и интеграция с приложением

Заходите на https://sentry.example.com, логинитесь под учёткой, созданной при установке, и создаёте организацию и первый проект — выбираете платформу (Python, Node.js, PHP, Go и так далее), Sentry выдаёт DSN — уникальный URL для отправки событий из вашего кода.

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

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

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

Для Python (Django/Flask через SDK):

import sentry_sdk

sentry_sdk.init(
    dsn="https://xxxxxxxx@sentry.example.com/2",
    environment="production",
    traces_sample_rate=0.2,
)

traces_sample_rate ниже 1.0 — сознательный выбор для продакшена: трассировка производительности (performance monitoring) резко увеличивает объём данных, и на своём железе это в первую очередь означает нагрузку на ClickHouse и диск, а не абстрактный лимит квоты как в облаке.

Если приложение и Sentry держите на одном сервере с базой данных под нагрузкой — обратите внимание на тюнинг PostgreSQL, потому что сам Sentry активно пишет в свой Postgres, и дефолтные настройки на слабом VPS иногда становятся узким местом раньше, чем ожидаешь.

Бэкапы: что сохранять и как

Self-hosted означает, что за сохранность данных отвечаете вы. У Sentry есть встроенный скрипт бэкапа Postgres:

cd /opt/sentry
docker compose run --rm postgres backup > /opt/sentry-backups/sentry-$(date +%F).sql

Но в Postgres лежат только метаданные (проекты, пользователи, настройки, релизы), а сами события и трассировки хранятся в ClickHouse и на файловой системе (blob storage для артефактов и source maps в каталоге /opt/sentry/data). Полный бэкап должен закрывать оба слоя:

# метаданные
docker compose run --rm postgres backup > /backup/pg-$(date +%F).sql

# файловые данные (артефакты, uploads)
tar czf /backup/sentry-data-$(date +%F).tar.gz /opt/sentry/data

# конфигурация
cp /opt/sentry/.env /backup/env-$(date +%F).bak

ClickHouse-данные (сами события) в стандартной поставке бэкапятся сложнее — это отдельный кластер с собственным форматом хранения, и для не самого критичного сценария (события — это диагностика, а не источник истины) многие ограничиваются ротацией: держат события 90 дней (настройка SENTRY_EVENT_RETENTION_DAYS в .env) и не тянут их в бэкапы вообще, полагаясь на то, что метаданные и код важнее исторических стектрейсов. Решайте по своей ситуации — если для вас важна долгая история ошибок, изучайте документацию по бэкапу ClickHouse отдельно, это выходит за рамки базовой установки.

Автоматизировать бэкапы Postgres и файлов удобно через cron с ротацией старых архивов — общий подход к автоматизации бэкапов на сервере описан в статье про бэкап и восстановление (пример на VPN-сервере, но логика cron+ротация переносится один в один).

Обновление и обслуживание

Self-hosted Sentry обновляется примерно раз в 1-2 месяца новыми релизами — в них правят уязвимости и добавляют функции UI. Процесс:

cd /opt/sentry
git fetch --tags
git checkout <новый-тег>
./install.sh   # применит новые миграции
docker compose up -d

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

Регулярно проверяйте место на диске: ClickHouse и Kafka по умолчанию пишут довольно много, и на маленьком диске (60 ГБ) это забивается за несколько недель активного трафика ошибок:

docker system df
du -sh /opt/sentry/data/*

Если видите, что диск подъедается быстрее ожидаемого — либо снижайте SENTRY_EVENT_RETENTION_DAYS, либо переезжайте на VPS с диском побольше, благо на VPS это обычно вопрос апгрейда тарифа, а не переустановки системы.

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