Как мы строили мониторинг на Prometheus, Clickhouse и ELK

Меня зовут Антон Бадерин. Я работаю в компании «Центр Высоких Технологий» и зан��маюсь системным администрированием. Неделю назад завершилась наша корпоративная конференция, где мы делились накопленным опытом с ИТ-сообществом Ижевска, нашего города. Я рассказывал про мониторинг веб-приложений.

Краеугольный камень, лежащий в основе любой системы мониторинга — решение задач бизнеса. Мониторинг ради мониторинга никому не интересен. А чего хочет бизнес? Чтобы все работало быстро и без ошибок. Бизнес хочет от нас проактивности, чтобы мы сами выявляли проблемы в работе сервиса и максимально быстро их устраняли. Это, по сути, и есть задачи, которые я решал весь прошлый год на проекте одного из наших заказчиков.

Проект — одна из крупнейших в стране программ лояльности. Мы помогаем розничным сетям увеличивать частоту продаж за счёт различных маркетинговых инструментов вроде бонусных карт. В общей сложности в проект входят 14 приложений, которые работают на десяти серверах.

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

В моём случаем прежде в основе системы мониторинга заказчика лежала Icinga. Она никак не решала указанные выше задачи. Часто клиент сам сообщал нам о проблемах и не реже нам просто не хватало данных, чтобы докопаться до причины.

Кроме того, было чёткое понимание бесперспективности её дальнейшего развития. Я думаю, те кто знаком с Icinga меня поймут. Итак, мы решили полностью переработать систему мониторинга веб-приложений на проекте.

Мы выбрали Prometheus, исходя из трех основных показателей:

Ранее мы логи не собирали и не обрабатывали. Недостатки ясны всем. Мы выбрали ELK, поскольку опыт работы с этой системой у нас уже был. Храним там только логи приложений. Основными критериями выбора стали полнотекстовый поиск и его скорость.

Изначально выбор пал на InfluxDB. Мы осознавали необходимость сбора логов Nginx, статистики из pg_stat_statements, хранения исторических данных Prometheus. Influx нам не понравился, так как он периодически начинал потреблять большое количество памяти и падал. Кроме того, хотелось группировать запросы по remote_addr, а группировка в этой СУБД только по тэгам. Тэги дороги (память), их количество условно ограничено.

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

Clickhouse удовлетворяет всем этим критериям, и о выборе мы ни разу не пожалели. Мы не пишем в него каких-то выдающихся объёмов данных (количество вставок всего около пяти тысяч в минуту).

NewRelic исторически был с нами, так как это был выбор заказчика. У нас он используется в качестве APM.

Мы используем Zabbix исключительно для мониторинга Black Box различных API.

Нам хотелось декомпозировать задачу и тем самым систематизировать подход к мониторингу.

Для этого я разделил нашу систему на следующие уровни:

Чем удобен такой подход:

Так как наша задача выявлять нарушения в работе системы, мы должны на каждом уровне выделить некий набор метрик, на которые стоит обращать внимание при написании правил алертинга. Далее пройдемся по уровням «VMS», «Операционная система» и «Системные сервисы, стек ПО».

Хостинг выделяет нам процессор, диск, память и сеть. И с первыми двумя у нас были проблемы. Итак, метрики:

CPU stolen time — когда вы покупаете виртуалку на Amazon (t2.micro, к примеру), следует понимать, что вам выделяется не целое ядро процессора, а лишь квота его времени. И когда вы её исчерпаете, процессор у вас начнут забирать.

Эта метрика позволяет отслеживать такие моменты и принимать решения. Например, надо ли взять тариф пожирнее или разнести обработку фоновых задач и запросов в API на разные сервера.

IOPS + CPU iowait time — почему-то многие облачные хостинги грешат тем, что недодают IOPS. Более того, график с низкими IOPS для них не аргумент. Поэтому стоит собирать и CPU iowait. С этой парой графиков — с низкими IOPS и высоким ожиданием ввода-вывода — уже можно разговаривать с хостингом и решать проблему.

Метрики операционной системы:

Также на уровне операционной системы у нас появляется такая сущность, как процессы. Важно выделить в системе набор процессов, которые играют важную роль в её работе. Если, к примеру, у вас есть несколько pgpool, то необходимо собирать информацию по каждому из них.

Набор метрик следующий:

Весь мониторинг у нас развернут в Docker, для сбора данных метрик мы используем Сadvisor. На остальн��х машинах применяем process-exporter.

У каждого приложения есть своя специфика, и сложно выделить какой-то набор метрик.

Универсальным набором являются:

Наиболее яркие примеры мониторинга данного уровня у нас — Nginx и PostgreSQL.

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

Мы видели высокую нагрузку на диски, но слоулоги ничего толком не показывали. Эту проблему мы решили с помощью pg_stat_statements, представления, в котором собирается статистика по запросам.

Это всё, что нужно админу.

Строим графики активности запросов на чтение и запись:

Всё просто и понятно, каждому запросу — свой цвет.

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

Лично я добавил request_time, upstream_response_time, body_bytes_sent, request_length, request_id.Строим графики времени ответа и количества ошибок:

Строим графики времени ответа и количества ошибок. Помните? я говорил про задачи бизнеса? Чтоб быстро и без ошибок? Мы уже двумя графиками эти вопросы закрыли. И по ним уже можно звонить дежурным админам.

Но осталась ещё одна проблема — обеспечить быстрое устранение причин инцидента.

Весь процесс от выявления до решения проблемы можно разбить на ряд шагов:

Важно, что мы должны это делать максимально быстро. И если на этапах выявления проблемы и отправки уведомления мы особо времени выиграть не можем — две минуты на них уйдут в любом случае, то последующие — просто непаханное поле для улучшений.

Давайте просто представим, что у дежурного зазвонил телефон. Что он будет делать? Искать ответы на вопросы — что сломалось, где сломалось, как реагировать? Вот каким образом мы отвечаем на эти вопросы:

Мы просто включаем всю эту информацию в текст уведомления, даем в нем ссылку на страницу в вики, где описано, как на эту проблему реагировать, как её решать и эскалировать.

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

Пара моментов.

Во-первых, пишите структурированные логи. Не надо включать контекст в текст сообщения. Это затрудняет их группировку и анализ. Logstash требует много времени, чтобы всё это нормализовать.

Во-вторых, правильно используйте severity-уровни. У каждого языка свой стандарт. Лично я выделяю четыре уровня:

Резюмирую. Нужно стараться выстраивать мониторинг именно от бизнес-логики. Стараться замониторить само приложение и оперировать уже такими метриками, как количество продаж, количество новых регистраций пользователей, количество активных в данный момент пользователей и так далее.

Если весь ваш бизнес — одна кнопка в браузере, необходимо мониторить, прожимается ли она, работает ли должным образом. Всё остальное не важно.

Если у вас этого нет, вы можете попытаться это наверстать в логах приложения, Nginx-логах и так далее, как это сделали мы. Вы должны быть как можно ближе к приложению.

Метрики операционной системы конечно же важны, но бизнесу они не интересны, нам платят не за них.

#мониторинг