Sentry пора на покой... Metric готов принять пост.

Self-hosted Sentry — это 65 контейнеров, 16-32 ГБ RAM и выделенный инженер на поддержку. Всё ради того, чтобы ловить стектрейсы. Разбираемся, почему индустрия приняла это как норму, сравниваем альтернативы (GlitchTip, BugSink, Hawk) и знакомимся с Metric.

Каждый, кто хоть раз поднимал 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 - и это я ещё не всё перечислил.

Теперь про железо. Официальные системные требования:

И ласковое примечание: "рекомендуется 32 ГБ". Опытные эксплуатантеры на issue-трекере getsentry/self-hosted согласно кивают: под реальной нагрузкой стабильно жить хочется на 24-32 ГБ, потому что один ClickHouse способен откусить 8-12 ГБ и не моргнуть.

Тридцать два гигабайта оперативной памяти. Чтобы смотреть, почему падает ваш pet-проект.

Для сравнения: на такой машине можно поднять половину микросервисной инфраструктуры среднего стартапа! Но нет - она будет греть 65 контейнеров, чтобы вы могли вовремя узнать про TypeError: undefined is not a function.

А теперь вопрос на миллион (буквально - оценка выручки Sentry исчисляется сотнями миллионов долларов): а случайно ли это?

Смотрите, какая красивая механика:

Возникает крамольная мысль: а не является ли самопальный монстр частью воронки продаж? Идеальным антипрививочным аргументом против 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 плохой" - легко. Вопрос, что предложить взамен. Хорошая новость: альтернативы есть, и они прекрасно доказывают главный тезис этой статьи - для приёма ошибок не нужна инфраструктура уровня малых стран. Плохая новость: у каждой есть свой компромисс.

Разберём достойных.

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 - это Sentry-совместимая система мониторинга, переписанная на Rust с нуля и с одной навязчивой идеей: функциональность не обязана стоить 65 контейнеров.

Миграция выглядит так:

Всё. Это вся миграция. Официальные 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 контейнера). Всё.

Установка:

Одна команда. Без клонирования репозитория, без сборки, без интерактивного инсталлятора на 20 минут. Скрипт сам генерирует пароли, тянет готовый образ и поднимает стек.

А теперь - мой любимый пункт - производительность. Metric не говорит "мы быстрые". Metric коммитит сырые результаты бенчмарков в репозиторий (performance/baselines/), чтобы вы могли проверить и придраться. Референс-машина - обычный ноутбучный Ryzen 5 5600H (6 ядер) с 16 ГБ RAM:

Четыре тысячи девятьсот восемьдесят три долговечно записанных события в секунду - то есть с подтверждением записи в базу, с нулевой потерей подтверждённых событий - на железе, которое у Sentry self-hosted даже не пройдёт проверку инсталлятора. Перечитайте это предложение ещё раз. Ноутбук, который Sentry отверг бы на пороге, обрабатывает поток, эквивалентный сотням миллионов событий в сутки (проектный конверт Metric - ровно 100 млн событий в день, модель расписана в ADR-0037).

И - ключевое отличие от всех альтернатив выше - Metric не режет функциональность:

Это не "подмножество Sentry". Это полный рабочий цикл Sentry - приём, группировка, расследование, алертинг, релизы, мониторинг - в одном бинарнике, который умещается в 320 МБ лимита памяти на минимальном профиле.

Отдельная любовь - к честности в мелочах. У каждого профиля жёсткие потолки памяти, очередей и ретеншена: система не предполагает бесконечное железо, она гарантирует ограниченное поведение. MongoDB получает WiredTiger-кэш ровно 256 МБ, а не "сколько удастся урвать". Логи контейнеров ротируются после двух файлов по 5 МБ. Разработчики Metric явно устали от инфраструктурных сюрпризов - и это очень сильно чувствуется.

Чтобы меня не разорвали в комментариях - скажу сам, честно и заранее:

Мораль этой статьи не "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 ГБ оперативной памяти, но разработчикам будет категорически приятно.