Свой Sentry вместо платного тарифа: во сколько обходится одна ошибка

MAATRIX

Счёт за Sentry растёт вместе с тем, как ваше приложение падает чаще — это неприятная особенность биллинга по событиям: чем хуже здоровье продукта или чем активнее вы логируете, тем больше платите. В какой-то момент хочется понять не абстрактное «дорого», а конкретное число — сколько стоит одна отслеженная ошибка. Ниже — методика этого расчёта для платного тарифа и для self-hosted Sentry на своём сервере, с честным разбором, когда самостоятельный хостинг реально экономит, а когда только добавляет работы.

Как считать цену одной ошибки

Sentry — открытая платформа отслеживания ошибок и производительности приложений с self-hosted версией, и именно это делает сравнение осмысленным: вы не сравниваете разные продукты, а сравниваете две модели владения одним и тем же инструментом. У платного SaaS-тарифа Sentry биллинг построен вокруг числа отслеживаемых событий в месяц — error events, к которым в некоторых тарифах добавляются performance-транзакции, replay-сессии и cron-мониторинг как отдельные единицы учёта. Base-метрика для нашего расчёта простая:

цена_ошибки = стоимость_за_период / число_ошибок_за_тот_же_период

Здесь важны три методических нюанса, без которых число получится бессмысленным.

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

Во-вторых, считайте именно события (events), а не «issues». Sentry дедуплицирует похожие ошибки в один issue, но тарифицирует по числу событий — то есть по числу фактических срабатываний, даже если это один и тот же баг, упавший тысячу раз за час. Число событий смотрите в Stats/Usage в самом Sentry, не в списке issues.

В-третьих, для платного тарифа интереснее не средняя цена события за месяц, а предельная (маржинальная) — сколько стоит следующее событие сверх уже оплаченного лимита. Именно предельная цена определяет, что произойдёт со счётом, если в проде случится инцидент и число ошибок вырастет в разы за одну ночь.

Для self-hosted логика зеркальная: в числителе — не абонплата, а совокупная стоимость владения сервером за месяц (аренда/амортизация железа, диск под retention, время администратора, если вы готовы его учитывать деньгами). В знаменателе — то же число событий. Разница в том, что у self-hosted эта стоимость в первом приближении фиксирована и не зависит от объёма — а у платного тарифа она явно от объёма зависит, ступенями.

Платный тариф: иллюстративный расчёт

Точные актуальные цены Sentry (и любого другого SaaS с error tracking) здесь сознательно не привожу — тарифные планы и лимиты меняются, и любое число из статьи устареет быстрее, чем вы её дочитаете. Вместо этого — модель на условных переменных, которую вы подставите под свой тариф на день расчёта.

Обозначим:

• B — базовая стоимость подписки в месяц (₽ или $), в которую включён лимит N0 событий;
• O — цена доплаты за дополнительную тысячу событий сверх N0 (overage rate);
• N — реальное число ошибок за месяц.

Тогда стоимость месяца:

если N <= N0:  Cost = B
если N > N0:   Cost = B + O * ceil((N - N0) / 1000)

А цена одной ошибки:

цена_ошибки = Cost / N

Характерная форма этой функции — не плавная кривая, а пилообразная. Пока N растёт в пределах включённого лимита N0, цена ошибки падает почти до нуля (вы платите одну и ту же B за всё больше событий). Как только вы упираетесь в лимит и переходите на overage, цена ошибки скачком подрастает — потому что каждая следующая тысяча событий уже не бесплатна, а стоит O. Дальше внутри одной тарифной ступени она снова плавно снижается, пока не наступит следующий тариф-порог или новая доплата.

Условный пример на округлённых цифрах (не берите их как актуальные цены — только как иллюстрацию формы кривой):

Вывод из формы кривой, а не из конкретных цифр: у платного тарифа цена ошибки никогда не стремится к нулю — она колеблется около какого-то плато, потому что провайдер закладывает маржу в каждую дополнительную тысячу событий. Это нормально — вы платите за то, что не администрируете инфраструктуру. Но это значит, что рост числа ошибок (например, из-за деградации качества кода или роста трафика) почти линейно тянет за собой рост счёта.

Если хотите заранее прикинуть свою предельную цену события, не гадайте — откройте текущий прайс-лист Sentry (или другого используемого SaaS) на странице тарифов и посчитайте O по факту на день расчёта; здесь эта переменная умышленно оставлена открытой.

Self-hosted Sentry: из чего складывается стоимость

Self-hosted Sentry — это не «один контейнер», а небольшой кластер сервисов: Postgres для метаданных, Clickhouse и Kafka для хранения и обработки событий (в современных версиях), Redis для очередей, Relay как приёмник событий, плюс воркеры обработки (symbolication, ingest, post-process) и веб-фронтенд. Официальный install.sh разворачивает это через docker-compose, и старт «в лоб» на слабом VPS обычно заканчивается тем, что Clickhouse или Kafka не проходят health-check по нехватке памяти.

Реалистичная отправная точка для небольшой команды — сервер с 4 vCPU и от 8–16 ГБ RAM, с оговоркой, что фактическая потребность сильно зависит от retention (сколько дней хранить события) и от пиковой нагрузки на ingest. Подробный разбор по памяти под разные объёмы событий — в отдельном материале: сколько RAM нужно для Sentry self-hosted. Пошаговую установку из official docker-compose стека смотрите в инструкции по установке self-hosted Sentry на VPS — там же разобраны типичные ошибки первого запуска.

Компоненты стоимости владения на своём сервере:

• Аренда/амортизация сервера — фиксированная сумма в месяц, не зависящая от числа событий (в разумных пределах, до упора в ресурсы).
• Диск под retention — Clickhouse хранит сырые события, и при большом объёме и долгом сроке хранения диск растёт быстрее, чем кажется на старте; закладывайте SSD с запасом или отдельный volume под данные.
• Обновления — Sentry self-hosted выпускает новые версии часто, и разработчики явно не гарантируют обратной совместимости между сильно разошедшимися версиями: апгрейд «через одну» может потребовать промежуточных шагов. Это лучше закладывать как регулярную (хоть и не еженедельную) задачу, а не разовую настройку «поставил и забыл».
• Резервное копирование — Postgres и Clickhouse нужно бэкапить отдельно; готового единого «экспорта одной кнопкой» в self-hosted версии нет из коробки.
• Время администратора — если считаете экономику для бизнеса, а не для себя одного, честно оцените часы в деньгах: даже 2–3 часа в месяц на обновления и присмотр за диском — это реальные затраты, просто не в виде счёта от провайдера.

Цена ошибки на self-hosted: расчёт

Здесь методика проще, потому что знаменатель растёт, а числитель — почти нет:

цена_ошибки_self = (стоимость_сервера_в_месяц + амортизация_админ_времени) / N

Ключевое отличие от платного тарифа: стоимость_сервера_в_месяц в первом приближении константа (пока вы не упёрлись в ресурсы и не пришлось расширять сервер). Значит, при росте N цена ошибки падает гиперболически — стремится к нулю, но никогда его не достигает, потому что фиксированная стоимость сервера никуда не девается.

Условный иллюстративный расчёт при фиксированной стоимости сервера S ₽/мес (подставьте свою цену VPS с нужным объёмом RAM/диска):

Форма этой кривой — монотонно убывающая гипербола с редкими скачками вверх, когда приходится увеличивать сервер под возросший объём. Это зеркальная противоположность пилообразному графику платного тарифа: там цена ошибки колеблется около плато, здесь — асимптотически падает к минимуму, определяемому ценой самого дешёвого сервера, способного тянуть Sentry-стек.

Если хотите добавить в формулу время администратора, оцените его как отдельное слагаемое A = часы_в_месяц × ставка_часа, и не забудьте, что A в первом приближении тоже почти не зависит от N — присмотр за системой с 50 000 и 500 000 событий в месяц отличается по трудозатратам не так драматично, как разница в объёме данных, пока Clickhouse справляется с нагрузкой на выбранном железе.

На каком объёме self-hosted оправдан

Точка перелома — это объём N*, при котором стоимость платного тарифа сравнивается со стоимостью self-hosted:

B + O * ceil((N* - N0) / 1000)  =  S + A

Решать это уравнение с точными цифрами сейчас смысла нет — тарифы SaaS и цены VPS у каждого свои на момент чтения. Но общая логика перелома такая:

• Чем выше объём ошибок стабильно в месяц, тем быстрее фиксированная S self-hosted окупается на фоне растущего по объёму B + O×... у SaaS. Команды с высоким трафиком, активной разработкой (много релизов — много новых багов) и длинным retention обычно первыми упираются в overage у провайдера и тогда всерьёз считают self-hosted.
• Чем предсказуемее нагрузка, тем проще подобрать сервер один раз и не гоняться за масштабированием — рваный трафик с редкими всплесками (например, вирусный рост или DDoS-подобный шторм ошибок при сбое зависимости) требует либо запаса по ресурсам «на всякий случай», либо готовности временно тормозить приём событий через rate limiting в Relay.
• Чем больше в команде людей, готовых сопровождать инфраструктуру, тем ниже эффективная A — если у вас уже есть кто-то, кто администрирует GitLab CI, Grafana Loki и прочий self-hosted стек, добавление Sentry в этот список почти не увеличивает трудозатраты. Похожая логика разбирается в статье про точку перелома для своего GitLab против платных тарифов — принцип общий для любого self-hosted DevOps-инструмента: экономика улучшается не только с объёмом данных, но и с числом систем, которые уже обслуживает одна и та же команда.

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

Когда платный тариф проще

Честно: self-hosted не всегда выигрывает, и вот когда managed-тариф — разумный выбор, а не признание поражения.

• Маленький проект с редкими ошибками. Если у вас 500–5000 событий в месяц, вы почти наверняка укладываетесь в самый дешёвый платный тариф или даже в бесплатный лимит, и цена одной ошибки там уже околонулевая — сравнивать не с чем.
• Нет человека, готового администрировать инфраструктуру. Self-hosted Sentry — это не «поставил и забыл», а система, требующая регулярных обновлений и присмотра за диском Clickhouse. Если такого человека в команде нет, эффективная стоимость A может оказаться выше, чем кажется на бумаге — считайте не только время на установку, но и на разбор инцидентов вида «Sentry сам упал и не шлёт алерты».
• Нужна гарантия SLA и поддержка вендора. На проде с юридическими обязательствами перед клиентами платный тариф с SLA от Sentry снимает риск, который на self-hosted целиком ложится на вас.
• Команда уже перегружена другими self-hosted системами. Экономика self-hosted работает лучше, когда инструмент добавляется к уже существующей DevOps-практике, а не когда он становится первой и единственной системой, которую придётся учиться администрировать с нуля. Смежный разбор такой же развилки — в статье своя аналитика вместо платного тарифа: цена миллиона просмотров, там та же арифметика применена к другому инструменту.

Если сомневаетесь — посчитайте N* по формуле выше на своих реальных цифрах за последние 2–3 месяца (число событий видно в Stats самого Sentry, стоимость тарифа — в биллинге). Если ваш текущий объём заметно ниже N* — оставайтесь на SaaS и пересчитывайте раз в квартал; если выше — self-hosted, скорее всего, уже окупается, и вопрос только в том, готовы ли вы взять на себя администрирование.

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