Ставим мониторинг Prometheus + Grafana

 СЕРГЕЙ ЯРЕМЧУК, автор более 1000 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС, yaremchuk@samag.ru

Ставим мониторинг Prometheus + Grafana

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

Сложно представить современную сеть без системы мониторинга, позволяющего получить статистику о работе систем и выдать предупреждение в случае превышения значения параметра или недоступности сервиса. Этим теперь удивить кого-то сложно, но сегодня на одном физическом сервере может быть запущено несколько виртуальных машин и сотни контейнеров, а приложения уже не являются монолитными и используют десятки сервисов в своей работе. В итоге классической информации о загрузке процессора, потреблении памяти, свободном месте на диске и сетевой нагрузке явно недостаточно. Они могут быть свободными, а вот приложение явно подтормаживает. Предоставляемых метрик очень не хватает, и часто требуется большая гибкость в возможностях их отбора.

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

Проект Prometheus

Примерно с такой проблемой столкнулись разработчики музыкальной социальной сети SoundCloud, использовавшей микросервисы. Так, собственно, и стартовал проект Prometheus [1], выпущенный со временем под свободной лицензией Apache 2 License и хорошо зарекомендовавший себя благодаря гибкости и функциональности. Prometheus входит в Cloud Native Computing Foundation и его поддерживают разработчики Docker и Kubernetes.

В Prometheus используется так называемая децентрализованная самоуправляемая архитектура, позволяющая легко добавлять сервисы и серверы, которые контролируются с одной консоли. Запущенные на узле сервисы обнаруживаются автоматически, при помощи заранее подготовленных установок. Это очень упрощает администрирование, так как все запускается буквально несколькими командами. Основой является prometheus server, умеющий самостоятельно собирать, хранить метрики с локального сервера, а при помощи агентов и с удаленных.

Поддерживается оповещение и простые графики, которые, правда, больше подходят для быстрого визуального представления собранных метрик или при отладке. Для отбора событий из полученного набора, построения графиков иустановки оповещений используется гибкий язык запросов [2]. Доступно API, которое может быть использовано для визуализации собранных данных в сторонних приложениях, шаблоны консоли для визуализации нужных данных иконсольный клиент prometheus-cli.

Некоторое время проект разрабатывал собственный дашборд PromDash, но теперь он объявлен как deprecated, а сами разработчики рекомендуют для вывода графиков данных использовать систему анализа, визуализации и мониторинга Grafana [3], имеющую встроенную поддержку Prometheus (и не только).

Данные в Prometheus представляются в виде временных рядов c 64-битной точностью. Каждая метрика сохраняется в отдельный файл в виде имени и атрибутов:

<metric name>{<label name>=<label value>, ...}

Например:

per_cpu_pct_user{device="cpu9",host="Stage"} 2.56

Такое представление позволяет легко отбирать, обрабатывать данные и формировать отчеты. Метрики по умолчанию собираются с интервалом 10 минут, это снимает нагрузку с клиента, а так как не используется интерполяция данных (вычисляется случайная величина – квантиль), некоторые графики выглядят прямолинейными, хотя значения, в общем-то, чуть «гуляют». При необходимости это можно подстроить.

Информация от агентов передается при помощи HTTP. По умолчанию используется порт 9126, хотя в разных плагинах свой номер. То есть всегда можно просмотреть метрики при помощи curl (см. рис. 1):

$ curl http://localhost:9126/metrics

Рисунок 1. Метрики Prometheus

Кроме этого, проект предоставляет еще несколько элементов, в частности exporter, предназначенные для сбора метрик с хоста или определенных сервисов. Доступны для узла (node_exporter), MySQL, Memcached, HAProxy, Graphite, Consul, Blackbox, SNMP и других. Поддерживается агрегатор метрик StatsD, умеющий собирать метрики и хранить их в нужном формате. Компонент Alertmanager предназначен для оправки сообщений (email, PagerDuty, OpsGenie), кроме этого, есть плагин для Nagios. Еще один полезный компонент – Pushgateway является, по сути, прокси и позволяет собирать информацию от систем, включающихся в сеть периодически.

Написан на Go, доступны клиентские библиотеки, написанные на Go, Java, Python и Ruby и других языках. В сети очень легко найти клиентов сторонних разработчиков. Наверное, самым популярным из них является Telegraf [4] – приложение, позволяющее собирать данные с удаленного хоста и поддерживающее около 80 плагинов [5] для ввода метрик (Varnish, СУБД, Apache, nginx Docker, Kubernetes, logparser...). Изначально поддерживает метрики InfluxDB, которому передает их в корректном формате, но в комплекте 23 плагина вывода для самых разнообразных приложений (Prometheus, Elasticsearch, Graphite, OpenTSDB, файл...). И главное – плагины уже входят в состав Telegraf, т.е. нужно просто включить.

Большой плюс, что для подключения к Prometheus используется всего один порт, в который выводится информация со всех плагинов. Поэтому Telegraf проще в развертывании. К тому же он работает не только под Linux, но и подFree/Open/NetBSD, Windows, DragonFly и Darwin. Хотя некоторые плагины Telegraf (мне попался logparser, предназначенный для парсинга журналов) умеют отдавать данные только в стандарте InfluxDB, и, чтобы их видел Prometheus, выход необходимо доработать. Или как вариант использовать grok_exporter [7], который также умеет парсить журнал и формирует правильный для Prometheus вывод. Единственный его недостаток: он умеет парсить только один файл. Поэтому, если нужно проверять несколько журналов, придется использовать несколько процессов.

Статью целиком читайте в журнале «Системный администратор», №5 за 2017 г. на страницах 36-44.

PDF-версию данного номера можно приобрести в нашем магазине.

1. Сайт Prometheus – http://prometheus.io.
2. Язык запросов Prometheus – http://prometheus.io/docs/querying/basics.
3. Проект Grafana – https://grafana.com.
4. Документация Telegraf – https://docs.influxdata.com/telegraf/latest/introduction/getting_started.
5. Плагины Telegraf – https://github.com/influxdata/telegraf/tree/master/plugins.
6. Ссылка на GitHub Prometheus – https://github.com/prometheus.
7. Плагин grok_exporter – https://github.com/fstab/grok_exporter.
8. Плагины Grafana – https://grafana.com/plugins.

Комментарии могут оставлять только зарегистрированные пользователи