Если продакшен живёт дольше пары недель, вы неизбежно приходите к двум вопросам: «почему пользователю стало плохо прямо сейчас» и «когда это повторится». Error tracking закрывает первую часть (исключения, stacktrace, контекст), а performance monitoring — вторую (latency, транзакции, узкие места).
Де-факто стандарт на рынке — Sentry. Его часто берут как «всё в одном», но вместе с возможностями приходит и неочевидная стоимость: деньги, объёмы данных, эксплуатация. В качестве более простого и дешёвого варианта часто смотрят GlitchTip. А кто-то принципиально выбирает self-hosted и собирает стек под себя.
Ниже — сравнение Sentry vs GlitchTip vs self-hosted: функциональность, ограничения, нюансы эксплуатации, стоимость владения, retention и алерты. С прицелом на админов/DevOps и вебмастеров: чтобы система не превращалась в отдельный продукт, требующий постоянного внимания.
Что именно сравниваем: error tracking, performance monitoring и «обвязку»
Чтобы сравнение было честным, важно разложить термины. В реальных командах под «Sentry» (или «сентри-подобной системой») обычно подразумевают сразу несколько подсистем.
Error tracking: исключения, фронтенд-ошибки, дедупликация, группировка, контекст (breadcrumbs), поиск по событиям, релизы.
Performance monitoring (APM/tracing): транзакции и спаны, p95/p99, throughput, медленные запросы, внешние вызовы, N+1 и другие паттерны.
Alerts: уведомления по росту ошибок, деградации latency, регрессии по релизам, «аномалии».
Retention: сколько дней вы храните события/транзакции, как чистите, во что упираетесь по диску/цене.
Интеграции: почта, мессенджеры, issue tracker, CI/CD, релизы, автосоздание задач.
Эксплуатация: обновления, бэкапы, миграции, масштабирование, RBAC/доступы, контроль PII.
Ключевой нюанс: GlitchTip обычно закрывает error tracking заметно лучше, чем полноценный APM. А «self-hosted» — вообще не один продукт, а подход: вы либо ставите готовое решение у себя, либо собираете стек из компонентов (например, вокруг OpenTelemetry).
Sentry: максимум возможностей, максимум «неочевидной» стоимости
Sentry силён тем, что вы получаете почти всё в одном интерфейсе: ошибки, релизы, расследования, базовый APM/tracing. Для разработки это означает «быстро получить пользу» — особенно если стартовать со стандартных SDK и типовых интеграций.
Сильные стороны Sentry
Группировка и контекст: дедупликация, breadcrumbs, теги, фильтрация, привязка к релизам. В быту это экономит больше времени, чем любые красивые графики.
Связка ошибок и производительности: когда trace связан с ошибкой и релизом, расследования действительно ускоряются.
Работа с релизами: health/regressions и быстрый ответ на вопрос «что сломал релиз X».
Гибкие alerts: по ошибкам и по перформансу (детали зависят от тарифа/возможностей инсталляции).
Слабые стороны, которые всплывают в эксплуатации
Retention и объёмы данных: как только включаете performance monitoring и собираете транзакции, объём растёт быстро. Retention становится управляемым ресурсом: либо платите, либо жёстко сэмплируете, либо снижаете детализацию.
Self-hosted Sentry — это проект: установка возможна, но это уже не «поднял контейнер и забыл». Внутри много компонентов (БД, очереди, воркеры, кэш), и стабильность сильно зависит от дисциплины обновлений и мониторинга самой системы.
Шум без гигиены: без фильтров, rate limit и понятных правил вы быстро утонете в событиях. Это нормальная стадия взросления, но её надо закладывать в план внедрения.
Практическое правило: если вы хотите не просто «ловить исключения», а управлять качеством релизов и деградациями, Sentry закрывает больше сценариев «из коробки». Но цена — деньги и/или эксплуатационная сложность.
Если вы размещаете self-hosted инсталляцию, заранее прикиньте ресурсы и отказоустойчивость. Для большинства команд разумный путь — вынести систему мониторинга на отдельный сервер/кластер, чтобы проблемы приложения не «роняли» сбор ошибок.
GlitchTip: проще и предсказуемее, но не про «полный APM»
GlitchTip часто выбирают команды, которым нужен sentry-like интерфейс для ошибок, но без тяжёлого APM-стека. Он закрывает базовый self-hosted error tracking: события, окружения, релизы, оповещения. По ощущениям продукт «легче» и проще в поддержке.
Где GlitchTip выигрывает
Ниже порог входа: для небольших проектов быстрее выходите в состояние «ошибки видим, реагируем, ничего не горит».
Self-hosted без лишнего: чаще меньше компонентов, проще обновления и понятнее требования к ресурсам.
Предсказуемые объёмы: если вы делаете ставку на error tracking без высококардинального tracing, хранение и нагрузка обычно стабильнее.
Ограничения GlitchTip (важные для продакшена)
Performance monitoring не является сильной стороной: для полноценного tracing по сервисам/БД/очередям и внешним API почти всегда понадобится отдельный observability/APM стек.
Меньше «типовых практик»: у Sentry больше готовых материалов, интеграций и примеров. С GlitchTip проще стартовать, но иногда больше решений придётся стандартизировать внутри команды.
Удобный сценарий: GlitchTip как единая точка правды по ошибкам, а метрики и трассировка — отдельным инструментом, где уже настроены SLO/дашборды/Alertmanager.
Если для вас важно быстро и без боли разместить систему на сервере, чаще всего удобнее брать отдельный VDS под мониторинг и error tracking: изоляция ресурсов, прозрачная утилизация диска и проще планирование retention.
Self-hosted как подход: когда «SaaS/готовый продукт» не подходит
Фразой «self-hosted error tracking» обычно называют две разные стратегии.
Развернуть готовый продукт у себя: self-hosted Sentry или self-hosted GlitchTip.
Собрать стек из компонентов: например, OpenTelemetry SDK/Collector + хранилище + UI/дашборды + алерты.
Во втором варианте вы получаете максимальный контроль, но платите временем инженеров и риском «проект мониторинга» вместо мониторинга проекта.
Что обычно входит в «самосбор»
Сбор ошибок приложениями: SDK/агенты, формат событий, нормализация полей, редактирование/удаление PII.
Трассировка: OpenTelemetry, выбор sampling-стратегии, договорённость о семантике атрибутов и кардинальности.
Хранилище: отдельные потоки для logs/metrics/traces, политики retention, компрессия, контроль дисков.
Alerts: правила, маршрутизация, дедупликация, окна тишины, эскалации.
Главный плюс self-hosted
Контроль над данными и предсказуемость: вы сами решаете, какие поля хранить, как долго и кто имеет доступ. Для проектов с требованиями комплаенса и внутренними политиками это может быть решающим фактором.
Главный минус self-hosted
Вы становитесь владельцем SLO самой системы мониторинга. Сборщик должен принимать события, UI должен открываться, алерты должны уходить. Иначе в момент инцидента вы будете дебажить не прод, а мониторинг.
Сравнение по ключевым критериям: alerts, retention, performance monitoring
Ниже — не «табличка ради таблички», а критерии, которые реально влияют на выбор в продакшене.
1) Alerts: узнать быстро и не утонуть в шуме
Система алертов хороша не тем, что умеет «сообщать», а тем, что умеет не сообщать лишнего. Для self-hosted стека критично сразу продумать маршрутизацию и окна тишины, иначе on-call превращается в спам-бота.
Если вы строите алертинг вокруг Prometheus/Alertmanager, полезно заранее выстроить практики: шаблоны, дедупликацию, silence и маршруты команд. Здесь может помочь наш разбор про маршрутизацию и silence в Alertmanager.
2) Retention: сколько хранить и зачем
Retention — это не только диски и деньги. Это ответ на вопрос: насколько далеко назад вы реально смотрите. 7 дней хватает для оперативной реакции, 30 — для «до/после релиза», 90 — для редких ошибок и сезонности. Чем больше tracing, тем дороже каждый лишний день.
3) Performance monitoring: нужно ли вам tracing или достаточно ошибок
Если у вас монолит и основные проблемы — «падает на исключении» или «ломается фронт», error tracking даст 80% пользы. Если микросервисы, очереди, много внешних API и сложные цепочки запросов — без performance monitoring вы будете долго искать первопричину.
Sentry: один из самых быстрых путей получить tracing и связать его с ошибками и релизами. Важно заранее решить уровень детализации и настроить sampling.
GlitchTip: чаще выбор «ошибки прежде всего». Performance monitoring обычно закрывают отдельным инструментом.
Self-hosted: часто начинается с OpenTelemetry. Это мощно, но требует зрелости: договориться о семантике и ограничивать кардинальность, иначе хранилище и счета растут лавинообразно.
Модель владения (TCO): где чаще всего «не сходится экономика»
Ловушка сравнений в том, что считают только лицензии/подписки и игнорируют операционные расходы. Для DevOps правильнее считать TCO: время инженеров, риски простоя мониторинга, стоимость хранения и сети.
Скрытые статьи затрат
Трафик событий: ошибок может быть больше, чем кажется (фронтенд, ретраи, таймауты внешних API, сканеры, тестовые окружения).
Нормализация и фильтры: вы либо платите за хранение мусора, либо инвестируете время в правила/фильтрацию.
On-call и доверие: если алерты шумят или система периодически падает, команда перестаёт ей верить. Вернуть доверие дороже, чем сделать аккуратно на старте.
Обновления и миграции: self-hosted продукт нужно обновлять регулярно и закладывать время на тестирование миграций.
Практика: начните с лимитов и sampling, иначе retention «съест» сервер
Самый частый сценарий аварии у self-hosted — заполнение диска или «задушенная» БД из-за потока событий. Минимальный набор защит:
ограничить окружения (production отдельно);
включить sampling на транзакции и/или на часть событий;
добавить квоты/лимиты по проектам и источникам;
заранее определить retention и механизм очистки.
Как выбрать: практичная матрица решений
Эти сценарии обычно быстро приводят к верному выбору.
Выбирайте Sentry, если…
нужно «всё в одном»: error tracking + performance monitoring + релизы + быстрые расследования;
несколько сервисов/команд и важно стандартизировать процессы;
вы готовы управлять объёмами: фильтры, sampling, понятная политика retention.
Выбирайте GlitchTip, если…
нужен self-hosted error tracking без тяжёлого APM;
команда небольшая и хочется минимизировать эксплуатационную сложность;
performance monitoring вы либо не планируете, либо закрываете отдельным стеком.
Идите в self-hosted «самосбор», если…
есть строгие требования к данным и интеграциям, которые сложно закрыть готовым продуктом;
в компании уже есть observability-платформа и нужно встроиться в неё;
есть ресурс на поддержку: документация, on-call, регулярные апдейты.
Минимальный чек-лист внедрения, чтобы система сразу приносила пользу
Разведите окружения: production, staging, dev. Смешивание окружений почти всегда убивает ценность данных.
Настройте релизы: версия/коммит/сборка должны попадать в события (и в транзакции, если включён performance monitoring).
Отфильтруйте шум: известные «не баг» ошибки, сканеры, отменённые запросы, ошибки нестабильных клиентов.
Согласуйте правила алертов: что считается инцидентом, что — задачей в бэклог, а что — просто метрикой.
Продумайте retention: сколько дней хранить ошибки и (если есть) транзакции. Заранее, до заполнения диска.
Ограничьте доступ: ошибки часто содержат PII и секреты «по неосторожности». Нужны роли и ревизия того, что отправляют SDK.
Если у вас уже есть алертинг по инфраструктуре, отдельно настройте уведомления на состояние самого error tracking: очереди/воркеры, время приёма событий, место на диске, ошибки БД. Для практических примеров пригодится материал про алерты и автоперезапуск сервисов на VDS.
Типовые грабли и как их обойти
Грабля 1: «Собираем всё»
События бесконечны, бюджет — нет. На старте лучше собирать меньше, но качественно: ключевые сервисы, production, понятные теги, релизы. Если нужен performance monitoring — начните с умеренного sampling и расширяйте постепенно.
Грабля 2: «Алерты настроим потом»
Если система собирает данные, но не зовёт вас вовремя — в момент инцидента вы всё равно будете искать логи руками. Начните хотя бы с двух алертов: резкий рост ошибок и деградация p95 по ключевым транзакциям (если есть performance monitoring).
Грабля 3: «Self-hosted без мониторинга самого мониторинга»
Любой self-hosted error tracking должен иметь собственные метрики здоровья: задержки приёма событий, размер очередей, заполнение диска, ошибки БД. Иначе вы узнаете, что система не работала, ровно тогда, когда она понадобится.
Вывод
Sentry — самый функциональный вариант, особенно если вам нужен performance monitoring, глубокие расследования и богатые alerts. GlitchTip — практичный компромисс для self-hosted error tracking: проще, легче, часто достаточно для задач «ловим ошибки и быстро реагируем». Self-hosted «самосбор» даёт максимальный контроль, но требует зрелости и времени на эксплуатацию, иначе TCO будет выше ожиданий.
Если сомневаетесь, выбирайте от сценария: что болит прямо сейчас (ошибки или производительность), какие требования к данным, и есть ли ресурс на поддержку. Всё остальное — детали настройки retention, фильтров и алертной гигиены.
