Мы начинали с обычного ELK-стека, логи приходили на logstash, записывались в Elasticsearch, а пользователи смотрели их в Kibana. Потом в эту схему добавилась Kafka, так как мы понимали, что на пиках нагрузок не успеваем записать все логи в Elasticsearch. Всё это располагалось в одном ЦОДе, а в Kafka была единая очередь. В результате горизонтального масштабирования Elasticsearch разросся до 30+ нод. Данная схема справлялась с нагрузкой в 100 тысяч документов в секунду.

Как вы понимаете, эта схема нас устраивала только до определённого периода. В какой-то момент нагрузка начала расти как на дрожжах.

Привет, Хабр! На связи Филипп Бочаров, руководитель платформы наблюдаемости и мониторинга для более 400 продуктов экосистемы МТС, и Юлия Тальцкова, ведущий инженер сервиса логирования и кластеров Open Search с более 400 терабайтами логов клиентов. Этот материал написан на основе нашего доклада для конференции Highload++

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

Метрики — один из трёх базовых типов телеметрии и основа мониторинга любого приложения. Но что, если необходимо собирать их в рамках крупной и высоконагруженной экосистемы? Как собрать метрики с десятков тысяч хостов разных ЦОДов и сотен типов приложений? И как упростить инженерам настройку правил алертинга и создание дашбордов?

Привет, Хабр! Я Филипп Бочаров, руководитель стрима мониторинга и наблюдаемости в МТС Digital. Мы занимаемся всеми типами телеметрии: логами, трассировкой и, конечно, метриками. Единое хранилище метрик экосистемы — часть нашей платформы наблюдаемости. Для этих целей мы используем агент Telegraf и большой кластер VictoriaMetrics, принимающий 10+ миллионов сэмплов в секунду.

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

Привет, Хабр! Меня зовут Филипп Бочаров, я руководитель направления мониторинга и наблюдаемости в МТС Диджитал. В нашей экосистеме более 400 продуктов, которые активно взаимодействуют между собой. Для такого обширного ландшафта мы используем единую платформу мониторинга: она устанавливает общие стандарты, дает возможность легкого перехода на новый стек и снижает трудозатраты на типовые операции. 

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

Привет! Меня зовут Филипп Бочаров, я руководитель центра мониторинга и наблюдаемости в МТС Digital. Мы делаем распределённую трассировку, чтобы контролировать качество наших сервисов и предотвращать аварии. В этой статье разберём, как добиться понятной и прозрачной работы от сложных распределённых систем.

За время, прошедшее с прошлого доклада, количество обрабатываемых в единицу времени спанов выросло в несколько раз. Рассмотрим, какие архитектурные решения начали «поджимать», и как команда МТС их исправляла.

Всем привет! Меня зовут Филипп Бочаров, я руководитель центра мониторинга и наблюдаемости в МТС Digital. Мы с командой делаем платформу Наблюдаемости – это набор сервисов, который позволяет сделать работу других продуктов МТС прозрачной и понятной. Сегодня я расскажу про распределенную трассировку экосистемы МТС. 

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