Дисклеймер: статья написана с пристрастием, желчью и таблицами. Автор считает, что инфраструктура должна работать на вас, а не вы на неё. Если вы фанат Sentry — дочитайте до конца, вам будет что предъявить в комментариях.
Акт первый, в котором мы покупаем билет в зоопарк
Каждый, кто хоть раз поднимал self-hosted Sentry, помнит этот момент. Вы клонируете getsentry/self-hosted, запускаете ./install. sh, идёте за кофе. Возвращаетесь, а Docker всё ещё тянет образы. Вы открываете docker-compose. yml и начинается самое интересное: знакомство с семейством.
Вот официальный Compose-файл релиза 26.7.2. В нём 65 (шестьдесят пять) определений сервисов. Шестьдесят пять, Карл! Это не опечатка и не преувеличение ради красного словца — это файл из официального репозитория, откройте и посчитайте сами. Да, часть из них — профили и разовые джобы. Но даже в «боевом» составе там: Sentry web, воркеры (несколько видов!), Relay, Snuba (api + consumer’ы), Kafka, ZooKeeper, ClickHouse, PostgreSQL, Redis, Memcached, Symbolicator, Vroom, cron, и далее по списку, пока глаза не устанут.
Шестьдесят пять сервисов. Чтобы ловить стектрейсы. Нет слов, одни…
Давайте осмыслим. Стектрейс — это текст. JSON-документ размером в несколько килобайт. Человечество научилось принимать JSON по HTTP примерно в 2005 году. А чтобы сохранить этот JSON и показать его в веб-интерфейсе, Sentry предлагает вам поднять брокер сообщений Kafka (с ZooKeeper в комплекте, разумеется), колоночную аналитическую СУБД ClickHouse, отдельную реляционную СУБД PostgreSQL, два разных кэша, прокси-прослойку Relay, Python-воркеры для очередей, отдельный сервис Snuba, который переводит запросы внутреннего API на язык ClickHouse, и профайлер Vroom — и это я ещё не всё перечислил.
Теперь про железо. Официальные системные требования:
4 ядра CPU;
16 ГБ RAM — и это минимум, ниже инсталлятор просто откажется работать;
16 ГБ swap (да, своп размером с RAM - это такая тонкая самоирония);
20 ГБ диска — на старте, дальше ClickHouse решит сам.
И ласковое примечание: “рекомендуется 32 ГБ”. Опытные эксплуатантеры на issue-трекере getsentry/self-hosted согласно кивают: под реальной нагрузкой стабильно жить хочется на 24-32 ГБ, потому что один ClickHouse способен откусить 8-12 ГБ и не моргнуть.
Тридцать два гигабайта оперативной памяти. Чтобы смотреть, почему падает ваш pet-проект.
Для сравнения: на такой машине можно поднять половину микросервисной инфраструктуры среднего стартапа! Но нет — она будет греть 65 контейнеров, чтобы вы могли вовремя узнать про TypeError: undefined is not a function.
Акт второй, в котором автор надевает шапочку из фольги
А теперь вопрос на миллион (буквально — оценка выручки Sentry исчисляется сотнями миллионов долларов): а случайно ли это?
Смотрите, какая красивая механика:
Sentry - отличный продукт. Спору нет. UX эталонный, SDK прекрасные, экосистема огромная. Им искренне хочется пользоваться.
SaaS-версия стоит денег. Цены растут с объёмом событий, и в какой-то момент счёт начинает напоминать аренду небольшой недвижимости.
“Но мы же open-source! — говорит Sentry. — Возьмите self-hosted!” И даёт вам 65-контейнерного левиафана, который требует выделенного инженера, 16+ ГБ RAM и крепчайших нервов.
Через месяц эксплуатации левиафана среднестатистическая команда делает единственно разумный вывод: “Проще заплатить за SaaS”.
Возникает крамольная мысль: а не является ли самопальный монстр частью воронки продаж? Идеальным антипрививочным аргументом против self-hosted, как явления? “Видите, как сложно? А теперь посмотрите на наш тариф Team - всего $26 в месяц, и никакой боли”.
Добавим перцу. Sentry давно не open source в строгом смысле: лицензия у него Functional Source License (FSL 1.1) — “source available”, с запретом конкурировать с облаком Sentry. То есть код вы видеть можете, а вот построить на нём свой разумный сервис — юридически рискованно. Удобно, правда? Окно витринное, стекло бронированное.
И вишенка: в официальном репозитории self-hosted честно написано, что эта сборка предназначена для low-volume deployments и proof of concept. То есть сама компания признаёт: полноценный прод на этом разворачивать не предполагалось. Зачем тогда, спрашивается, 65 контейнеров для «маленького» сценария? Хороший вопрос. Чертовски хороший вопрос.
Хватит ли этого, чтобы объявить заговор? Решать вам в комментариях. Но согласитесь: если бы SaaS-компания хотела сделать self-hosted намеренно неудобным — лучше бы и не придумала.
Акт третий, в котором мы смотрим на альтернативы и почти радуемся
Критикуешь, предлагай! Сказать «Sentry плохой» — легко. Вопрос, что предложить взамен. Хорошая новость: альтернативы есть, и они прекрасно доказывают главный тезис этой статьи — для приёма ошибок не нужна инфраструктура уровня малых стран. Плохая новость: у каждой есть свой компромисс.
Sentry self-hosted | GlitchTip | BugSink | Hawk | Metric | |
|---|---|---|---|---|---|
Язык/стек | Python + весь зоопарк | Django + PostgreSQL (+Redis/Valkey опционально) | Django + PostgreSQL/SQLite | Node.js-микросервисы + MongoDB + Redis | Rust + MongoDB |
Контейнеров из коробки | 65 определений, ~20+ всегда живых | 2-4 | 1-2 | десятки (воркеры, сборщики, API, гараж, нотификатор…) | 2 (Min/Low) - 4 (Medium/High) |
Минимальная машина | 4 CPU / 16 ГБ RAM / 16 ГБ swap | ~512 МБ RAM | от 64-256 МБ | ощутимо больше пары гигабайт | 1 vCPU / 1 ГБ RAM |
Совместимость с Sentry SDK | нативная | часть ingest API | часть ingest API (только ошибки) | нет, свои SDK | полная: меняется только DSN |
Ошибки и группировка | да | да | да | да | да |
Логи (структурированные) | да | нет | нет | нет | да |
Трейсы / транзакции / спаны | да | частично | нет | нет | да |
Релизы и release health | да | частично | нет | нет | да |
Cron-мониторинг | да | нет | нет | нет | да |
Аптайм-мониторы | да | да | нет | нет | да |
Метрики приложений и дашборды | да | нет | нет | нет | да |
Session Replay | да | нет | нет | нет | да (включается на проект) |
User Feedback | да | частично | нет | нет | да |
Source maps / debug files | да | частично | да (source maps) | нет | да |
Алерты (email/Telegram/webhook) | да | email/webhook | да | да | да |
Разберём достойных.
GlitchTip - замечательный проект. Django, PostgreSQL, стартует на половине гигабайта, умеет ошибки, аптайм, частично транзакции. Но это именно что “упрощённый Sentry”: ни структурированных логов, ни Session Replay, ни cron-мониторинга, ни метрик приложений с дашбордами. Команда GlitchTip сама честно говорит: мы реализуем подмножество Sentry API. Если вам нужны только ошибки — отличный выбор. Если вы привыкли к Sentry целиком — будете постоянно натыкаться на стены.
BugSink — ещё более радикальный минимализм: ловит ошибки, красиво их показывает, живёт в одном контейнере и даже гордится, что игнорирует всё, кроме ошибок — ни перформанса, ни реплеев. Философия уважаемая, но это ответ на вопрос “чем заменить папку с логами”, а не “чем заменить Sentry”.
Hawk — наш, отечественный, от CodeX. Милый интерфейс, живая команда. Но: собственные SDK (то есть миграция с Sentry — это переписывание интеграции), и архитектура в духе “микросервисы ради микросервисов”: API, отдельные воркеры-сборщики под каждый язык, MongoDB, Redis и длинный Compose-файл. По духу это скорее младший брат того самого монстра, чем его противоядие.
Видите закономерность? Все альтернативы либо режут функциональность (GlitchTip, BugSink), либо ломают совместимость (Hawk), либо делают и то и другое. Сменить DSN и потерять половину привычного Sentry — так себе сделка.
Акт четвёртый, в котором на сцену выходит Metric
А теперь — то, ради чего всё затевалось.
Metric — это Sentry-совместимая система мониторинга, переписанная на Rust с нуля и с одной навязчивой идеей: функциональность не обязана стоить 65 контейнеров.
Миграция выглядит так:
Sentry.init({ dsn: "http://<key>@your-metric-host:4001/<project_id>" });
Всё. Это вся миграция. Официальные Sentry SDK продолжают работать как ни в чём не бывало — потому что Metric говорит на родном протоколе Sentry: энвелопы, сторы, релизы, сессии, чек-ины, replay-записи. Совместимость подтверждается не словами, а релизными тестами: реальные процессы @sentry/browser и @sentry/node 10.66.0, sentry-sdk (Python) 2.32.0, sentry-java 8.50.1, Sentry для .NET 6.7.0, sentry-go 0.48.0, sentry для Rust 0.48.5 и даже sentry-cli 3.6.2/2.58.6 для загрузки source maps и debug-файлов - всё это гоняется против Metric перед каждым релизом, и платформа объявляется поддерживаемой только после зелёного теста.
Теперь про железо. Минимальный профиль Metric:
1 vCPU, 1 ГБ RAM, 15 ГБ SSD.
Не опечатка. Один гигабайт. Это дешевле кофейной подписки на любом VPS-хостинге планеты. Профиль “Medium” (4 vCPU / 8 ГБ) — это уже полноценный сервер с Symbolicator’ом и символикацией нативных и JS-стектрейсов. Состав стека: один бинарник на Rust + MongoDB (2 контейнера), в старших профилях добавляется Symbolicator с уборщиком кэша (4 контейнера). Всё.
Установка:
curl -fsSL https://raw.githubusercontent.com/biosshot/metric/v0.1.5/deploy/install.sh | sh
Одна команда. Без клонирования репозитория, без сборки, без интерактивного инсталлятора на 20 минут. Скрипт сам генерирует пароли, тянет готовый образ и поднимает стек.
А теперь мой любимый пункт — производительность. Metric не говорит «мы быстрые». Metric коммитит сырые результаты бенчмарков в репозиторий (performance/baselines/), чтобы вы могли проверить и придраться. Референс-машина — обычный ноутбучный Ryzen 5 5600H (6 ядер) с 16 ГБ RAM:
Нагрузка | Результат | Латентность |
|---|---|---|
Долговечный приём ошибок, цель 5000/с | 4 983 события/с | p95 = 27,7 мс |
Замер насыщения, цель 20 000/с | 7 307 долговечных событий/с | p95 = 296,8 мс |
HTTP-конвейер (парсинг/auth/скраббинг) | 2 500 запросов/с | p99 = 0,62 мс |
Запись спанов в MongoDB | 32 639 спанов/с | - |
Четыре тысячи девятьсот восемьдесят три долговечно записанных события в секунду — то есть с подтверждением записи в базу, с нулевой потерей подтверждённых событий — на железе, которое у Sentry self-hosted даже не пройдёт проверку инсталлятора. Перечитайте это предложение ещё раз. Ноутбук, который Sentry отверг бы на пороге, обрабатывает поток, эквивалентный сотням миллионов событий в сутки (проектный конверт Metric — ровно 100 млн событий в день, модель расписана в ADR-0037).
И — ключевое отличие от всех альтернатив выше — Metric не режет функциональность:
— ошибки, группировка в ишью, поиск, таймлайны, тренды; — структурированные логи, транзакции, спаны, трейс-вью; — метрики приложений (counters, gauges, distributions), дашборды, сохранённые поиски; — релизы, деплои, release health, сессии; — cron-мониторинг и активные HTTP-аптайм-мониторы; — Session Replay, user feedback со скриншотами, вложения; — алерты в email, Telegram и подписанные вебхуки с историей ретраев; — source maps и debug-файлы через sentry-cli, символикация через Symbolicator; — скраббинг/псевдонимизация персональных данных до записи в хранилище — по умолчанию, а не галочкой в настройках; — единый язык запросов по всем сущностям, экспорт в JSON/CSV; — веб-интерфейс на русском и английском (привет, Хабр).
Это не «подмножество Sentry». Это полный рабочий цикл Sentry — приём, группировка, расследование, алертинг, релизы, мониторинг — в одном бинарнике, который умещается в 320 МБ лимита памяти на минимальном профиле.
Отдельная любовь — к честности в мелочах. У каждого профиля жёсткие потолки памяти, очередей и ретеншена: система не предполагает бесконечное железо, она гарантирует ограниченное поведение. MongoDB получает WiredTiger-кэш ровно 256 МБ, а не «сколько удастся урвать». Логи контейнеров ротируются после двух файлов по 5 МБ. Разработчики Metric явно устали от инфраструктурных сюрпризов — и это очень сильно чувствуется.
Акт пятый, в котором автор снимает шапочку из фольги
Чтобы меня не разорвали в комментариях — скажу сам, честно и заранее:
— Metric — релиз 0.1.5, ранний. Профайлинга нет, SSO/SCIM/MFA нет, часть платформ (Apple/Cocoa, Flutter, Android, PHP, Ruby, React Native) пока вне релизных тестов. Шардинга и HA нет — это сознательно однонодовая система. Авторы не прячут это в мелком шрифте: есть целая страница known limits. — 65 сервисов Sentry — не все одновременно живые: там есть профили и разовые джобы. Но 20+ постоянно работающих контейнеров — это всё равно в 5-10 раз больше, чем у Metric при сопоставимой для большинства команд задаче. — Теория заговора из второго акта — это теория. Возможно, Sentry просто вырос исторически: Python-монолит оброс очередями, потом появился ClickHouse под аналитику, потом Relay под приём, потом Snuba, потом… Но знаете что? Результат неотличим от заговора. И платите за этот результат — вы.
Финал
Мораль этой статьи не «Sentry плохой». Мораль вот в чём:
Индустрия приняла как норму, что приём телеметрии стоит 16-32 ГБ RAM и зоопарк из шести десятков сервисов. Это не норма. Это привычка, которую кому-то очень выгодно поддерживать.
GlitchTip и BugSink доказали: на сотни мегабайт можно ловить ошибки. Metric доказал следующий шаг: на одном гигабайте и двух контейнерах можно иметь весь Sentry-воркфлоу — логи, трейсы, метрики, релизы, мониторы, реплеи, алерты — с полной SDK-совместимостью и производительностью, за которую не стыдно перед бенчмарком в открытом репозитории.
Если ваш Sentry-счёт за SaaS больше, чем стоимость VPS на 4 ГБ — вы знаете, что делать. Если вы год эксплуатируете self-hosted Sentry и считаете это нормальным — жду вас в комментариях, берите цифры, будем меряться.
Metric: github.com/biosshot/metric · MIT License · ставится одной командой · работает на сервере, на который Sentry отказался бы даже устанавливаться.
Звёздочка на GitHub — это, конечно, не 32 ГБ оперативной памяти, но разработчикам будет категорически приятно.
