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

Резерв

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

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

Доклад принят в программу конференции

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

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

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

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

Тезисы

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

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

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

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

СберМаркет

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

Видео