Альтернативи Sentry для self-hosted error tracking

Вартість self-hosted error tracking до збереження першої події

У self-hosted error tracking є один параметр, який визначає весь вибір, — мінімальний обсяг RAM. Власна документація Sentry для self-hosted розгортання вимагає 4 CPU cores, 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 ГБ для Sentry — це документований мінімум, а на тій самій сторінці рекомендовано 32 ГБ. 0.5 ГБ для GlitchTip — це рекомендація; проєкт зазначає, що робочий мінімум становить 256 МБ або 128 МБ зі swap за умови ретельного налаштування. 4 ГБ для Bugsink — не одне й не друге: це конфігурація сервера, яку постачальник використав для власного тесту пропускної здатності. Опублікований показник — це відправна точка, а не гарантія для вашого обсягу подій.

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

Офіційний стек — це getsentry/self-hosted, проєкт Docker Compose, який запускає ті самі компоненти, що й Sentry у production. У власній документації його описано як «повністю функціональний і упакований для розгортань із невеликим навантаженням та перевірки концепції». Це чесний підсумок. Ви отримуєте всі функції та всі компоненти, необхідні для їхньої роботи.

Встановлюйте tagged release, а не 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, а також кілька worker- і cron-процесів. Порахуйте їх один раз, оскільки це і є ваше навантаження з обслуговування. Кожен запис відповідає процесу, який може аварійно завершитися, заповнити диск або не виконати міграцію.

Якщо сервіс перебуває у стані Restarting, спочатку перевірте пам’ять:

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

Рядок на кшталт Out of memory: Killed process 3412 (java) означає, що kernel OOM killer (out of memory killer) завершив контейнер, оскільки на сервері закінчилася RAM. Тому цей сервіс не переходить у стан healthy, а стек не завершує запуск. Це звичайний результат запуску повного стека за мінімальних вимог, указаних у документації. У документації також зазначено важливість швидкості диска: значення iowait понад 10% означає, що машина не встигає обробляти pipeline ingest. Перегляньте його у стовпці wa в top або у iostat -x 5, якщо у вас установлено sysstat.

Оновлення — це частина, яку часто недооцінюють

Sentry self-hosted випускає оновлення щомісяця за CalVer, схемою версій, заснованою на календарі. Основний реліз виходить 15-го числа кожного місяця. Не можна перейти зі старої версії безпосередньо на найновішу. Проєкт визначає обов’язкові проміжні версії, і для застосування міграцій бази даних потрібно послідовно перейти на кожну з них. Станом на August 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.

Оновлення складається з checkout і повторного запуску інсталятора:

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, а не open source, схвалений OSI: ви можете запускати його для власних потреб, але не можете продавати його як конкурувальний сервіс. Кожен реліз переходить на Apache 2.0 через два роки після випуску.

GlitchTip: відповідь для 512 MB

GlitchTip має ліцензію MIT і приймає події від open source SDK Sentry, тому інструментований застосунок можна перенести, змінивши одне значення: DSN (ім’я джерела даних, 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_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:// на початку посилання в alert-листах формуються неправильно й ведуть на URL, який не відповідає.

Запустіть сервіс і стежте за першим запуском:

docker compose up -d
docker compose logs -f web

Станом на August 2026 у прикладі використовуються теги образів postgres:18, valkey/valkey:9 і glitchtip/glitchtip:6. Не змінюйте їх на плаваючі теги. Compose-файл зі значенням latest оновить database engine під час наступного docker compose pull, а перехід на нову major-версію Postgres у запущеному інстансі може призвести до того, що робочий error tracker перестане запускатися.

Щоб працювати в діапазоні від 256 MB до 512 MB, скористайтеся коментарями у файлі прикладу. Вони вказують, що вимкнути спочатку: Valkey, а також необов’язкові функції журналювання й перевірки доступності. Без Valkey GlitchTip використовує базу даних для кешу та черги. Це повільніше, але працює коректно. Режим All in one запускає worker у web-процесі, тому потрібно підтримувати один application container замість двох.

Розмістіть proxy перед GlitchTip. Документація GlitchTip рекомендує proxy або load balancer, який буферизує запити й обробляє chunked Transfer-Encoding. Як приклад конфігурації наведено nginx. Без буферизації повільний клієнт утримує application worker протягом усього завантаження. Тому кілька повільних відправників можуть зайняти всі доступні worker, після чого нормальні клієнти почнуть отримувати тайм-аути.

Оновлення — найпростіша частина:

docker compose pull
docker compose stop
docker compose up -d

Міграції бази даних запускаються автоматично під час старту. Але все одно спочатку створіть дамп, оскільки автоматична міграція залишається міграцією.

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

Bugsink — найлегший із трьох варіантів. Він підтримує протокол Sentry SDK і працює без черги повідомлень та зовнішніх сервісів, крім бази даних. За замовчуванням використовується SQLite. MySQL і PostgreSQL також підтримуються, коли можливостей SQLite вже недостатньо.

Тимчасовий екземпляр для перевірки інтерфейсу перед розгортанням:

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, включно зі схемою. Якщо сервер доступний за https://errors.example.com, не залишайте значення http://localhost:8000: кожне посилання в email-сповіщенні вестиме на хост, який не визначається у користувача. Якщо nginx або Caddy завершує TLS (transport layer security) перед Bugsink, задайте BEHIND_HTTPS_PROXY значення true. Інакше Bugsink формуватиме URL http:// за вашим https:// проксі, а браузери блокуватимуть змішаний вміст.

Постачальник наводить власні показники пропускної здатності: 18 подій на секунду по 50 KB кожна, тобто 1.5 мільйона подій на добу, на VPS із 2 vCPU і 4 GB RAM. Сприймайте це як орієнтир можливостей інструмента, а не як гарантію для вашого навантаження. Водночас ці дані показують, що гранична продуктивність значно вища за навантаження, яке створює один невеликий застосунок.

Тепер про ліцензію. Її потрібно прочитати до того, як Bugsink з’явиться у вашому стеку. Bugsink поширюється за ліцензією PolyForm Shield License 1.0.0. Це доступний для перегляду вихідний код, а не open source: ви можете запускати програму та змінювати її, але не можете використовувати її для створення продукту, що конкурує з Bugsink. Для внутрішнього трекера помилок це обмеження зазвичай не має значення. Якщо ваша компанія продає інструменти для розробників, спочатку доручіть комусь перевірити текст ліцензії.

Відстеження помилок і спостережуваність LLM — це досі два окремі інструменти

Якщо шукати один інструмент, який одночасно виконує відстеження помилок і спостережуваність великих мовних моделей (LLM), можна знайти продукти, що заявляють про підтримку обох функцій. Форми даних відрізняються, тому об’єднання досі не відбулося. Система відстеження помилок отримує виняток зі stack trace, обчислює на його основі fingerprint і об’єднує тисячі входжень в одну проблему з лічильником. Інструмент трасування LLM отримує span із prompt, відповіддю, кількістю токенів і latency. Він має зберігати кожен такий запис, оскільки два виклики з однаковими вхідними даними все одно є окремими подіями, які варто переглянути.

Тому використовуйте обидва інструменти. Надсилайте винятки до системи відстеження помилок, а виклики моделей — у систему, призначену для них: self-hosted Langfuse для трасування агентів охоплює цей бік, а self-hosted спостережуваність AI розв’язує те саме завдання з іншого підходу. Ваш застосунок уже генерує обидва типи збоїв. Виклик моделі, який повертає впевнено сформульовану нісенітницю, взагалі не створює винятку, тому система відстеження помилок ніколи його вам не покаже.

Зростання диска — це збій, який проявиться згодом

Кожен трекер помилок — це база даних із високою інтенсивністю запису та необмеженим вхідним потоком. Застосунок визначає обсяг даних, які він записує. Одна нова помилка в часто виконуваній ділянці коду може за ніч створити мільйон подій.

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 у монолітному режимі з вимкненим Valkey або Bugsink на SQLite. Обидва варіанти добре підходять для кількох застосунків.
• 4 GB: Bugsink із PostgreSQL або GlitchTip з увімкненим Valkey і окремим worker service. Це обсяг, за якого вже не потрібно оптимізувати кожен мегабайт.
• 8 GB: цього все ще недостатньо для офіційного стека Sentry. Краще використати цей ресурс для довшого періоду зберігання даних і більшого диска для вибраного легкого варіанта.
• Мінімум 16 GB, рекомендовано 32 GB: офіційний self-hosted стек Sentry. Використовуйте його лише тоді, коли потрібна функція Sentry, якої немає в легших проєктах. Спочатку перевірте потрібну функцію в документації кожного проєкту, оскільки сумісні проєкти підтримують типові функції.

Який би варіант ви не запустили, трекер помилок не може повідомити про власну відмову. Налаштуйте перевірку з іншої машини: Uptime Kuma, що працює з іншого сервера, повідомить, що трекер недоступний. Саме в цей момент ваш застосунок може почати генерувати помилки, які ніхто не записує.

Коли тариф із хостингом є вигіднішим варіантом

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

GlitchTip і Bugsink повністю змінюють цю математику, оскільки 512 MB–4 GB — це недорогий сервер, а оновлення виконується за docker compose pull. Тому більшість людей, які ставлять це запитання, зрештою обирають один із сумісних проєктів, а не офіційний стек. Їм потрібна система відстеження помилок, а не розподілений конвеєр обробки даних, за яким потрібно постійно стежити.

Якщо ви ще визначаєте, що взагалі має працювати на сервері, ширший список того, що варто розгортати у власній інфраструктурі розглядає систему відстеження помилок разом з іншими сервісами, які конкурують за ту саму RAM.

FAQ

Чи можна розгорнути Sentry на VPS із 2 GB RAM?

Ні. В офіційній документації Sentry для self-hosted-розгортання вказано мінімальні вимоги: 4 ядра CPU, 16 GB RAM, додатково 16 GB swap і 20 GB вільного дискового простору. Стек одночасно запускає Postgres, ClickHouse, Kafka, Redis і кілька worker-процесів. Тому на невеликому сервері kernel завершує роботу контейнерів ще до завершення інсталяції. Це можна підтвердити за допомогою dmesg -T | grep -i 'out of memory'. Команда виводить рядок із назвою завершеного процесу. Для VPS із 2 GB RAM використовуйте GlitchTip, для якого задокументовано вимогу 512 MB, або Bugsink, що працює як один контейнер із SQLite.

Чи потрібно змінювати код застосунку, щоб перейти із Sentry на GlitchTip або Bugsink?

Ні. Обидва сервіси приймають події від open source SDK Sentry. Тому можна залишити вже встановлений SDK і змінити лише одне значення: DSN, тобто URL, на який SDK надсилає події. Якщо DSN досі жорстко заданий у коді, винесіть його в змінну середовища. Вкажіть адресу нового хоста, потім згенеруйте тестову помилку й перевірте, чи надійшла вона. Якщо подія не з’явилася, перевірте, чи ідентифікатор проєкту в DSN відповідає проєкту на новому сервері, а також чи дозволяє firewall застосунку підключатися до цього хоста та порту.

Скільки дискового простору потребує self-hosted error tracking?

Це залежить від обсягу подій і періоду їх зберігання, а не від самого інструмента. GlitchTip вказує 30 GB для інстансу, який обробляє один мільйон подій на місяць. У Bugsink ліміт можна задати безпосередньо за допомогою MAX_RETENTION_EVENT_COUNT і MAX_EVENT_AGE_DAYS. Ви самі визначаєте максимальний обсяг, а вимога до дискового простору залежить від нього. Налаштуйте retention у перший день. Трекер без політики retention зростатиме, доки df -h не покаже 100%. Після цього приймання подій зупиниться, і ви втратите помилки, які найважливіше було побачити.

Чому оновлення self-hosted Sentry постійно завершується помилкою?

Тому що під час оновлення було пропущено обов’язкову проміжну версію. Self-hosted Sentry визначає конкретні версії, які містять міграції бази даних і через які потрібно пройти. Станом на August 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. Якщо перейти безпосередньо зі старого release на найновіший, ці міграції буде пропущено. Через це схема бази даних і код не відповідатимуть один одному, а оновлення зупиниться на півдорозі. Послідовно встановіть кожну обов’язкову проміжну версію та виконайте ./install.sh на кожній із них. Перед початком створіть snapshot сервера. Також ознайомтеся із задокументованим списком release, яких слід уникати. До нього входять 23.7.0, 25.9.0 і 25.12.0.