Т‑Банк — это не только банк. Это еще брокер, мобильный оператор, страховая компания и другие сервисы. Все они с самого начала создавались с расчетом на использование в онлайне. Это значит, что критически важно поддерживать SLA и обнаруживать проблемы раньше, чем они причинят ущерб. Такое возможно, только если выстроить качественный мониторинг на всех уровнях — от инфраструктуры до бизнес-процессов.

Изначально инструменты мониторинга в Т‑Банке представляли собой солянку из десятков инстансов Zabbix, ELK, Graylog, Prometeus и др. Такой зоопарк не позволял делать сквозной анализ, настройка алертинга была болью. Не говоря уже о сложности его администрирования.

Чтобы сделать мониторинг более централизованным, развернули Splunk — универсальную платформу для обработки машинных данных. С частью систем Splunk интегрировался автоматически, для других настроили заливку логов руками. Аналитики были очень довольны: наконец-то стало возможно строить сложные запросы к логам. Правда, стоимость Splunk была завязана на объем данных, а данных в Т‑Банке уже тогда было очень много, но это не успело стать проблемой.

В 2019 году Splunk скоропостижно покинул Россию, продлить лицензию стало невозможно. Идеальной замены на рынке не было, наступать второй раз на грабли вендорлока тоже не хотелось. Приняли решение разработать собственный инструмент — так появился Sage Observability.

Мы хотели переехать на Sage Observability бесшовно, для этого нужно было иметь:

• свой Splunk-подобный язык запросов;
• всеядность относительно формата логов;
• визуализацию и алертинг.

Собрали небольшую команду из опытных инженеров, и уже через год Sage Observability был на проде. Переезд со Splunk завершился успешно.

Sage Observability — это высоконагруженная система, распределенная на несколько дата-центров. С точки зрения архитектуры ее можно разделить на две большие части: запись и чтение (поиск + алертинг). А эти части в свою очередь делятся на логи, метрики и трейсы.

Логи. Именно логи дольше всего существуют в Sage Observability, дают самую большую нагрузку и занимают больше всего места.

В качестве БД для логов используется Elasticsearch, общий объем порядка 7 ПБ, пиковый поток 3 Гб/с. Как мы выживаем с такой нагрузкой, рассказывали на Saint HighLoad++ 2023. Доклад попал в топ-5 конференции — настолько впечатлились участники. Спойлер: выживаем непросто, поэтому мы разработали SageDB, собственную БД для логов, и уже перенесли туда часть нагрузки. Что скрывается за этой невинной формулировкой, можно узнать из другого нашего доклада.

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

Метрики. Для хранения метрик мы используем VictoriaMetrics в кластерной конфигурации. Для сбора метрик разработали компоненты, которые поддерживают OpenMetrics/RemoteWrite и позволяют нам гибко адаптироваться к нагрузке, распределять клиентов по кластерам и не терять данные даже в случае отказов кластеров. Метрики мы умеем хранить до года благодаря специальной конфигурации LTS-хранилища и поискового движка.

Трейсы. Исторически трейсинг развивался независимо. В 2023 году интегрирован в Sage Observability, завершив таким образом классическую триаду телеметрии.

Mage — поисковый движок, ключевой компонент Sage Observability. Изначально мы разработали Mage вместе с языком запросов MageQL для бесшовного переезда со Splunk, продолжаем активно его развивать. Основные фичи:

• простой и понятный язык запросов с поддержкой фильтрации, преобразований и статистики;
• компиляция в нативные запросы к Elasticsearch (в QueryDSL);
• поддержка PromQL/MetricsQL для запросов к метрикам;
• джоины логов и метрик;
• автодополнение и подсветка синтаксиса.

Алерты. Собственный движок алертов позволяет писать и запускать триггеры на JavaScript, это делает логику максимально гибкой. В коде триггера можно выполнять MageQL-запросы, анализировать результаты и рассылать алерты по различным каналам, адресам и группам пользователей. Когда не нужна гибкость, можно накликать упрощенные алерты через UI или выбрать готовые из каталога.

Anomaly Analyzer. Собственная система анализа данных на основе машинного обучения, которая автоматизирует обнаружение аномалий и прогнозирование бизнес-метрик.

Anomaly Analyzer использует статистические алгоритмы для выявления отклонений от нормального поведения в бизнес- и технических показателях. Применение Anomaly Analyzer в наших процессах помогает быстрее находить инциденты.

Grafana. Для визуализации метрик в Sage Observability используется Grafana. Мы написали плагин, чтобы можно было использовать MageQL в качестве датасорса.

Sage Observability — это в первую очередь про высокие нагрузки, быструю обработку запросов и оптимальную утилизацию ресурсов. Поэтому конкретные языки и технологии мы используем, если именно они дадут максимальный эффект. Большинство компонентов написаны на .NET, Kotlin, Go, JS.

Команда Sage Observability — высококлассные специалисты, которые любят свою работу и продукт. Звучит, как дежурная фраза из вакансии, но это настоящая правда. В чем причина такой любви?

• Инженерный продукт. Sage Observability — это тот редкий случай, когда вы делаете инструмент для таких же инженеров, как и вы сами.
• Масштабы. Sage Observability — это сотни хостов, тысячи ядер, петабайты дискового пространства. Вы физически ощущаете это.
• Красивая архитектура и лучшие практики. Если вам когда-либо казалось, что секция System Design на собесе была лишней, то это точно не про Sage Observability. Здесь не получится применять плохие решения, и не потому, что они не пройдут ревью. А потому, что они просто не вывезут наш прод.

С 2023 года Sage Observability перестал быть чисто внутренней историей. Мы проделали огромную работу, чтобы, как мы говорим, «оторвать его от земли» и начать продавать другим компаниям.

Одним из первых наших клиентов стало АО «НСПК» — оператор платежной системы «Мир». На высоких нагрузках и надежности они съели стаю собак, поэтому особенно приятно, что они выбрали Sage в качестве инструмента для мониторинга.

Направление настолько бурно развивается, что под него есть отдельная команда интеграций. Ребятам даже пришлось написать свой фреймворк для развертывания Sage Observability вне Т‑Банка.

Зарегистрировали Sage Observability в реестре российского ПО. 

Что это значит для нас?

• Sage Observability стал одним из первых продуктов компании в реестре, второй — Notification Center.
• Регистрация обязательна для продаж крупным компаниям и укрепляет наши позиции на рынке, поддерживая импортозамещение.
• Подготовка к подаче в реестр — длительный процесс, требующий подтверждения соответствия продукта и компании российским стандартам.
• Подготовка заняла много времени и сил: локализация, подготовка архитектурных документов, проверка лицензионной чистоты, оформление документации по функциональности. Весь процесс, от старта до получения регистрации, занял почти полтора года.
• Т-Команда — априори крутая!