Как научить On-Prem Sentry принимать 60 млн событий в сутки

DevOps и эксплуатация

Трейсинг

Логирование и мониторинг
Observability в enterprise
Логи, метрики, ошибки
DevOps / SRE

Доклад отозван

Мнение Программного комитета о докладе

У вас тормозит Sentry? Вы ищете, куда бы пристроить ваши трейсы и ошибки вместо NewRelic/Datadog? Ой, а может у вас есть пара своих патчей для On-Prem Sentry? Ну, и наконец, вам бы сгруппировать поток ошибок, а то с логами бардак? За этим и многим другим о Sentry — добро пожаловать на доклад!

Целевая аудитория

DevOps- и SRE-инженеры; все, кому интересны инструменты observability.

Тезисы

В докладе расскажу про то, как мы в СберМаркете решали проблемы производительности on-prem Sentry — учили обрабатывать 60 миллионов событий в сутки, для чего пришлось провести оптимизацию почти каждого компонента.

Оптимизировали БД Postgres — научили Sentry работать не только с мастером, но и с репликами. Перенесли хранение событий в s3 и сэкономили 12 ТБ на БД (которые лежали в одной таблице!). Оптимизировали обработку событий из kafka — даже если у тебя есть буфер, не значит, что все будет стабильно. Научили работать с шардированным ClickHouse и максимально глубоко погрузились в архитектуру, чтобы достичь производительности, которую не позволяет даже Cloud Sentry.

О боли, муках и страданиях от несовершенства архитектурных решений, что из этого вытекло, над чем пришлось поработать и к чему приложить руку.

Руководитель базовой инфраструктуры в СберМаркете, SRE-инженер с 10-летним опытом.

СберМаркет

СберМаркет — технологический онлайн-сервис, который помогает делать покупки не выходя из дома. Tech-команда СберМаркета создает один из самых сложных высоконагруженных e-commerce-проектов в России и делает это с любовью.

Видео