Мониторинг, который кричал «Волк»! Что мы придумали для корректного сбора метрик

Привет, Хабр! Меня зовут Станислав Савостин, в СберТехе я занимаюсь системой мониторинга «Маяк». Это наш внутренний сервис, который основан на Prometheus, но включает много доработок и «тюнинга» под наши условия и стандарты работы.

Основная задача мониторинга — быстро выявить проблему (до того, как что‑то упало) и отреагировать, чтобы пользователи не заметили. Из‑за высокого темпа уведомлений и реакций часто возникает риск пойти по неправильному сценарию. Например, перезагрузка брокера Kafka или Artemis занимает около 30 секунд, поэтому упустить такую ситуацию легко, хотя для нас это критически важная метрика. Ложная тревога или задержка передачи метрик — максимально неприятные события, так что мы постоянно дорабатываем систему и уже научились отслеживать перезагрузки сервисов.

Я расскажу, как мы дорабатывали мониторинг, как реагируем на действительно опасные ситуации и что помогает нам ловить дзен, когда все кричат: «Волк!»

Что болит у Prometheus

Основная проблема мониторинга — отслеживание коротких событий. Их непросто отловить, и ещё сложно правильно идентифицировать. Наша команда провела исследование временных рядов Prometheus, чтобы оценить масштаб и характер доработок. Оказалось, что после прекращения поступления метрик есть проблема с повторением последнего полученного значения. Так становится сложнее отслеживать события получения метрик и их задержки, а в конечном счёте мы получаем нереалистичные данные. В самом простом варианте наша система выглядит так:

Коллекторы располагаются рядом с системой, которую необходимо мониторить. Далее Prometheus забирает из них данные для хранения и дальнейшей передачи в мониторинг. Коллектор — это наша собственная разработка для сбора метрик. Он умеет собирать и агрегировать любые JMX‑метрики, преобразовывать их и выполнять математические операции. Кроме этого, реализована возможность выставлять метрики в формате Prometheus и отправлять данные в Kafka. Коллекторы специально разработаны для снятия нагрузки с системы мониторинга, что позволяет брать на обслуживание порядка 200 000 метрик на одну инсталляцию.

Что делает «классический» Prometheus, когда ему не удаётся обновить метрику? Кажется, что в этом случае нужно записать пустое значение. На практике Prometheus поступает по‑другому. Он начинает дублировать последнее полученное значение и делает это, по данным наших тестов, четыре с половиной минуты — можно успеть False Alarm послушать. Только после «антракта» система покажет, что значений по данной метрике больше нет.

На графике видно, что метрика активно изменяется, но после отключения системы (белая вертикальная линия на графике) начинают появляться статичные значения. Метрике нужно время, чтобы исчезнуть полностью.

Почему всё именно так

Система позволяет избежать ситуаций, когда есть кратковременные проблемы в получении метрик в Prometheus: например, сетевая недоступность или та же перезагрузка источника метрик. Позиция разработчиков Prometheus в этом вопросе непоколебима, как и их график после недоступности метрик. Кажется, что несколько пропусков в получении не может считаться поводом для реагирования. При этом нет никаких настроек для изменения такого поведения. На самом же деле для сервисов, которым важна высокая доступность, это может быть узким местом. Мы хотим знать всё, что происходит с системой, которую мониторим максимально подробно, достоверно и быстро, поэтому надеемся только на себя. Чтобы решить проблему с задержкой, нужно разобраться в возможных причинах. Распределим их на две категории:

1. Реальная недоступность системы, которую мы мониторим. Например, обновление, перезагрузка, инфраструктурные работы в системе или её реальная неисправность. Обо всех этих случаях должны узнать администраторы через нашу систему мониторинга.

1. Проблемы в работе самой системы мониторинга или инфраструктурные работы в системе мониторинга. Об этом должны узнать наши администраторы и не должны беспокоиться администраторы систем, которые мы мониторим. Чтобы добиться такого поведения, мы отслеживаем состояние доступности всех компонентов системы.

Проверка по часовой

Мониторинг отслеживает состояние Prometheus и через метрики самих коллекторов мониторит их состояния. Коллекторы, в свою очередь, могут отслеживать доступность самого инструмента. При этом у нас реализовано георезервирование всех компонентов. Выглядит это вот так:

При недоступности коллектора или ядра Prometheus мы автоматически переключаемся на резервные. Это обеспечивает непрерывность сбора и анализа всех метрик. Период настраиваемый и составляет порядка 30 секунд по умолчанию. В первую очередь наш сервис «Маяк» обрабатывает собственные метрики, которые выставляют сами компоненты мониторинга. Их не так много, поэтому они не влияют на скорость обработки основных метрик. Во вторую очередь мы собираем данные сервисов. Так мы полностью отсеиваем все события, не относящиеся к работе объекта мониторинга, а администраторы системы никогда не получат ложные сообщения об ошибках.

Свет на маяке

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