Comments 24
Спасибо, попробую, а то держать sentry накладно. Я так понимаю это ваш продукт?
Да, я активно участвую в разработке. Сам Metric вырос из накопившихся головных болей разработчиков и сам по себе создал команду единомышленников - поэтому, скорее это общий продукт. Мы рады будем новым единомышленникам-контрибьюторам, особенно с толковыми идеями по дальнейшему развитию и улучшению.
А, ну и где в тексте про конфликт интересов?
Какой именно конфликт интересов Вы имеете ввиду?
Имею в виду вполне обычный конфликт интересов: автор сравнительного материала сам участвует в разработке одного из сравниваемых продуктов — причём именно того, который по итогам статьи оказывается победителем. При этом эта аффилированность в статье не раскрыта. 🤷♂️
Само участие автора в Metric ни разу не проблема. Проблема в том, что читателю предлагают воспринимать текст как независимое сравнение Sentry и альтернатив, не сообщая, что автор является заинтересованной стороной. Это как раз та информация, которую обычно раскрывают в начале материала, чтобы читатель мог учитывать её при оценке выводов.
Собственно, автор и не скрывал аффилированности с продуктом. Конфликт интересов просто не имеет смысла, если все данные и тесты абсолютно честные, продукт действительно решает все изложенные проблемы и является абсолютно бесплатным, что не несёт за собой извлечения выгоды автором, как интересантом.
Под заголовком указан бэйдж "Мнение" - независимое мнение автора. Статья не позиционировалась, как "независимое сравнение".
вот, кстати, пример как правильно делать — прямо тут, на Хабре: https://habr.com/ru/articles/1035660/
Я смотрю у вас есть Метрики, но все же уточню. Мониторинг производительности есть?
Попробовал - действительно круто. В ближайшее время буду мигрировать на Metric. Автору респект
Есть еще такая альтернатива, по той же причине
https://urgentry.com
Я думаю, что причина монструозности деплоя Sentry - не в хитром способе заставить вас купить SaaS, но в банальной экономии.
Экономии времени и трудозатрат на адаптацию их SaaS специфики (в виде огромных RPS, количества пользователей, SLO) под небольшие on-prem инсталляции. Можно сделать проще, конечно, но это будет фактически поддержка двух продуктов, один из которых - бесплатный и не накладывает ограничений (насколько я помню).
Не соглашусь. Их, так называемая, "SaaS специфика" ровно таким же образом бьёт им по карману, требуя неимоверных мощностей для работы сервисов. Сама по себе чрезмерная декомпозиция, нерациональное использование ресурсов и сервисы ради сервисов сами по себе не являются "SaaS спецификой" - это банальное отсутствие архитектурного видения. У нас есть куча примеров, когда SaaS с продуманной архитектурой, чётким видением реализации и паттернов проектирования, становился невероятно эффективным в масштабировании и потреблении ресурсов. Тот же Amazon Prime Video, например, переходом на проработанные модульные монолиты с такой же микросервисной "каши", как у Sentry, снизил инфраструктурные расходы на 90%.
Я не говорил ничего про обоснованность выбора архитектуры и количества компонентов разработчиками Sentry.
Адекватно или нет - у них есть определенный набор сервисов и зависимостей, необходимый для работы под их же нужды, в их сценарии, как они считают нужным. Добавлять сюда вариативность ради упрощения деплоя и поддержки бесплатной версии - это трата ресурсов команды, а бизнес ценность этого процесса сомнительна, на мой взгляд.
Ну а на тему чрезмерной декомпозиции и нерациональности и прочего - наверное не очень корректно рассуждать в таком ключе, не видя их инфраструктуру, метрики и требования.
Наконец-то годнота на Хабре снова появляется
Раз в комментариях собирается список лёгких self-hosted вариантов - добавлю свой. Дисклеймер сразу: я автор, так что читайте как заинтересованную сторону.
Gotcha - один Go-бинарник плюс PostgreSQL и ClickHouse, compose из трёх сервисов. Принимает данные по протоколу Sentry SDK (то есть официальные SDK работают как есть, меняется только DSN) и по OTLP для метрик и логов. Внутри: ошибки с группировкой в issues, трейсы и транзакции, Web Vitals, метрики с порогами, логи с полнотекстовым поиском, профили CPU (Sentry profiling и pprof), аптайм со статус-страницами, метрики хостов через свой агент, SLO с burn-rate алертами и эскалации. Интерфейс и доки на русском и английском. Лицензия Apache-2.0.
Отвечу заодно на вопрос выше про мониторинг производительности: трейсинг, спаны, детект перформанс-регрессий после деплоя - есть, это одна из основных частей.
Код и docker-compose: https://github.com/OtezVikentiy/gotcha
Про то, как это устроено внутри и почему без Kafka и Redis, писал тут: https://habr.com/ru/articles/1062624/
А что с бенчмарками? Есть тесты производительности?
Честно: нагрузочных тестов нет, поэтому цифр "событий в секунду" я нигде и не называю - брать их с потолка не хочу. Что измерено на живых инсталляциях: потребление в покое (Go-бинарник 6 МБ, PostgreSQL 25 МБ, ClickHouse 730 МБ на дефолтном профиле) и байты на запись после сжатия (спан ~38 Б, точка метрики ~12 Б, событие ~45 Б на 14 днях данных). Из ограничений по дизайну: rate limit на проект 500 запросов/с с бёрстом 1000, приём батчится в ClickHouse по 1000 строк или раз в 5 секунд, при недоступности базы буферизует в памяти и не блокирует ingest. Нагрузочный тест в планах; когда будет, выложу отдельным постом с методикой, а не цифрой в комментарии.
Наличие ClickHouse - это точно не "лёгкий self-hosted". В статье эта тема раскрыта.
Согласен, ClickHouse - самая тяжёлая часть стека, и в своих цифрах я это не прячу: из ~760 МБ в покое на него приходится 730. "Лёгкий" я употребил в том смысле, в каком его использует тред: три контейнера и один бинарник против двух десятков сервисов с брокером, воркерами и двумя кешами. По железу задокументированный минимум - 2 vCPU / 2 ГБ / 20 ГБ SSD. Под этот размер есть отдельный профиль compose: ClickHouse ограничен 1 ГБ по cgroup, у него выключены системные логи-профайлеры (trace_log, text_log и остальные) и урезаны фоновые пулы. На живом VPS с 2 ядрами и 2 ГБ после этого ClickHouse занимал 295 МБ вместо 880. Это всё равно больше, чем 1 ГБ на всё, тут спорить не буду. Зачем он тогда нужен: кроме ошибок я храню спаны, логи и метрики, а это колоночные объёмы - на тех же 14 днях сжатие вышло от 3.7x на спанах до 14x на событиях, и в реляционной базе это стоило бы диска заметно дороже.
Sentry пора на покой… Metric готов принять пост