GlitchTip на VPS: замена Sentry за 512 МБ памяти

Если приложение падает у клиента, вы узнаете об этом двумя путями: либо из письма от разъярённого пользователя, либо из трекера ошибок. GlitchTip — второй путь, и он стоит 512 МБ оперативной памяти на вашем же сервере.

Это открытый трекер ошибок с лицензией MIT, который понимает DSN от Sentry. То есть библиотеки в приложении менять не нужно: ставите GlitchTip, создаёте проект, подменяете адрес — и те же исключения с теми же стеками начинают приходить к вам, а не в чужое облако. Внутри Django, PostgreSQL и один сервис вместо полутора десятков контейнеров, как у self-hosted Sentry.

Ниже — установка на VPS, честные требования по памяти и диску, настройки, без которых через месяц будет больно, и сравнение с Sentry без маркетинга. Актуальная версия на конец октября 2026 — 9.1.1, цены провайдеров сверены 30 октября.

Что такое GlitchTip и почему вспоминают именно его

Задача трекера ошибок простая: приложение ловит исключение, отправляет его на сервер, вы видите в панели стек вызовов, версию релиза и число пользователей, которых это задело. Тысяча одинаковых падений схлопывается в одну запись со счётчиком.

Sentry делает это лучше всех — и требует 4 ядра и 16 ГБ RAM минимум, потому что внутри Kafka, ClickHouse, Snuba, Symbolicator и ещё десяток сервисов. Для команды из трёх человек, которая ловит 50 тысяч ошибок в месяц, это как возить хлеб фурой.

GlitchTip решает ту же задачу скромнее: события лежат в PostgreSQL, фоновые задачи крутит Celery, кэш опционален. Отсюда и разница в требованиях — в 30 раз меньше памяти на старте. Ограничение тоже понятное: очень большие объёмы событий PostgreSQL переваривает хуже, чем ClickHouse, и на десятках миллионов событий в месяц придётся думать про холодное хранение и партиционирование (о нём ниже — оно уже встроено).

Кому подходит: небольшим продуктовым командам, веб-студиям с десятком клиентских сайтов, проектам на 1С-стеке с внешними интеграциями, всем, кто хочет мониторинг ошибок в своём периметре без счёта за каждую тысячу событий.

Кому не подходит: если нужны трейсы уровня Sentry с профилированием каждой транзакции, session replay и AI-разбор инцидентов — это не сюда, там всё-таки Sentry.

Что умеет, кроме собственно ошибок

За последние версии GlitchTip перестал быть «просто трекером». На октябрь 2026 в нём есть:

• Группировка ошибок и стеки вызовов — базовое, работает как ожидается: issue, счётчик, первое и последнее событие, список затронутых пользователей.
• Релизы — метка версии приложения. Видно, после какого деплоя пошёл всплеск.
• Uptime-мониторинг — включён по умолчанию (GLITCHTIP_ENABLE_UPTIME). Проверяет адреса по расписанию и шлёт алерт, когда сайт не отвечает. Отдельный Uptime Kuma больше не обязателен.
• Приём логов по OTLP — GLITCHTIP_ENABLE_LOGS. Логи и ошибки в одном окне, что удобно: видно, что приложение писло перед падением.
• Холодное хранение — GLITCHTIP_ENABLE_DUCKDB=true. Свежие события живут в PostgreSQL 30 дней, потом уезжают в Parquet на S3 или локальный диск и читаются через DuckDB. База не растёт бесконечно, а история остаётся.
• Sourcemaps и вложения — можно подгружать карты для фронтенда, чтобы минифицированный стек читался.
• Алерты — почта, вебхуки, интеграции с мессенджерами через правила: «новая issue», «частота выросла», «событие с тегом production».
• Метрики Prometheus — ENABLE_OBSERVABILITY_API, если вы мониторите сам мониторинг.

Список интеграций скромнее, чем у Sentry, и это надо принять сразу. Зато всё перечисленное работает без Kafka.

Сколько ресурсов нужно на самом деле

Официальные цифры GlitchTip на октябрь 2026:

Три вещи, которые чаще всего недооценивают.

Диск, а не память. 512 МБ хватает процессу, но события копятся в базе. Миллион событий в месяц — это порядка 30 ГБ. Если приложение шлёт ошибки пачками (а оно шлёт), место кончится быстрее, чем вы думаете.

Буферизация на прокси. Запрос от SDK может быть большим — вложение, sourcemap, длинный стек. Без client_max_body_size 40M и буферизации nginx часть событий отвалится с 413, и вы узнаете об этом по пустым issue.

Резерв по памяти. 512 МБ — это когда всё хорошо. Пик одновременных событий, миграция базы или архивация в холодное хранилище легко добавляют сотню-другую мегабайт. На 512 МБ без swap OOM-killer выберет самый жирный процесс — обычно PostgreSQL.

Какой VPS брать под GlitchTip

Считайте от объёма событий и от того, нужны ли логи и uptime-проверки.

Несколько замечаний к таблице.

• Дешёвый тариф на 2 ГБ берут чаще всего, и на одном проекте этого честно хватает: GlitchTip с PostgreSQL забирает около 700–900 МБ.
• Если планируете хранить события дольше 90 дней или включить cold storage, смотрите на диск, а не на память: Parquet-архив растёт, а RAM почти нет.
• Локация важнее, чем кажется: SDK шлёт события по HTTP, и при разнице в 150 мс каждая ошибка на фронте добавляет задержку в отправке. Берите сервер в том же регионе, где живут пользователи и приложение.
• Локации и цены конкретных провайдеров — в каталоге VPS: там фильтры по памяти, диску, стране и виртуализации. Для сравнения: DockerHosting.ru даёт 2 ГБ и 15 ГБ NVMe за 299 ₽ в Москве и Новосибирске, Contabo — 8 ГБ и 75 ГБ за 425,70 ₽, Hetzner — 8 ГБ и 80 ГБ за 803,15 ₽.

Установка за шесть шагов

Ubuntu 24.04, пользователь с sudo, домен glitchtip.example.com уже смотрит A-записью на сервер.

Шаг 1. Docker и Compose.

sudo apt update && sudo apt install -y docker.io docker-compose-v2
sudo systemctl enable --now docker
docker compose version

Версия Compose должна быть 2.x. Если в репозитории Ubuntu её нет — ставьте Docker из официального репозитория, как в инструкции на docs.docker.com.

Шаг 2. Файл compose.

mkdir -p /opt/glitchtip && cd /opt/glitchtip
curl -o compose.yml https://glitchtip.com/assets/compose.sample.yml

Внутри — GlitchTip в режиме all-in-one, PostgreSQL и опциональный Valkey. Для сервера на 256–512 МБ в файле есть закомментированные опции отключения лишнего: их надо раскомментировать, иначе не хватит памяти.

Шаг 3. Переменные.

Минимум, без чего не поднимется:

SECRET_KEY: "длинная случайная строка"
GLITCHTIP_DOMAIN: "https://glitchtip.example.com"
EMAIL_URL: "smtp://user:pass@smtp.example.com:587/?tls=True"
DEFAULT_FROM_EMAIL: "glitchtip@example.com"

SECRET_KEY — не «changeme»: от него зависят сессии и подписи. Сгенерируйте: openssl rand -hex 32.

EMAIL_URL — обязательное поле, но если почты пока нет, поставьте consolemail://: письма будут падать в лог контейнера, а не в космос. Позже замените на реальный SMTP — без почты не придут ни приглашения, ни алерты.

Шаг 4. Запуск.

docker compose up -d
docker compose ps

Первый запуск скачивает образы и делает миграции автоматически. Через минуту веб доступен на 127.0.0.1:8000. Порт наружу не публикуйте — только через прокси.

Шаг 5. nginx и HTTPS.

server {
    server_name glitchtip.example.com;
    client_max_body_size 40M;
    location / {
        proxy_pass http://127.0.0.1:8000;
        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;
    }
}

Дальше certbot --nginx -d glitchtip.example.com. Про client_max_body_size и заголовок X-Forwarded-Proto забывают чаще всего, и получают либо обрезанные события, либо редирект на http после логина.

Шаг 6. Первый вход и проект.

Открываете домен, регистрируете первую учётную запись — она становится владельцем. Создаёте организацию, потом проект под нужную платформу (Python, PHP, JavaScript, Go, .NET). GlitchTip покажет DSN вида https://ключ@glitchtip.example.com/1.

В приложении меняется одна строка. Для Python:

import sentry_sdk
sentry_sdk.init(
    dsn="https://ключ@glitchtip.example.com/1",
    environment="production",
    release="backend@1.4.2",
    traces_sample_rate=0.1,
)

Проверка: вызовите исключение руками — оно должно появиться в списке issue в течение минуты. Если пусто, смотрите логи контейнера: почти всегда дело в DSN или в прокси, который режет тело запроса.

Настройка, без которой через месяц будет больно

Закройте регистрацию. По умолчанию завести аккаунт может любой, кто знает адрес: ENABLE_USER_REGISTRATION включён. На публичном домене это дыра — посторонний создаст организацию и будет лить события в вашу базу. После создания первого аккаунта поставьте ENABLE_USER_REGISTRATION: "false", а коллег добавляйте приглашениями.

Задайте срок хранения. По умолчанию 90 дней. Для сервера на 40 ГБ это много:

GLITCHTIP_RETENTION_DAYS: "90"
GLITCHTIP_EVENT_RETENTION_DAYS: "90"
GLITCHTIP_EVENT_HOT_DAYS: "30"

Смысл: 30 дней события лежат в PostgreSQL, дальше — в холодном хранилище (если включён DuckDB). Если холодное хранилище не нужно, ставьте GLITCHTIP_EVENT_RETENTION_DAYS: "30" и не думайте про диск.

Настройте почту и проверьте её. Алерт, который не дошёл, хуже отсутствия алерта: вы уверены, что мониторинг есть. После настройки SMTP отправьте тестовое письмо из интерфейса.

Сделайте бэкап базы до того, как она станет нужной.

docker compose exec -T postgres pg_dump -U postgres glitchtip | gzip > /backup/glitchtip-$(date +%F).sql.gz

Раз в сутки в cron, раз в квартал — пробное восстановление на отдельной машине. Как организовать это по-нормальному — в статье про бэкапы VPS.

Включите метрики, если есть чем смотреть. ENABLE_OBSERVABILITY_API: "true" открывает /metrics для Prometheus. Мониторинг мониторинга — не паранойя: трекер, который молча упал, создаёт ложное чувство контроля.

Обновление и бэкап

Обновление в GlitchTip короткое — за это его и любят:

cd /opt/glitchtip
docker compose pull
docker compose stop
docker compose up -d

Миграции применяются сами при старте. Мажорные версии выходят примерно раз в год, и там бывают ломающие изменения (например, отказ от старых версий PostgreSQL) — перед мажором читайте release notes, а не «потом разберёмся».

Порядок безопасного обновления выглядит так: pg_dump → docker compose pull → stop → up -d → проверка / и отправка тестового события из приложения. Если событие не дошло — смотреть логи веб-сервиса и воркера, а не перезагружать сервер.

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

• События не приходят, в панели пусто. DSN не тот (перепутан проект), либо прокси режет запрос. Проверять логи контейнера web и curl с самого сервера на /api/1/store/.
• 413 Request Entity Too Large. Не задан client_max_body_size. Симптом коварный: мелкие ошибки проходят, крупные с вложениями — нет.
• Вход зацикливается, после логина снова форма. Не передаётся X-Forwarded-Proto, Django считает соединение http и не ставит защищённую куки.
• Контейнеры падают с OOM на 256 МБ. Не хватило памяти на пик: включён Valkey, идёт миграция или архивация. Добавить swap, отключить Redis, поднять тариф.
• База растёт быстрее диска. Не настроен retention или в проекте шлют каждый запрос как событие. Смотреть распределение по проектам и резать шум в SDK (ignore_errors, traces_sample_rate).
• Алерты не приходят. Не настроен EMAIL_URL, либо письма уходят в спам из-за отсутствия SPF и PTR у домена.
• Uptime-проверки не работают по внутренним адресам. Так задумано: приватные IP запрещены для защиты от SSRF. Включается отдельным флагом, если мониторите внутреннюю сеть.

GlitchTip или Sentry: когда что

Практическое правило: до нескольких миллионов событий в месяц и без требований к трейсам — GlitchTip. Если нужен полный APM с профилированием и бюджетом на 32 ГБ RAM — Sentry. Перейти с одного на другой можно сменой DSN, история ошибок при этом не переедет.

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

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

Да, код открыт под лицензией MIT: ставить, менять, использовать в коммерческих проектах можно без ограничений и без платы за события. Платите только за сервер. У проекта есть и облачная версия от разработчиков — она платная, но не обязательная.

Подойдёт ли GlitchTip, если приложение уже отправляет ошибки в Sentry?

Да, это его сильная сторона: DSN-формат совместим, SDK менять не нужно. Меняете адрес в конфиге приложения — события начинают приходить в GlitchTip. Обратный переезд тоже работает.

Хватит ли 1 ГБ RAM?

Для одного-двух небольших проектов — да, если не включать Valkey и холодное хранилище. На практике GlitchTip с PostgreSQL на 2 ГБ занимает 700–900 МБ, так что 1 ГБ — это впритык, без запаса на пики и обновления. Ставить 2 ГБ спокойнее.

Нужен ли Redis?

Нет, Valkey или Redis 7+ опционален. Он ускоряет очереди и нужен на больших объёмах. На сервере с 512 МБ его лучше не включать вовсе — память нужнее PostgreSQL.

Что будет с событиями, когда закончится место на диске?

GlitchTip перестанет принимать новые события: PostgreSQL не сможет писать. Панель при этом продолжит открываться, и это сбивает с толку. Поэтому retention и алерт на заполнение диска — обязательная часть настройки, а не «потом».

Сколько времени занимает установка?

От 20 до 40 минут на чистом сервере: Docker, compose-файл, переменные, nginx и сертификат. Дольше всего — выпуск сертификата и настройка почты, если SMTP-доступ надо получать у администратора.

Можно ли ставить GlitchTip на тот же сервер, что и приложение?

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

Итог

GlitchTip — редкий случай, когда открытая альтернатива не «хуже, но бесплатно», а просто решает narrower задачу: собирает ошибки, показывает стеки, следит за доступностью и не требует 16 ГБ памяти. Ставится за полчаса, обновляется одной командой, переезд с Sentry — сменой DSN.

Сервер под него нужен скромный: 2 ГБ RAM и 40 ГБ NVMe закрывают один-два проекта с запасом, а если планируете хранить историю дольше 90 дней — смотрите на диск. Подобрать конфигурацию по цене, локации и виртуализации можно в каталоге VPS, там же карточки провайдеров с актуальными тарифами.