Масштабируем мониторинг: как удалось вырасти с нуля до миллионов событий в день

1. Контекст и масштаб задачи
Автономная система принятия кредитного рискрешения и расчета бизнес-потенциала с использованием средств ИИ юридическим
лицам сегментов: крупнейший, крупный, средний, а также микро и малый бизнес - один из критичных бизнес-процессов банка.
Простой в минуты — это реальные финансовые потери и репутационные риски. В своей работе придерживаемся нулевой
толерантности к инцидентам. Пять лет назад мы начали строить систему технологического мониторинга, которая
сегодня обеспечивает наблюдаемость на следующих масштабах:
- ~7 млн метрик ежедневно собираются со всех сред (Dev, Stage, Production);
- более 100 тысяч пересчётов и реагирований на события в день на Production;
- более 60 млн ответов по API смежным систем
- от 600 ГБ до 1 ТБ логов генерируется ежедневно и доставляется через Kafka в OpenSearch;
- хранение логов — 35–37 дней, что позволяет расследовать инциденты даже с большим лагом.

2. Эволюция стека: от legacy к целевой архитектуре
За 5 лет система прошла путь от WebSphere/Wildfly до целевого стека DropApp/Pangolin + Kafka.
Расскажу, почему каждая миграция была необходима, какие проблемы возникали при переходе и какой эффект получили:
- Сократили время деплоя с 5-6 часов до 2-3 минут.
- Из монолита перешли к микросервисной архитектуре.
- Приложения написаны на Java, Go и Python — расскажу, как мы пришли к мультиязычному стеку и как это влияет
на подход к инструментам и сбору метрик.
- В настоящее время у нас ~150 микросервисов.

3. Архитектура наблюдаемости

Основные четыре столпа наблюдаемости в нашей реализации:
Метрики:
- Оперативное хранилище — Prometheus;
- ~7 млн метрик в день,
- Federation, есть два инстанса Prometheus для Stage & Prod;

Логи:
- Приложения → Kafka → OpenSearch;
- Объём: 600 ГБ – 1 ТБ/день, хранение 35–37 дней;
- 8 нод Opensearch в кластере на Production (ноды географически распределены по ЦОДам),
- Используем ISM (Index State Manager) для разных шаблонов индексов настроены разные политики.

Алертинг:
- AlertManager → три канала: почта, чат, СМС;
- Предоставляем сервисный аккаунт для создания алертов командами;

Визуализация:
- Центральный дашборд «здоровья системы» + множество вспомогательных дашбордов для дебага — Grafana;
- Всего дашбордов ~100
- Есть автоматическая генерация дашбордов.

4. Проблемы и неочевидные решения:
- До перехода на сбор через Kafka, были проблемы с переполнением нод OpenSearch. Ранее при переполнении кластера
OpenSearch нам приходилось вручную удалять индексы, что неизбежно приводило к потере данных. Для предотвращения
повторения подобной ситуации сейчас добавлен экспортер OpenSearch и настроены соответствующие оповещения (алерты).
- Использование экспортеров и инсталляций Prometheus AS IS без тюнинга, что порождало большое
количество мусорных метрик, которые никак не использовались.
- Сбор собственных логов и аналитику самих компонентов системы мониторинга (Мониторинг мониторинга)

5. Результаты и метрики эффективности:
- MTTR (среднее время восстановления) изменился за 5 лет с 2 часов до 10-15 минут.
- Доступность системы сейчас составляет 99.95%, но внутренне мы стремимся к 99.99%
- Скорость обнаружения проблем с момента возникновения до алерта — 1 минута;
- Стоимость эксплуатации: Оптимизировали ресурсы через уход от вендоров.

6. Практические советы: что мы бы сделали иначе:
Конкретные рекомендации для тех, кто строит наблюдаемость на масштабах:
- Как правильно проектировать метрики для Prometheus при высокой кардинальности:
Во-первых, нужны алерты, сообщающие об их появлении. Для метрик их нужно агрегировать на уровне
источника с исключением UID - этот шаг нужно выполнять на этапе проектирования.
Если всё же нет возможности этого избежать - то нужно удалять лейблы на уровне федерации. До объединения - тюнинг не "AS IS" инсталляций.
- Паттерны организации логов в Kafka → OpenSearch при объёмах в сотни ГБ/день;
Осуществляется подбор в процессе тестирования. На этапе ingest по необходимости логи трансформируем.
Нужно следить за write opesearch и lag в кафке, для этого у нас есть экпортеры.
- Подход к построению алертинга, который не превращается в «шум».
Оптимизируем алерты, по которым не принимается никакого решения, за исключением информационных по запросу пользователя
Регулярно собираем через for (ждём подтверждения следующим скриптом, что алерт действительно сработал).