Self-hosted альтернативы Sentry: сравнение ресурсов

Стоимость self-hosted систем отслеживания ошибок до обработки первого события

Для self-hosted систем отслеживания ошибок существует один показатель, определяющий выбор — минимальный объем оперативной памяти. Официальная документация Sentry для self-hosted установки требует 4 ядра CPU, 16 GB RAM, 16 GB swap и 20 GB свободного места на диске еще до того, как ваше приложение отправит хотя бы одно событие. GlitchTip требует 512 MB. Все представленные здесь варианты принимают события от одних и тех же Sentry SDK, поэтому выбор не зависит от способа инструментирования кода. Это вопрос о том, за сервер какого размера вы готовы платить и поддерживать его работоспособность.

Опубликованные показатели ресурсов для сравнения

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

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

Значение 16 GB для Sentry является задокументированным минимумом, при этом на той же странице рекомендуется использовать 32 GB. Значение 0.5 GB для GlitchTip является рекомендацией; проект указывает 256 MB как рабочий минимум или 128 MB при использовании swap и тщательной настройке. Значение 4 GB для Bugsink не относится ни к одной из этих категорий: это характеристики сервера, который разработчик использовал для собственного теста производительности. Опубликованная цифра — это отправная точка, а не гарантия работы при вашем объеме событий.

Sentry self-hosted: весь продукт и все расходы

Официальный стек — это getsentry/self-hosted, проект Docker Compose, который запускает те же компоненты, что и Sentry в production. В собственной документации он описан как «полнофункциональный пакет для развертываний с небольшим объемом данных и создания прототипов». Это честное описание. Вы получаете все функции и все движущиеся части, которые обеспечивают их работу.

Устанавливайте из помеченного релиза, а не из 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}
./install.sh

Затем запустите его:

docker compose up --wait

По умолчанию Sentry ожидает запросы на http://127.0.0.1:9000. Требуются Docker Engine 19.03.6 или новее и Docker Compose 2.32.2 или новее; более старые версии Compose выдают ошибку из-за синтаксиса файла, а не из-за действий Sentry.

Посмотрите, что именно вы запустили:

docker compose ps
free -h

docker compose ps перечисляет все сервисы в стеке, и список длинный: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator, а также несколько воркеров и процессов cron. Посчитайте их один раз, так как это число определяет объем вашего обслуживания. Каждая запись — это процесс, который может аварийно завершиться, заполнить диск или вызвать сбой миграции.

Если сервис находится в состоянии Restarting, прежде всего проверьте память:

dmesg -T | grep -i 'out of memory'

Строка вроде Out of memory: Killed process 3412 (java) означает, что OOM killer (out of memory killer) ядра принудительно завершил контейнер, так как на сервере закончилась оперативная память. В результате сервис не переходит в работоспособное состояние, а стек не завершает запуск. Это обычный результат запуска полного стека при несоблюдении минимальных системных требований. Документация также указывает на важность скорости диска: iowait выше 10% означает, что машина не справляется с конвейером обработки данных. Проверяйте это значение в столбце wa в top или через iostat -x 5, если у вас установлен sysstat.

Обновления — это то, что люди недооценивают

Sentry self-hosted выпускается ежемесячно по схеме CalVer (версионирование на основе календаря), основной релиз выходит 15-го числа каждого месяца. Вы не можете перейти со старой версии сразу на последнюю. Проект определяет версии с обязательной промежуточной установкой (hard stops), и вы должны последовательно переключаться на каждую из них, чтобы применить миграции базы данных. По состоянию на август 2026 года установлены следующие обязательные версии: 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 и 26.7.0. В документации также перечислены релизы, которые следует пропустить из-за проблем с миграцией, включая 23.7.0, 25.9.0, 25.12.0 и диапазон с 26.3.0 по 26.4.0.

Обновление состоит из переключения версии и повторного запуска установщика:

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

Перед началом сделайте снимок (snapshot) сервера, так как миграция большого набора данных ClickHouse может длиться часами, а сбой в процессе оставит базу данных в промежуточном состоянии между двумя схемами. Основная причина большинства неудачных обновлений Sentry self-hosted: сервер не обновлялся год, поэтому переход охватывает сразу несколько обязательных версий, и одна из пропущенных миграций оказывается критически важной.

Еще один момент, который нужно знать перед началом работы. Sentry self-hosted распространяется по лицензии Functional Source License (FSL), которую ввела сама компания Sentry. Это «честное» ПО (fair source), а не открытое ПО в понимании OSI: вы можете использовать его для себя, но не можете продавать как конкурирующий сервис. Каждый релиз переходит на лицензию Apache 2.0 через два года после выпуска.

GlitchTip: решение для 512 МБ

GlitchTip распространяется по лицензии MIT и принимает события от SDK с открытым исходным кодом, разработанных для Sentry. Перенос инструментария приложения выполняется путем изменения одного значения: DSN (data source name, URL, на который ваш SDK отправляет события). Требуется PostgreSQL 14 или более поздней версии. Использование Valkey или Redis 7 и выше является опциональным, но повышает производительность крупных инстансов.

Установка выполняется через Docker и один файл compose:

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

Перед запуском отредактируйте раздел environment. Обязательно укажите значения для secret, domain и пути к почтовому серверу:

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

В примере DATABASE_URL уже настроен на работу с собственным сервисом postgres, поэтому не меняйте эту строку, если только вы не используете базу данных, запущенную отдельно. GLITCHTIP_DOMAIN должен включать схему. Без https:// в начале ссылки в письмах с уведомлениями будут сформированы неверно и будут вести на URL, который не отвечает.

Запустите сервис и отслеживайте первый процесс загрузки:

docker compose up -d
docker compose logs -f web

Теги образов в примере на август 2026 года — postgres:18, valkey/valkey:9 и glitchtip/glitchtip:6. Фиксируйте их версии. Файл compose с указанием latest приведет к обновлению движка базы данных при следующем docker compose pull, а переход на мажорную версию Postgres для работающего инстанса — это причина, по которой система отслеживания ошибок перестает запускаться.

Чтобы уложиться в диапазон от 256 МБ до 512 МБ, следуйте комментариям в самом файле примера: там указано, что можно отключить, начиная с Valkey и опциональных функций логирования и мониторинга uptime. Работа без Valkey означает, что GlitchTip будет использовать базу данных для кэширования и работы с очередями, что медленнее, но корректно. Режим «все в одном» запускает worker внутри процесса web, поэтому вы поддерживаете один контейнер приложения вместо двух.

Установите прокси перед сервисом. Документация GlitchTip требует наличия прокси или балансировщика нагрузки, который буферизует запросы и обрабатывает chunked Transfer-Encoding; в качестве примера приводится nginx. Без буферизации медленный клиент удерживает worker приложения занятым на все время загрузки, поэтому несколько медленных отправителей могут занять все доступные worker, и запросы от корректных клиентов начнут завершаться по таймауту.

Обновления выполняются просто:

docker compose pull
docker compose stop
docker compose up -d

Миграции базы данных запускаются автоматически при старте. В любом случае сначала сделайте дамп, так как автоматическая миграция остается миграцией.

Bugsink: один контейнер и лицензия, которую необходимо прочитать

Bugsink — самый легковесный инструмент из трёх представленных. Он поддерживает протокол Sentry SDK и работает без очереди сообщений, не требуя внешних сервисов, кроме базы данных. По умолчанию используется SQLite, но при росте нагрузки поддерживаются MySQL и PostgreSQL.

Временный экземпляр для ознакомления с интерфейсом перед внедрением:

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Откройте http://localhost:8000/ и войдите, используя адрес и пароль, переданные в CREATE_SUPERUSER. Этот контейнер не сохраняет данные после остановки. Для полноценного развертывания используйте пример compose из репозитория проекта, который объединяет bugsink/bugsink:2 с postgres:17-alpine и задает DATABASE_URL, BASE_URL и BEHIND_HTTPS_PROXY. Сгенерируйте секретный ключ корректно:

openssl rand -base64 50

Параметр BASE_URL должен соответствовать URL, который реально используют ваши пользователи и SDK, включая схему. Если оставить значение http://localhost:8000 на сервере, доступном по адресу https://errors.example.com, то все ссылки в уведомлениях по электронной почте будут указывать на хост, который не разрешается у получателя. Установите BEHIND_HTTPS_PROXY в значение true, если Nginx или Caddy выполняют TLS termination (завершение TLS) перед Bugsink. В противном случае Bugsink будет формировать URL с http:// за вашим прокси https://, и браузеры заблокируют смешанный контент (mixed content).

Разработчик публикует показатели производительности: 18 событий в секунду при размере каждого в 50 KB, что составляет 1,5 миллиона событий в день на VPS с 2 vCPU и 4 GB RAM. Воспринимайте это как ориентир возможностей инструмента, а не как гарантию для вашей нагрузки. Эти данные показывают, что предел производительности значительно выше того, что генерирует одно небольшое приложение.

Теперь о лицензии: это та часть, которую нужно прочитать до внедрения в стек. Bugsink распространяется по лицензии PolyForm Shield License 1.0.0. Это модель source available, а не open source: вы можете запускать и модифицировать код, но не имеете права использовать его для создания конкурирующего продукта. Для внутреннего трекера ошибок это ограничение не является препятствием. Если ваша компания занимается продажей инструментов для разработчиков, сначала дайте юристам ознакомиться с текстом лицензии.

Отслеживание ошибок и наблюдаемость LLM остаются двумя разными инструментами

Попробуйте найти один инструмент, который одновременно выполняет отслеживание ошибок и обеспечивает наблюдаемость больших языковых моделей (LLM), и вы обнаружите продукты, заявляющие о поддержке обоих направлений. Структуры данных в этих задачах различаются, поэтому их объединение до сих пор не произошло. Система отслеживания ошибок получает исключение со стеком вызовов (stack trace), вычисляет по нему отпечаток (fingerprint) и сводит тысячи вхождений в одну проблему со счетчиком. Инструмент трассировки LLM получает span, содержащий промпт, ответ, количество токенов и задержку, и он обязан сохранять каждый из них, так как два вызова с идентичными входными данными — это отдельные события, требующие анализа.

Поэтому используйте оба решения. Отправляйте исключения в систему отслеживания ошибок, а вызовы моделей — в специализированные инструменты: self-hosted Langfuse для трассировки агентов закрывает эту часть, а self-hosted AI observability подходит к той же задаче с другой стороны. Ваше приложение уже генерирует оба типа сбоев. Вызов модели, который возвращает уверенный, но бессмысленный ответ, не вызывает исключения, поэтому система отслеживания ошибок никогда его не зафиксирует.

Рост объема данных на диске — это проблема, которая проявится позже

Любая система отслеживания ошибок — это база данных с интенсивной записью и неограниченным входящим потоком. Ваше приложение само определяет объем записи, и одна новая ошибка в часто вызываемом участке кода может привести к генерации миллиона событий за ночь.

GlitchTip приводит цифру, на которую стоит ориентироваться при планировании: инстансу, обрабатывающему один миллион событий в месяц, может потребоваться 30 GB дискового пространства. Этот объем покрывает один месяц приема данных при такой нагрузке, а период хранения определяет, сколько месяцев вы будете хранить одновременно.

Bugsink подходит к этому с другой стороны. Вместо фиксированной квоты он применяет алгоритм хранения, основанный на количестве и возрасте событий, и предоставляет прямые настройки ограничений: MAX_RETENTION_EVENT_COUNT для всей установки, MAX_RETENTION_PER_PROJECT_EVENT_COUNT для каждого проекта и MAX_EVENT_AGE_DAYS в качестве абсолютного предела. Установка бюджета событий для всей инсталляции — это честный способ рассчитать размер диска, так как этот бюджет и есть сам диск.

Следите за реальными показателями на сервере:

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v выводит размеры данных по томам, что позволяет увидеть, какой именно сервис разрастается. Если объем тома увеличивается на несколько гигабайт в неделю при неизменном трафике, это обычно означает, что политика хранения не была настроена, поэтому данные не удаляются, и единственным ограничением остается размер раздела.

Память — это та же проблема, но в другом обличье. Стек без ограничений заберет всё, что предложит ядро, и когда ресурсы закончатся, OOM killer выберет самый крупный процесс. Вполне вероятно, что это будет ваш веб-сервер, а не трекер, который вызвал нехватку памяти. Установите для каждого сервиса верхний предел: лимиты памяти в Docker Compose показывает синтаксис и поведение контейнера при достижении лимита. Контейнер, завершенный по собственному лимиту, — это локализованный сбой. Контейнер, завершенный ядром, может потянуть за собой соседние процессы.

Какой стек подходит для какого VPS

• 1 GB или 2 GB с запасом: GlitchTip в режиме all-in-one с отключенным Valkey или Bugsink на SQLite. Оба варианта комфортно работают здесь для небольшого количества приложений.
• 4 GB: Bugsink с PostgreSQL или GlitchTip с включенным Valkey и отдельным worker-сервисом. Это тот объем памяти, при котором можно прекратить оптимизацию и просто запустить систему.
• 8 GB: всё еще недостаточно для официального стека Sentry. Потратьте этот ресурс на увеличение периода хранения данных и больший объем диска для выбранного вами облегченного варианта.
• минимум 16 GB, рекомендуется 32 GB: официальный self-hosted стек Sentry, и только в том случае, если вам нужна функция Sentry, которую не поддерживают более легкие проекты. Сначала сверьте нужную функцию с документацией каждого проекта, так как совместимые решения покрывают большинство стандартных задач.

Что бы вы ни запускали, система отслеживания ошибок не может сообщить о собственной неработоспособности. Настройте проверку с другого сервера: Uptime Kuma, отслеживающий состояние с другого узла оповестит вас о том, что трекер недоступен — именно в этот момент ваше приложение начнет генерировать ошибки, которые никто не будет записывать.

Когда хостинг-план оказывается более выгодным решением

Self-hosting системы отслеживания ошибок оправдан, если этого требуют правила хранения данных или если объем событий настолько велик, что оплата за каждое событие становится невыгодной. В остальных случаях проведите честный расчет. Минимальные требования Sentry — сервер с 16 GB оперативной памяти, 4 ядрами и быстрым диском, а VPS такой конфигурации стоит недешево. Добавьте к этому эксплуатационные расходы: строгое соблюдение порядка обновлений и создание снимков системы перед каждой миграцией несколько раз в год.

GlitchTip и Bugsink полностью меняют этот расчет, так как для них достаточно сервера с 512 MB – 4 GB RAM, а обновление выполняется через docker compose pull. Именно поэтому большинство тех, кто задается этим вопросом, в итоге выбирают один из совместимых проектов, а не официальный стек. Им нужна система отслеживания ошибок, а не распределенный конвейер обработки данных, требующий постоянного присмотра.

Если вы все еще определяетесь с тем, что именно стоит размещать на сервере, более широкий список сервисов, пригодных для self-hosting поможет сопоставить систему отслеживания ошибок с другими сервисами, претендующими на тот же объем оперативной памяти.

FAQ

Можно ли разместить Sentry на VPS с 2 ГБ ОЗУ?

Нет. В документации к self-hosted версии Sentry указаны минимальные требования: 4 ядра CPU, 16 ГБ ОЗУ, 16 ГБ swap и 20 ГБ свободного места на диске. Стек одновременно запускает Postgres, ClickHouse, Kafka, Redis и несколько рабочих процессов, поэтому на слабом сервере ядро завершает контейнеры до окончания установки. Проверьте это с помощью dmesg -T | grep -i 'out of memory': команда выведет строку с названием завершённого процесса. Для VPS с 2 ГБ ОЗУ используйте GlitchTip, для которого заявлено 512 МБ, или Bugsink, который работает как один контейнер на SQLite.

Нужно ли менять код приложения для перехода с Sentry на GlitchTip или Bugsink?

Нет. Оба решения принимают события от open source SDK для Sentry. Вы можете оставить уже установленный SDK и изменить только одно значение: DSN — URL, на который SDK отправляет события. Если DSN зашит в код, вынесите его в переменную окружения, укажите новый хост, вызовите тестовое исключение и убедитесь, что оно пришло. Если событие не появилось, проверьте, что идентификатор проекта в DSN соответствует проекту на новом сервере, и что сетевой экран разрешает приложению доступ к этому хосту и порту.

Сколько дискового пространства нужно для self-hosted системы отслеживания ошибок?

Это зависит от объёма событий и периода хранения данных, а не от самого инструмента. GlitchTip указывает 30 ГБ для инстанса, обрабатывающего один миллион событий в месяц. Bugsink позволяет задать бюджет напрямую через MAX_RETENTION_EVENT_COUNT и MAX_EVENT_AGE_DAYS: вы выбираете лимит, а требования к диску определяются им. Настройте период хранения данных в первый же день. Трекер без политики хранения будет расти, пока df -h не покажет 100% заполнения; в этот момент приём данных остановится, и вы потеряете ошибки, которые важнее всего было увидеть.

Почему обновление self-hosted Sentry постоянно завершается ошибкой?

Потому что при обновлении были пропущены обязательные промежуточные версии. В Sentry self-hosted определены конкретные версии с миграциями базы данных, через которые необходимо пройти последовательно. По состоянию на август 2026 года это: 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 и 26.7.0. Прямой переход со старого релиза на самый новый пропускает эти миграции, из-за чего схема базы данных и код перестают соответствовать друг другу, и процесс обновления прерывается. Выполняйте обновление через каждую промежуточную версию, запускайте ./install.sh на каждом этапе, делайте снапшот сервера перед началом и ознакомьтесь с документацией по релизам, которых следует избегать (включая 23.7.0, 25.9.0 и 25.12.0).