Мониторинг, который узнает о сбое первым

Привет! Меня зовут Валентин Лебедев, и я начальник Центра ИТ-мониторинга в Газпромбанке.

В марте нашим докладом открылась Observability Conf, первая в стране конференция целиком про мониторинг. Полчаса на сцене, формат интервью: вопросы со стороны заказчика задавал Ян Ашенкампф, наш CTO. Здесь то же самое, только без тайминга и с деталями, на которые там не хватило времени. Начну с того же, с чего начал тогда.

Знакомая ситуация: бизнес звонит и спрашивает, почему ничего не работает. Мы смотрим в дашборды: Zabbix зеленый, OpenTelemetry зеленый, у соседнего отдела вообще все прекрасно. Бизнес уверен, что мониторинга нет. ИТ уверено, что есть. Доверие постепенно снижается, диалог становится все сложнее.

Получается эффект арбуза: снаружи зеленый, внутри красный.

«Сделайте нам хороший мониторинг»

Эту фразу я слышу уже пятнадцать лет, запрос почти дословно повторяется. При этом никто не уточняет, что именно подразумевается под «хорошим».

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

Это звучит несложно, но ломается на каждом из трех пунктов.

Классика ломается не там, где ждешь

Zabbix, VictoriaMetrics, Elastic, сверху OpenTelemetry. Примерно такую связку предложит и ChatGPT, если спросить его, как построить мониторинг. Небольшой компании ее действительно хватит. На нашем масштабе она ломается дважды.

По нагрузке: больше 700 тысяч метрик в секунду эта комбинация не выдерживает.

По масштабируемости: один инженер развернул свой кластер, сосед развернулся на OpenTelemetry, двумя этажами выше живет чей-то Zabbix. Умножьте на 50-70 команд. При разборе значительного инцидента люди буквально бегают с первого этажа на пятый и заглядывают друг другу в мониторы, потому что метрики везде разные, каждый видит свой кусок, а состояние сервиса целиком не видит никто.

Отсюда три корневые проблемы, которые я вытащил из опыта выстраивания систем мониторинга: коммуникация с бизнесом, отсутствие MaaS в центральной платформе, несвязанные потоки данных. Ни одна не лечится выбором правильной СУБД.

Проактивность: метрика, за которую платят

Вся система мониторинга держится на одном ключевом показателе.

Проактивность — это доля значительных инцидентов, которые открыл мониторинг, а не колл-центр и не бизнес. У нас 80% по банку и 95-97% по розничному кредитному конвейеру. В девяти случаях из десяти мы сообщаем о проблеме первыми, а не узнаем о ней последними.

Почему это важно? Потому что разговор переходит с языка «мы поставили еще один экспортер» на язык, где у бизнеса появляется измеримая гарантия.

Лестница зрелости и разворот сверху вниз

Пять этапов:
● инфраструктура;
● приклад;
● бизнес-метрики;
● APM на OpenTelemetry;
● RUM.

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

Внедрить Zabbix и внедрить RUM, это вложения разного порядка. Маршрут зависит от того, что нужно вам.

Нужен быстрый старт: заходите через инфраструктурный мониторинг и приземляете туда даже бизнес-метрики. Да, на Zabbix. Да, работает.

Большой бизнес и много запросов: начинайте с головы и идите в ноги. Сначала RUM и бизнес-параметры, потом декомпозиция вниз.

Логика определяется приоритетом клиента. Нет клиентов, нет компании. Насколько всё бывает просто, показывает наш розничный кредитный конвейер. Он мониторится двумя метриками: вход и выход. Люди на выходе получают деньги? Значит, конвейер работает.

Что держит нагрузку

Zabbix я называю автоматом Калашникова. У этой системы сложилась репутация устаревшей, однако у нас она работает на 150 тысячах NVPS, и это, по моим наблюдениям, одна из крупнейших инсталляций в стране. Загрузили конфигурацию, шаблоны, базовые паттерны, включили и забыли. Заодно Zabbix кормит нашу CMDB: виртуалки, лицензии, софт. В классической поставке свыше 10 тысяч NVPS он не поедет, а TSDB открывает дорогу к 150 тысячам. Этот путь необходимо будет пройти.

VictoriaMetrics мы прошли от миллиона до 6,5 миллионов метрик в секунду. В базовой сборке отсечка стояла где-то на миллионе, и в три часа ночи разработчики действительно не спали — система мониторинга падала. Вместе с ней не спала и значительная часть банка. Сейчас у Газпромбанка 6-6,5 миллионов, плюс миллион каждый квартал. Инстансы разнесли балансировкой, около половины RAM держим прогретой, но неиспользуемой. Для сравнения: по данным сайта VictoriaMetrics у крупных иностранных компаний метрик 3,5 - 4 миллиона.

У нас 200 терабайт на весь банк с годовым хранением. Не «КАМАЗ жестких дисков», о котором в индустрии ходят легенды. Фокус в том, что сырой лог мы не храним вообще. Он работает транспортом: удобно выгружать телеметрию текстом, выгружайте. На трансформации лог превращается в метрики, метрики уезжают на долгое хранение, сырой лог удаляется. Позиция при этом не изменилась: мониторинг — это не логи.

MaaS: пятнадцать дашбордов до первого обращения

Самый частый управленческий вопрос ко мне звучит так: как управлять разнообразием инструментов и форматов, если команды говорят «нам удобнее писать в своем»? Ответ простой: не запрещать, а обслуживать.

Платформа дает технологическую свободу, шведский стол форматов загрузки. Всё, что можно автоматизировать, мы автоматизируем: VMware, Kubernetes, сертификаты.

Целевое состояние выглядит так. Разработчик заводит систему. Он ни разу не обращался к нам, не подавал заявку на постановку базы или приклада. Заходит в свое рабочее пространство, а там уже 15 дашбордов, консоли событий, расчет error budget и SLA.

Дальше срабатывает разделение ответственности: мы сделали около 500 золотых дашбордов, команды нарисовали несколько тысяч своих. Важность метрик определяет не команда мониторинга, а ее клиенты. Вот это и есть MaaS.

Отдельная сущность, которой в Grafana по умолчанию нет, это консоль событий. Не список алертов: рядом видно, сколько звонков прилетело в колл-центр, сколько значительных инцидентов зарегистрировано и что приходит прямо сейчас. Общий фон вместо потока срабатываний.

35 миллионов алертов и «Наташа, всё плохо»

Читать такой поток невозможно, поэтому он идет через шумо- и штормоподавление: самописный alert-manager, Kafka, Postgres, ClickHouse, Grafana OnCall. Алерты чистятся, коррелируются, на выходе остается сухая фактура.

Статических порогов здесь недостаточно. Они удобны, когда у вас сотня метрик; на миллионах это не работает. Поэтому в работе и статика, и anomaly detection с коридором нормы (верхнее и нижнее предсказание), и виртуальные метрики поверх физических.

Поверх Grafana работает Apache ECharts. На нем для каждого сервиса рисуется карта бизнес-процесса: процесс, функции, серверы. На модель нанесены алерты, и по одной картинке видно, как отказ конкретного компонента влияет на бизнес-функции.

С чего начинать?

● Начните с разговора с бизнесом. Концентрируйтесь не на инструментах, а на про проактивности и том, кто первым узнает о сбое. Именно этот разговор конвертируется в бюджет.
● Соберите архитектуру из open source и доработайте под свою нагрузку. Готового продукта, который закроет все, вы не купите.
● Обратитесь в хелпдеск за топ-10 значительных инцидентов и сверьте картину с колл-центром. Там подсветят намного больше, чем кажется.

Третий пункт повторю отдельно, потому что его пропускают чаще всего. Можно взять open source, собрать продукт, накатить золотые дашборды и MaaS, а получить платформу, которая формально существует, но не приносит пользы. Оживляет ее не архитектура, а покрытие тех инцидентов, которые критичны для бизнеса.