GlitchTip закрывает большую часть Sentry — вопрос в оставшейся

MAATRIX

Если вы уже пробовали поднять self-hosted Sentry на своём VPS, то знаете это чувство: docker compose up разворачивает полтора десятка контейнеров, Kafka не проходит health-check на слабом железе, а под ClickHouse хочется отдельный сервер помощнее. GlitchTip обещает то же самое — собственный трекер ошибок, совместимый с теми же Sentry SDK — но на стеке в разы легче. Вопрос не в том, работает ли GlitchTip вообще (работает, и стабильно), а в том, что именно вы теряете, когда меняете тяжёлый комбайн на лёгкий инструмент под одну задачу.

Что такое GlitchTip и в чём его расчёт

GlitchTip — open-core проект, который решает одну конкретную задачу: принять ошибку из приложения, сгруппировать её с похожими, показать в интерфейсе и уведомить нужного человека. Ключевая инженерная хитрость в том, что GlitchTip реализует тот же протокол приёма событий, что и Sentry — так называемый Sentry ingestion API. Практически это значит, что стандартные Sentry SDK для Python, JavaScript, Go, PHP, Ruby и десятка других языков отправляют события в GlitchTip без единой правки кода — меняется только DSN в конфиге на адрес вашего сервера. Если вы уже настраивали Sentry SDK по инструкции по установке self-hosted Sentry на VPS, тот же кусок кода инициализации sentry_sdk.init(dsn=...) подключится и к GlitchTip — поменяется только хост в DSN.

Модель «open-core» здесь означает следующее: сам движок GlitchTip публикуется с открытым исходным кодом, разворачивается на своём сервере бесплатно и без урезанных функций в самой системе трекинга ошибок. Монетизация у разработчиков построена не на скрытии кода, а на собственном hosted-тарифе — то есть они зарабатывают, предлагая управляемую версию тем, кто не хочет администрировать сервер сам, а не тем, что прячут функции за платной стеной в self-hosted версии. Это отличает GlitchTip от многих других open-core продуктов, где self-hosted версия урезана нарочно.

Стек GlitchTip построен на Django + PostgreSQL + Redis + Celery — это классический, хорошо изученный набор, который вы, скорее всего, уже администрировали для других проектов на Python. Никакого Kafka, никакого ClickHouse, никакой отдельной очереди symbolication-воркеров с непредсказуемым потреблением памяти. Это и есть главный практический аргумент в пользу GlitchTip: не «он функциональнее», а «он не требует отдельного кластера, чтобы просто ловить исключения».

Минимальный docker-compose и требования к серверу

Официальный репозиторий GlitchTip даёт готовый docker-compose.yml, структура которого выглядит примерно так (адаптируйте под свой сервер — точные версии образов смотрите в актуальном репозитории на день установки):

services:
  postgres:
    image: postgres:16
    volumes:
      - pg_data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: замените_на_свой_пароль
      POSTGRES_DB: glitchtip

  redis:
    image: redis:7

  web:
    image: glitchtip/glitchtip
    depends_on:
      - postgres
      - redis
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://postgres:замените_на_свой_пароль@postgres:5432/glitchtip
      SECRET_KEY: сгенерируйте_свой_секрет
      REDIS_URL: redis://redis:6379/0
      GLITCHTIP_DOMAIN: https://ваш-домен.example
      DEFAULT_FROM_EMAIL: glitchtip@ваш-домен.example
      CELERY_WORKER_AUTOSCALE: "1,3"

  worker:
    image: glitchtip/glitchtip
    command: celery -A glitchtip worker -B -l info
    depends_on:
      - postgres
      - redis
    environment:
      DATABASE_URL: postgres://postgres:замените_на_свой_пароль@postgres:5432/glitchtip
      SECRET_KEY: сгенерируйте_свой_секрет
      REDIS_URL: redis://redis:6379/0

  migrate:
    image: glitchtip/glitchtip
    command: ./manage.py migrate
    depends_on:
      - postgres
    environment:
      DATABASE_URL: postgres://postgres:замените_на_свой_пароль@postgres:5432/glitchtip
      SECRET_KEY: сгенерируйте_свой_секрет

volumes:
  pg_data:

Всего четыре сервиса вместо полутора десятков у Sentry. После первого запуска создайте суперпользователя внутри контейнера:

docker compose run --rm web ./manage.py createsuperuser

Разница в требованиях к железу ощутима на практике, а не только на бумаге. Для сравнения — по подробному разбору сколько RAM нужно для Sentry self-hosted реалистичная точка входа для Sentry — от 8–16 ГБ RAM и 4 vCPU, в основном из-за ClickHouse и Kafka. GlitchTip на сопоставимом объёме событий (единицы-десятки тысяч в месяц) обычно комфортно работает на 1–2 vCPU и 1–2 ГБ RAM — конкретная цифра зависит от вашей нагрузки и retention, поэтому воспринимайте это как ориентир для планирования, а не гарантию, и мониторьте потребление после первых недель работы под реальным трафиком.

Что GlitchTip закрывает полностью: сбор и группировка ошибок

Ядро продукта у GlitchTip сделано добросовестно, а не «для галочки». Что реально работает так же, как в Sentry, для типичного проекта:

• Приём и группировка ошибок (issue grouping). Похожие исключения схлопываются в один issue по стектрейсу, как и в Sentry — вы видите не тысячу одинаковых записей, а один инцидент с счётчиком срабатываний.
• Source maps. Для минифицированного JS/TS GlitchTip умеет разворачивать стектрейс до исходных строк кода, если вы загружаете source maps через тот же release-механизм, что и в Sentry SDK.
• Releases и связка с деплоями. Можно помечать события версией релиза и видеть, в каком именно деплое появилась регрессия — базовая, но рабочая функциональность.
• Уведомления. Email, webhook и интеграция с популярными мессенджерами для алертов по новым или участившимся ошибкам — правила настраиваются на уровне проекта.
• Организации, проекты, команды. Многопользовательская структура с ролями — подходит и для одного человека, и для команды из нескольких разработчиков с разграничением доступа к проектам.
• API-совместимость на уровне приёма событий. Именно за счёт этого миграция с SaaS-тарифа Sentry на self-hosted GlitchTip технически сводится к смене DSN в конфиге приложения, без переписывания инструментирования кода.

Для команды, чья единственная задача — «узнать о падении раньше пользователя и понять, где в коде оно случилось», это покрывает практически всё. Именно эту базовую функцию 80% пользователей Sentry используют в 95% случаев — но у Sentry вокруг неё выстроен большой слой дополнительных инструментов, и вот тут начинается разница.

Чего в GlitchTip нет: performance monitoring и трассировка

Самый заметный пробел — у GlitchTip нет полноценного performance monitoring в смысле Sentry: распределённой трассировки транзакций, замеров времени между сервисами, флейм-графов запроса от фронтенда до базы данных. Sentry Performance показывает не только факт ошибки, но и то, что запрос к /api/checkout внезапно стал выполняться в три раза дольше из-за медленного N+1-запроса в ORM — до того, как это превратилось в таймаут и полноценное исключение. GlitchTip такую картину не строит: он видит ошибку, но не видит «здоровье» запроса, который ещё не упал.

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

Профилирования кода (continuous profiling — построчный разбор, где именно приложение тратит CPU-время) в GlitchTip тоже нет. Это специфичная функция, которая в Sentry появилась сравнительно недавно и закрывает узкую, но реальную задачу — найти «горячую» функцию без ручной расстановки таймеров в коде. Для большинства команд, которые не занимаются перформанс-инжинирингом на постоянной основе, отсутствие профилирования не критично: эта функция используется точечно, при расследовании конкретной проблемы с производительностью, а не ежедневно.

Session replay, AI-функции и другие продвинутые возможности Sentry

Session replay — запись сессии пользователя (клики, скроллы, состояние DOM) с привязкой к конкретной ошибке — в GlitchTip отсутствует полностью. Это одна из самых заметных фронтенд-фич Sentry последних лет: вместо того чтобы гадать, что делал пользователь перед креш-репортом, вы буквально пересматриваете видео его сессии. Для команд с сложным фронтенд-UX, где баги воспроизводятся только в специфичной последовательности действий, это реально экономит часы расследования. Для бэкенд-сервисов или простых сайтов эта функция чаще остаётся невостребованной — там ошибку понятно и по стектраку с контекстом запроса.

Также у Sentry гораздо более развитый Discover / query builder — конструктор произвольных запросов по накопленным событиям с построением дашбордов и агрегаций. GlitchTip даёт список issues с фильтрами по проекту, статусу и уровню серьёзности, но не свободный SQL-подобный конструктор запросов по всему объёму данных. Если нужна не лента ошибок, а аналитика вида «сколько уникальных пользователей затронула эта регрессия за 30 дней в разрезе версии приложения» — в Sentry это встроено, в GlitchTip придётся выгружать данные и считать отдельно.

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

Экосистема интеграций и enterprise-функции

У Sentry за годы накопилась широкая маркетплейс-экосистема: Jira, Slack, PagerDuty, Vercel, GitHub с автоматическим suspect commit (кто из разработчиков, скорее всего, внёс баг, по git blame на стектрейсе), Crons — мониторинг того, что регулярные задачи (cron, celery beat) реально отрабатывают вовремя. GlitchTip покрывает базовые сценарии — вебхуки и уведомления в основные мессенджеры есть — но глубоких готовых интеграций с трекерами задач и инцидент-менеджментом заметно меньше. Если процесс завязан на автосоздание тикета в Jira с двусторонней синхронизацией статуса — в GlitchTip это, скорее всего, придётся собирать самостоятельно через общий webhook, а не включать галочкой в настройках.

Из enterprise-слоя стоит отметить SSO/SAML — в Sentry это часть платных тарифов с готовым UI под корпоративные требования; в self-hosted GlitchTip аутентификация проще, и сложный SSO придётся настраивать через обратный прокси с внешним провайдером идентификации. Для небольшой команды на своём VPS это обычно не проблема; для организации с требованиями комплаенса — фактор, который стоит проверить заранее.

Когда переходить на GlitchTip, а когда остаться на Sentry

Решение здесь не про «что лучше» вообще, а про то, что конкретно вы используете из Sentry сегодня. Практический чек-лист:

• Переходите на GlitchTip, если вы используете Sentry исключительно как трекер ошибок — issue tracking, группировка, алерты — и не открываете вкладку Performance или Replay месяцами. Экономия на ресурсах сервера и упрощение эксплуатации в этом случае реальны и сразу заметны: вместо кластера из полутора десятков контейнеров — четыре сервиса на Django-стеке, который проще понять и починить при сбое.
• Переходите на GlitchTip, если у вас уже есть отдельная система трассировки (или вы готовы поднять OpenTelemetry-стек отдельно) — тогда отсутствие Performance monitoring в трекере ошибок не потеря, а осознанное разделение ответственности между инструментами.
• Оставайтесь на Sentry, если ваша команда активно использует session replay для фронтенд-расследований, Discover для аналитики по накопленным событиям или глубокие интеграции с Jira/PagerDuty как часть налаженного инцидент-процесса — переезд на GlitchTip в этом случае не экономия, а откат функциональности, который команда почувствует в первую же неделю.
• Считайте экономику, а не только функциональность. Даже если Performance monitoring вам не критичен, полезно сравнить, во что обходится текущий SaaS-тариф Sentry и своя аренда сервера — методика такого расчёта разобрана в статье свой Sentry вместо платного тарифа: цена ошибки; та же логика применима и при выборе между self-hosted Sentry и self-hosted GlitchTip — сравнивайте не абстрактную «мощность» продукта, а то, что вы реально используете каждый день.

Гибридный вариант тоже имеет право на жизнь: часть проектов (внутренние сервисы, MVP, бэкенд-микросервисы без сложного UX) переводить на лёгкий GlitchTip, а флагманский продукт с фронтенд-сложностью и требованиями к аналитике оставить на Sentry — self-hosted или SaaS. Ничто не обязывает выбирать один инструмент для всей инфраструктуры разом.

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