Главная ошибка мониторинга в больших системах и как мы её избежали: опыт СберТеха
Мониторинг страдает не от сбора метрик, а от отсутствия целостного взгляда. На связи Александр Ковалёв, разработчик инженерных продуктов Platform V Works. В статье расскажу, почему логов недостаточно для мониторинга, какие три варианта архитектуры с Prometheus мы рассматривали в СберТехе и что в итоге выбрали.
Как увидеть общую картину и действовать дальше
Когда система становится сложной, важно уметь смотреть на неё не только «изнутри», но и сверху — видеть общую картину. Такой подход часто называют helicopter view: взгляд с высоты, который помогает понять, как разные части системы связаны между собой и что происходит с сервисом в целом.
Пока продукт небольшой, такой взгляд не нужен. Представьте простой сервис: веб-сервер с конечной точкой (endpoint), куда пользователь шлёт запросы. Пока пользователь один, хватает стандартного логгера: видим, что записи в логах появляются, можем посмотреть ошибки и их текст.
Но по мере развития сервиса пользователей становится много, они объединяются в группы под разные сегменты, продукты или команды, а бизнес-функциональность усложняется. Можно по-прежнему анализировать происходящее через логи, но это неудобно, если помимо бизнес-событий нужны ещё и инфраструктурные показатели.
В промышленном контуре возникает вопрос: «Достаточно ли нам логов для понимания того, что конкретно пошло не так при серьёзном сбое?» Изучая только логи, мы смотрим на единичные срабатывания, и контекст проблемы смещается для каждой выбранной строчки, а в голове при этом крутится мысль: «Эту проблему мы знаем, она не влияет ни на что».
Мы для себя сформулировали ответ: одних логов недостаточно. Да, они остаются, но в дополнение к ним нам нужно видеть срезы состояния систем на множестве панелей в реальном времени. Внедряя мониторинг, мы добавляем налог на развитие, актуализацию и сопровождение.
Благодаря такому подходу мы не делаем огромный шаг, в корне срезающий стоимость анализа проблем во всех случаях, но итеративно приближаемся к «helicopter view» — взгляде на ситуацию сверху, который позволяет охватить общую картину и увидеть взаимосвязи. И это — основная задача, которую мы решаем.
Как внедрять метрики, чтобы мониторинг не стал проблемой
Когда количество сервисов растёт, хаос возникает очень быстро: метрики собираются по-разному, любое изменение требует ручных правок и согласований. В какой-то момент мониторинг перестаёт помогать и сам становится источником проблем. Чтобы этого избежать, мы сначала зафиксировали базовые принципы и поняли, без каких компонентов дальше двигаться невозможно.
На следующем этапе у нас появилась потребность в двух компонентах:
- хранилище метрик, где будут аккумулироваться и агрегироваться нужные значения
- интерфейс визуализации, где мы будем видеть графики, таблицы и оповещения
Проанализировав, что уже используется в нашей компании, а также что является де-факто стандартом на рынке, мы пришли к очевидному выбору: Prometheus как хранилище и Grafana как средство отображения и анализа.
Мы начали с проработки архитектуры нашего решения. Было несколько вариантов — расскажу про плюсы и минусы, которые мы нашли для себя. Это реальный случай в компании с коммунальными инсталляциями и рядом ограничений от коллег из информационной безопасности.
Первый вариант, который является, скорее, базовым:
Есть существенные недостатки:
- мы выставляем «наружу» каждый сервис, с которого хотим собирать метрики
- накладные расходы на коммуникации по уведомлению об изменениях
- отслеживание и применение изменений на Prometheus (на новый сервис появится новый Target)
- накладные расходы на обеспечение безопасности
Эта схема нам не подошла, но она подойдёт для pet-проекта, где основная задача — апробация.
Второй вариант, который больше подходит для организаций с гибкими стандартами или небольшим количеством проектов, где можно оперативно внедрить современные практики:
В архитектуре с OpenTelemetry Collector gateway приложения не ожидают, что внешний Prometheus скрапит их напрямую. Вместо этого они отправляют метрики на единый endpoint Collector.
Там данные проходят через pipeline обработки: фильтрацию, агрегацию, возможно, sampling/recording. Затем Collector экспортирует подготовленные данные в Prometheus.
Преимущества этого решения:
- Больше контроля над потоками телеметрии: Collector может обогащать метки, агрегировать, фильтровать
- Приложения отправляют данные в Collector, а не ждут скрапа снаружи
- Collector может отправлять напрямую телеметрию в выбранный вами backend или remote-write
Подробнее можно почитать в этих статьях, чтобы реализовать такую схему в вашей организации:
Третий вариант, на котором мы остановились и который, по моему опыту, встречается чаще в крупных организациях:
Развёрнут собственный namespace‑collector Prometheus, скрапящий с сервисов метрики /actuator/prometheus. В свою очередь общий (коммунальный) Prometheus получает метрики с локального collector’а, не дёргая каждый сервис напрямую.Вариант, который тоже является рабочим, но со своими недостатками:
- При скрапинге множества сервисов напрямую легко получить избыточное количество временных рядов
- Pull-модель Prometheus не даёт промежуточной обработки: нельзя фильтровать, агрегировать или обогащать метрики до импорта — всё происходит как есть
- Прямой скрап большого количества pod’ов или namespace’ов усложняет поддержку: при росте системы конфигурация усложняется
Если вы дочитали до этого момента, вам точно будет интересно — а что с безопасностью и как организовать процесс мониторинга с точки зрения команды?
Отвечаю на эти вопросы в подробной статье в блоге Сбера на Хабре: там я рассказал, как выглядит реальность разработки. Она поможет собрать воедино все полезные источники и использовать их для адаптации.
А если вам близок наш подход к решению сложных задач и вы хотите реализовать свой потенциал в сфере высоких технологий — добро пожаловать в Сбер! Открытые позиции в разнообразных командах, где вашим скиллам точно найдут применение ищите на нашем портале.