что такое гугл прометей
Prometheus
Доброго всем. Делимся тут очень интересной статьёй, на которую натыкались в рамках подготовки нашего курса. Перевод идёт, как есть целиком (за исключением некоторых комментариев).
В двух словах — вступление о мониторинге и аппеляционности убеждений. Как многим известно, я сопровождаю Riemann — инструмент обработки потоков событий для мониторинга распределенных систем. В моей книге, посвященной мониторингу, я использовал Riemann, как основной инструмент для изучения новых подходов и паттернов мониторинга, и описал архитектуру whitebox-мониторинга (с выборочным blackbox-мониторингом), используя push модель.
Чтобы понять, о чем я вообще веду речь, объясним некоторые концепции. Blackbox-мониторинг отвечает за проверку внешних характеристик сервисов или приложений: возможно ли подключиться к открытому порту сервиса, возвращаются ли корректные данные или код ответа. Примером blackbox-мониторинга может служить ICMP-запрос и подтверждение получения ответа.
В свою очередь, whitebox-мониторинг сфокусирован на том, что происходит внутри сервиса или приложения. Приложение, обладающее соответствующим инструментарием, возвращает состояние самого себя или внутренних компонентов, результат выполнения транзакций или событий. Эти данные отвечают на вопрос “как работает приложение”, а не на вопрос “работает ли приложение”. Whitebox-мониторинг передает события, логи или метрики в специальный инструмент для мониторинга или предоставляет информацию наружу для последующего сбора инструментом мониторинга.
Большинство людей, занимающихся современным мониторингом, понимают, что в whitebox-мониторинг нужно вкладывать большие инвестиции. Информация, полученная изнутри приложения представляет ощутимо бОльшую ценность для бизнеса и эксплуатации, чем та, что получена на поверхности. Это совсем не значит, что blackbox-мониторинг — пустая трата ресурсов. Внешний мониторинг сервисов и приложений полезен, особенно для служб, которые находятся за пределами вашего контроля, или когда взгляд извне дает контекст, недоступный изнутри, например, касательно маршрутизации или проблем DNS.
В книге я фокусируюсь на работе с push-моделью, а не pull. Также много внимания в книге уделено преимуществам мониторинга на основе push-модели над pull-моделью. Многие (если не большинство) системы мониторинга построены именно на основе pull/polling-модели. В такой модели система опрашивает сервис или приложение, которое мониторит. В свою очередь в push-модели приложения и сервисы сами отправляют данные в систему мониторинга.
По множеству причин (некоторые из них не очевидны на первый взгляд) я предпочитаю push-модель. Но особенности обоих подходов зачастую не мешают реализации по ряду причин (например, из-за масштаба). А вероятность успеха никак не зависит от споров о реализации или инструментах. Я придерживаюсь мнения, что инструменты, в первую очередь, должны подходить именно вам, и нет смысла бездумно следовать тенденциям или догматизму.
Именно стремление не быть категоричным и недостаточность понимания различий сообществом воодушевили меня написать вводный туториал для одного из ведущих инструментов мониторинга на базе pull-модели: Prometheus. Он очень популярен, особенно в мире контейнеров и Kubernetes.
Знакомство с Prometheus
Prometheus разработан инженерами Soundcloud, ранее работавшими в Google. Он написан на Go, обладает открытым исходным кодом и разрабатывается при поддержке Cloud Native Computing Foundation. Источником вдохновения для проекта послужил Borgmon от Google.
Prometheus сфокусирован на whitebox-мониторинге. Он собирает time series данные, полученные из приложений и сервисов. Приложение предоставляет эти данные самостоятельно или через плагины, которые называются экспортеры (exporters).
Платформа Prometheus основывается на сервере, который собирает и хранит time series данные. Она обладает многомерной моделью временных рядов, объединяющую метрические имена и пары ключ/значение, называемые метками для метаданных. Time series данные хранятся на сервере, отдельные серверы автономны и не зависят от распределенного хранилища.
Платформа также содержит клиентские библиотеки и ряд экспортеров для специфических функций и компонентов. Например, экспортер StatsD, который преобразует time series данные StatsD в формат Prometheus. Кроме того, есть push-gateway для приема небольших объемов входящих данных и alert manager, который умеет обрабатывать уведомления, созданные триггерами или при превышении пороговых значений данных, собранных Prometheus. 
С более детальной архитектурой можно познакомиться в документации Prometheus.
Сервер Prometheus — бинарный файл с одноименным названием prometheus. Возьмем его последнюю версию и распакуем.
На официальном сайте также размещены различные дополнительные компоненты: alert manager для отправки уведомлений и экспортеры для разнообразных сервисов.
Бинарный файл prometheus, который мы только что распаковали, настраивается через YAML файл. Посмотрим, что он собой представляет:
В данном конфигурационном файле определены три YAML блока:
Глобальный
Первый блок global содержит глобальные настройки для управления поведением сервера.
scrape_interval задает интервалы между опросами приложения или сервиса, в нашем случае 15 секунд. Это разрешение шкалы данных, т. е. период времени, который покрывается каждой точкой данных.
evaluation_interval сообщает Prometheus, как часто обрабатывать данные согласно правилам. Правила бывают двух основных видов: правила записи и правила алерта. Правила записи позволяют заранее вычислить часто используемые и ресурсоемкие выражения и сохранить результат в виде новых time series данных. Правила алерта позволяют определять условия оповещений. Prometheus будет (пере-)проверять эти условия каждый 15 секунд.
В external_labels содержится список пар “ключ/значение” для меток, которые будут добавлены к любой метрике, существующей на сервере, например, при генерации предупреждения.
Файлы правил
Второй блок — rule_files, содержит в себе список файлов с правилами записи или алерта.
Конфигурация опросов
Последний блок scrape_configs показывает все цели, которые Prometheus будет опрашивать. Prometheus называет цели инстансами (instances), а группы инстансов — заданием (job). По умолчанию есть только одно задание — prometheus. Внутри него лежит static_config со списком инстансов (по умолчанию только один — сервер Prometheus). Он опрашивает порт 9090 localhost’а для получения метрик состояния самого сервера. Предполагается, что метрики находятся в /metrics, поэтому локально опрашивается адрес localhost:9090/metrics. Путь можно изменить с помощью опции metric_path.
Одинокий задание — довольно скучно, поэтому добавим еще одно для опроса локального демона Docker. Воспользуемся инструкцией в документации Docker и настроим демона, чтобы он отдавал метрики с адреса localhost:9323/metrics. А после, добавим еще одно задание с названием docker.
У задания есть имя и инстанс, который ссылается на адрес для получения метрик демона Docker. Путь по умолчанию снова /metrics.
Полный конфигурационный файл можно найти по ссылке.
Запустим сервер и посмотрим, что происходит.
У Prometheus есть встроенный интерфейс, где можно посмотреть результаты. Для этого нужно открыть в браузере http://localhost:9090/graph.
Появится список элементов и значений, например:
Эти элементы являются метриками, которые разделены дополнительными измерениями (они предоставляются метками метрик). Например, у метрики http_requests_total есть метка handler, которая содержит информацию о порождающем запрос процессе. Список метрик можно уменьшить, выбрав конкретные метрики, содержащие одну из этих меток.
Гибкость языка выражений, встроенного на сервер Prometheus, упрощает поиск и агрегирование метрик.
Мы использовали метку handler, чтобы выбрать метрики только для хендлера prometheus.
Дополнительно агрегируем метрики HTTP запросов. Допустим, необходимо посмотреть количество HTTP запросов за пять минут, разбитых по заданиям. Для этого уточним запрос:
Теперь выполним запрос, нажав Execute:
Дополнительно можно посмотреть график результатов, выбрав вкладку Graph:
На нем мы видим общее количество HTTP запросов за последние пять минут, сгруппированных по заданиям.
Мы можем сохранить эти запросы в качестве правил записи, обеспечивая их автоматическое выполнение и создание новой метрики из данного правила.
Для этого добавим файл в блок rule_files:
И пропишем следующее правило в файл first.rules:
Это создаст новую метрику job:http_requests_total:sum для каждого задания.
Теперь можно сделать график из метрики и добавить его в дашборд.
Предупреждения, как и агрегация, основываются на правилах. Чтобы добавить правило предупреждения, нужно прописать еще один файл в блок rule_files.
Создадим в файле second.rule новое правило, которое будет уведомлять о падении инстансов. Для этого используем одну из стандартных метрик для сбора: up — это метрика состояния, ее значение равно 1, если опрос успешен, и 0, если опрос потерпел неудачу.
Добавим правило алерта в файл правил. Выглядеть оно должно следующим образом:
Теперь, спустя пять минут после остановки демона Docker, Prometheus запустит наш алерт и отправит сообщение в диспетчер Alertmanager (который предварительно нужно установить и запустить отдельно, либо воспользоваться каким-то другим инструментом, например, Alerta tool). Текущие уведомления можно увидеть на дашборде во вкладке Alerts.
Prometheus — отличная платформа, которую легко установить и настроить. Конфигурация описывается в YAML, что упрощает использование подхода Infrastructure as Code (IaC). Мониторинг простых окружений становится безболезненным благодаря автономному серверу. К сожалению, не удалось найти много примеров для более сложных окружений, поэтому стоит потратить время на эксперименты и разные подходы, чтобы найти наиболее оптимальный способ.
Модель данных очень гибкая, особенно поражает легкость, с которой можно присваивать метки метрикам и производить по ним поиск. Я познакомился с большей частью клиентских библиотек и с несколькими экспортерами — ничего сверхсложного. Создание инструментов и генерация метрик не должна вызвать больших трудностей.
Встроенный интерфейс чистый и элегантный, а в совокупности с языком запросов, выглядит как подходящий инструмент для отладки или планирования ресурсов. Правила записи подходят для агрегации метрик.
Я немного изучил хранилище, безопасность, обнаружение серверов и прочие доступные интеграции — возможности выглядят всеобъемлющими. Быстрый поиск по GitHub показал внушительный набор инструментов, интеграций и примеров, которых для начала точно должно хватить.
У основной платформы есть достаточная документация, но для некоторых смежных проектов она довольно хаотичная и неполная. Хотя даже при ограниченном знании Prometheus, буквально за час мне удалось создать рабочую конфигурацию.
Распространение одного бинарного файла без скриптов инициализации или пакетирования нельзя назвать решением, готовым к использованию из коробки, но, тем не менее, это рабочее решение для многих проектов. Также существуют различные подготовительные скрипты среди систем управления конфигурации, которыми можно воспользоваться. Тем не менее, большинство исследующих инструменты вроде Prometheus’а скорее всего справятся с установкой самостоятельно. Поддержка контейнеров и Kubernetes привлекательна для людей, пользующихся этими инструментами. А исследователей (микро-)сервисов и динамических или облачных стеков заинтересует автономность и портативность сервера.
Если у вас есть проект, где нужно реализовать мониторинг, я рекомендую Prometheus. Он также стоит потраченного времени, если ваша деятельность связана с контейнерами и инструментами вроде Docker и Kubernetes. Благодаря своей гибкости он подходит для таких инструментов и архитектур гораздо лучше других существующих платформ.
Мониторинг сервисов с Prometheus
В предыдущих публикациях мы уже затрагивали вопросы мониторинга и сбора метрик. В сегодняшней статье мы хотели бы вернуться к этой теме и рассказать об интересном инструменте под названием Prometheus. Он был создан в 2012 году в качестве внутренней системы мониторинга небезызвестного проекта SoundCloud, но впоследствии получил более широкое распространение.
Prometheus — инструмент совсем новый (первый публичный релиз состоялся в начале 2015 года), и на русском языке публикаций о нём пока почти что нет (несколько месяцев назад была опубликована статья в журнале «Хакер», но она доступна только подписчикам).
Разработчики SoundCloud отмечают (см. подробный доклад здесь), что новый инструмент мониторинга понадобился им в связи с переходом к микросервисной архитектуре. Рост интереса к микросервисам — одна из характерных тенденций последних нескольких лет.
С точки зрения микросервисного подхода приложение пониматеся не как монолит, а как набор сервисов. Каждый из этих сервисов работает в своём процессе и взаимодействует с окружением при помощи простого механизма (как правило, через протокол HTTP).
Мониторинг микросервисов — задача непростая: в режиме реального времени нужно отслеживать как состояние отдельных компонентов, так и состояние системы в целом. Задача усложняется, если помимо технических нужно проверять ещё и бизнес-значимые показатели. Как отмечают сами разработчики Prometheus в многочисленных статьях и докладах, с помощью имеющихся систем мониторинга её решить проблематично. Поэтому они создали собственный инструмент.
Prometheus представляет собой комплексное решение, в состав которого входят и фреймворк для мониторинга, и собственная темпоральная база данных. В некоторых обзорах его даже называют «системой мониторинга нового поколения».
Публикации о Prometheus нас заинтересовали, и мы решили познакомиться с этим инструментом поближе.
Архитектура Prometheus
В состав Prometheus входят следующие компоненты:
Большинство из них написаны на Go, а совсем небольшая часть — на Ruby и Java.
Все компоненты Prometheus взаимодействуют между собой по протоколу HTTP:
Главный компонент всей системы — сервер Prometheus. Он работает автономно и сохраняет все данные в локальной базе данных. Обнаружение сервисов происходит автоматически. Это упрощает процедуру развёртывания: для наблюдения за одним сервисом не нужно разворачивать распределённую систему мониторинга; достаточно установить только сервер и необходимые компоненты для сбора и экспорта метрик. Таких компонентов, «заточенных» под конкретные сервисы, уже создано довольно много: для Haproxy, MySQL, PostrgreSQL и другие (полный список см. здесь, а также на GitHub).
Сбор метрик в Prometheus осуществляется с помощью механизма pull. Имеется также возможность сбора метрик с помощью механизма push (для этого используется специальный компонент pushgateway, который устанавливается отдельно). Это может понадобиться в ситуациях, когда сбор метрики с помощью pull по тем или иным причинам невозможен: например, при наблюдении за сервисами, защищёнными фаерволлом. Также механизм push может оказаться полезным при наблюдении за сервисами, подключающихся к сети периодически и на непродолжительное время.
Prometheus хорошо подходит для сбора и анализа данных, представленных в виде временных рядов (time series). Все метрики он хранит в собственной темпоральной БД (её сравнение с OpenTSDB и InfluxDB см. здесь); для хранения индексов используется LevelDB.
Модель данных
Prometheus хранит данные в виде временных рядов — наборов значений, соотнесённых с временной меткой (timestamp).
Элемент временного ряда (измерение) состоит из имени метрики, временной метки и пары «ключ — значение». Временные метки имеют точность до миллисекунд, значения представлены с 64-битной точностью.
Имя метрики указывает на параметр системы, о котором собираются данные. Например, у метрики с информацией о количестве HTTP-запросов к некоему API имя может выглядеть так: api_http_requests_total. Временной ряд в такой метрике может хранить информацию о обо всех GET-запросах на адрес /api/tracks, на которые был отдан ответ с кодом 200. Этот временной ряд можно представить в виде следующей нотации:
Модель данных, используемая в Prometheus, напоминает ту, что используется в OpenTSDB. У всех метрик есть имя, но оно может быть одним и тем же у нескольких рядов.
При этом каждый временной ряд должен быть помечен хотя бы одним тэгом. Измерения для одного тэга хранятся последовательно, что обеспечивает быструю агрегацию данных.
Поддерживаются следующие типы метрик:
Установка
Рассмотрим теперь практические аспекты использования Prometheus. Начнём с описания процедуры установки.
Совсем недавно Prometheus был включён в официальные репозитории Debian 8 и Ubuntu 15.10.
В Ubuntu 14.04 его тоже можно установить при помощи стандартного менеджера пакетов. Естественно, для этого понадобится подключить соответствующий репозиторий:
С помощью приведённых команд мы установили сервер Prometheus, а также дополнительные компоненты — node_exporter и alertmanager. Node_exporter собирает данные о состоянии сервера, а alertmanager (о нём мы более подробно поговорим ниже) — рассылает уведомления в случае выполнения или невыполнения заданных условий.
Установка завершена, но остался ещё один маленький штрих: нужно сделать так, чтобы node_exporter постоянно собирал метрики в фоновом режиме. Для этого сначала создадим символическую ссылку в /usr/bin:
Затем создадим файл /etc/init/node_exporter.conf и добавим в него следующие строки:
Сохраним внесённые изменения и выполним команду:
В дистрибутивах, перешедших на systemd (например, в Ubuntu 15.10), для запуска node_exporter в фоновом режиме нужно создать файл /etc/systemd/system/node_exporter.service и добавить в него следующие строки:
Сохранив внесённые изменения, нужно выполнить команды:
Конфигурирование
Настроек Prometheus по умолчанию вполне достаточно, чтобы следить за всем происходящим на локальной машине. Дополнительные настройки в случае необходимости всегда можно прописать в конфигурационном файле /etc/prometheus/prometheus.yml. Рассмотрим его структуру более подробно. Начинается он с секции globals:
Она включает следующие параметры:
Далее следует секция scrape_configs с базовыми настройками сбора метрик на сервере:
В этой же секции можно прописать дополнительные настройки:
Выше мы уже упомянули о том, что в конфигурационном файле можно ссылать на файлы правил. Правила помогают предварительно вычислять наиболее часто используемые или требующие значительных затрат ресурсов параметры и сохранять их в виде новых временных рядов. Осуществлять поиск по предварительно рассчитанным параметрам значительно проще, чем при каждом запросе заново вычислять их значения. Это может оказаться полезным, например, при работе с дашбордами, которые запрашивают значения параметров при каждом обновлении.
В общем виде синтаксис правил можно представить так:
Приведём более конкретные и понятные примеры:
Prometheus сверяется с правилами с определённой периодичностью, указанной в конфигурационном файле в параметре evaluation_interval). После каждой сверки Prometheus пересчитывает значение параметра и сохраняет его под новым именем с текущей временной меткой.
Итак, структуру и синтаксис конфигурационного файла мы в общих чертах рассмотрели. Чтобы прописанные настройки вступили в силу, нужно выполнить следующую команду (вместо path/to/prometheus.yml указываем путь к конфигурационному файлу):
Веб-интерфейс
Веб-интерфейс Prometheus будет доступен в браузере по адресу: http://[IP-адрес сервера]:9090:
В поле Expression можно выбрать метрику, для которой будет отображаться график. Попробуем отследить, например, объём активной памяти на сервере. Выбираем метрику node_memory_active и нажимаем на кнопку Execute:
Над графиком расположены кнопки, с помощью которых можно выбирать период для отображения статистики.
Шаблоны консолей
Если вам не подходит ни одна из имеющихся консолей, вы можете создать собственную консоль, которая будет отображать нужную вам статистику. Для написания консолей в Prometheus используется HTML-шаблонизатор Go. Подробные инструкции по созданию кастомных консолей приведены в официальной документации.
А если вас по тем или иным причинам не устраивают имеющиеся консоли, вы можете интегрировать Prometheus с популярным инструментом Grafana.
Разработчики Prometheus создали и собственный инструмент для создания дашбордов под названием Promdash (см. также репозиторий на GitHub), по интерфейсу напоминающий Grafana. На наш взгляд, он ещё находится в несколько «сыром» состоянии, и рекомендовать его к использованию пока что рано.
Alertmanager: настройка уведомлений
Ни один инструмент мониторинга немыслим без компонента для рассылки уведомлений. В Prometheus для этой цели используется alertmanager. Настройки уведомлений хранятся в конфигурационном файле alertmanager.conf.
Рассмотрим следующий фрагмент:
Его синтаксис вполне понятен: мы указали, что уведомления при наступлении определённого условия нужно отправлять по электронной почте на адрес test@example.org.
В конфигурационный файл можно добавлять ссылки на файлы правил (по сути они ничем не отличаются от файлов правил для сбора метрик, описанных выше). В правилах прописываются условия, при которых нужно отправлять уведомления.
В общем виде синтаксис правила выглядит так:
Рассмотрим функции правил на более конкретных примерах.
Пример1:
Это правило указывает, что уведомление нужно отправлять в случае, если некоторый инстанс недоступен в течение 5 минут и более.
Согласно этому правилу, уведомления нужно посылать, как только среднее время ответа на запросы к API превысит 1 мс.
Чтобы прописанные в конфигурационном файле настройки вступили в силу, нужно сохранить его и выполнить команду:
Можно создать несколько конфигурационных файлов и прописать в них настройки уведомлений для различных случаев.
Уведомления Prometheus отправляет в формате JSON. Выглядят они примерно так:
Отправка уведомлений осуществляется по электронной почте, через веб-хук, а также с помощью специализированных сервисов: PagerDuty, HipChat и других.
Разработчики Prometheus отмечают, что пока что alertmanager находится в «сыром» состоянии и предупреждают о возможных ошибках. Впрочем, мы никаких аномалий в работе этого компонента не заметили.
Заключение
Prometheus — инструмент достаточно интересный и перспективный, и на него стоит обратить внимание. В числе его преимуществ нужно в первую очередь выделить:
Если у вас уже есть практический опыт использования Prometheus, поделитесь впечатлениями. Будем благодарны за любые полезные замечания и дополнения.
Для желающих узнать больше приводим несколько полезных ссылок:
Если вы по тем или иным причинам не можете оставлять комментарии здесь — приглашаем в наш блог.
Полное руководство по Prometheus в 2019 году
DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.
Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. У него полностью открытый исходный код, он предоставляет десятки разных экспортеров, с помощью которых можно за считанные минуты настроить мониторинг всей инфраструктуры.
Prometheus обладает очевидной ценностью и уже используется новаторами в отрасли, вроде DigitalOcean или Docker, как часть системы полного мониторинга.
Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?
Если вы совсем ничего не знаете о Prometheus или хотите лучше разобраться в нем, в его экосистеме и всех взаимодействиях, эта статья как раз для вас.
Мы разделили это руководство на 3 части, как поступили с InfluxDB.
Часть I. Что такое Prometheus?
Prometheus — это база данных временных рядов. Если вы не в курсе, что такое база данных временных рядов, почитайте первую часть руководства по InfluxDB.
Но Prometheus — не просто база данных временных рядов.
К нему можно присоединить целую экосистему инструментов, чтобы расширить функционал.
Prometheus мониторит самые разные системы: серверы, базы данных, отдельные виртуальные машины, да почти что угодно.
Для этого Prometheus периодически скрейпит свои целевые объекты.
Что такое скрейпинг?
Prometheus извлекает метрики через HTTP-вызовы к определенным конечным точкам, указанным в конфигурации Prometheus.
Возьмем, например, веб-приложение, расположенное по адресу http://localhost:3000. Приложение передает метрики в текстовом формате на некоторый URL. Допустим, http://localhost:3000/metrics.
По этому адресу Prometheus с определенными интервалами извлекает данные из целевого объекта.
1. Как работает Prometheus?
Как мы уже сказали, Prometheus состоит из самых разных компонентов.
Во-первых, вам нужно, чтобы он извлекал метрики из ваших систем. Тут есть разные способы:
Как вы уже поняли, Prometheus сам собирает данные (исключая редкие случаи, когда мы используем Pushgateway).
Что это значит?
Зачем это нужно?
2. Сбор vs. отправка
У Prometheus есть заметное отличие от других баз данных временных рядов: он активно сканирует целевые объекты, чтобы получить у них метрики.
InfluxDB, например, работает иначе: вы сами напрямую отправляете ему данные.
Оба подхода имеют свои плюсы и минусы. На основе доступной документации мы составили список причин, по которым создатели Prometheus выбрали такую архитектуру:
Prometheus сам решает, где и как часто проводить скрейпинг.
Если объекты сами отправляют данные, есть риск, что таких данных будет слишком много, и на сервере произойдет сбой. Когда система собирает данные, можно контролировать частоту сбора и создавать несколько конфигураций скрейпинга, чтобы выбирать разную частоту для разных объектов.
Это дополнение к первой части, где мы обсуждали роль Prometheus.
Prometheus не основан на событиях и этим сильно отличается от других баз данных временных рядов. Он не перехватывает отдельные события с привязкой ко времени (например, перебои с сервисом), а собирает предварительно агрегированные метрики о ваших сервисах.
Если конкретно, веб-сервис не отправляет сообщение об ошибке 404 и сообщение с причиной ошибки. Отправляется сообщение о факте, что сервис получил сообщение об ошибке 404 за последние пять минут.
Это главное различие между базами данных временных рядов, которые собирают агрегированные метрики, и теми, что собирают необработанные метрики.
3. Развитая экосистема Prometheus
По сути Prometheus — база данных временных рядов.
Но при работе с такими базами данных часто нужно визуализировать данные, анализировать их и настраивать по ним оповещения.
Prometheus поддерживает следующие инструменты, расширяющие его функционал:
Часть II. Концепции Prometheus
Как и в руководстве по InfluxDB, мы подробно разъясним технические термины, связанные с Prometheus.
1. Модель данных «ключ-значение»
Прежде чем перейти к инструментам Prometheus, важно полностью разобраться в этой модели данных.
Prometheus работает с парами «ключ-значение». Ключ описывает, что мы измеряем, а значение хранит фактическую величину в виде числа.
Помните: Prometheus не создан для хранения необработанной информации, вроде обычного текста. Он хранит метрики, агрегированные за период времени.
Ключом в данном случае называется метрика. Это, например, скорость процессора или занятый объем памяти.
Но что если нужно больше деталей о метрике?
Например, у процессора 4 ядра, и нам нужно 4 отдельных метрики?
И здесь на помощь приходят ярлыки. Ярлыки дают больше сведений о метриках, добавляя дополнительные поля. Например, вы описываете не просто скорость процессора, а скорость одного ядра по определенному IP.
Потом вы сможете фильтровать метрики по ярлыкам и просматривать только нужную информацию.
2. Типы метрик
При мониторинге с Prometheus метрики можно описать четырьмя способами. Лучше дочитайте до конца, потому что здесь есть подводные камни.
Счетчик
Это, наверное, самый простой тип метрик. Счетчик, как понятно из названия, считает элементы за период времени.
Если вы хотите посчитать, например, ошибки HTTP на серверах или посещения веб-сайта, используйте счетчик.
И по логике, разумеется, счетчик может только увеличивать или обнулять число, поэтому не подходит для значений, которые могут уменьшаться, или для отрицательных значений.
С его помощью особенно удобно считать количество наступлений определенного события за период времени, т. е. показатель изменения метрики со временем.
А если нужно измерить, допустим, используемую память за определенный период?
Эта величина может уменьшаться. Как посчитать ее с Prometheus?
Измерители
Знакомьтесь — измерители!
Измерители имеют дело со значениями, которые со временем могут уменьшаться. Их можно сравнить с термометрами — если посмотреть на термометр, увидим текущую температуру.
Но если измерители могут увеличиваться и уменьшаться и принимать положительные и отрицательные значения, то выходит, они лучше счетчиков?
Значит, счетчики — бесполезны?
Поначалу и я так думал. Раз они могут все, давайте использовать их везде. Логично?
А вот и нет.
Измерители идеально подходят для измерения текущего значения метрики, которое со временем может уменьшиться.
Вот тут-то и кроются те самые подводные камни: измеритель не показывает развитие метрики за период времени. Используя измерители, можно упустить нерегулярные изменения метрики со временем.
Почему? Вот что говорит /u/justinDavidow:
«Измеритель показывает среднее значение дельты счетчика для единицы за период времени.
Счетчик учитывает каждую использованную единицу (если это процессор, то операции, циклы или такты), а потом вы можете выбрать, показатели за какой период вам нужны.
Если вы используете измеритель, частота выборки должна быть точной. Если частота отличается хотя бы на несколько микросекунд, значение будет недостоверным. Это еще более заметно при большой нагрузке, где время между измерениями возрастает в геометрической прогрессии, потому что планировщик системы не успевает уделять внимание приложению мониторинга».
Если система отправляет метрики каждые 5 секунд, а Prometheus скрейпит целевой объект каждые 15, в процессе можно потерять некоторые метрики. Если выполнять дополнительные вычисления с этими метриками, точность результатов окажется еще ниже.
У счетчика каждое значение агрегировано. Когда Prometheus собирает его, он понимает, что значение было отправлено в определенный интервал.
Теперь не запутаетесь.
Гистограмма
Гистограмма — это более сложный тип метрики. Она предоставляет дополнительную информацию. Например, сумму измерений и их количество.
Значения собираются в области с настраиваемой верхней границей. Поэтому гистограмма может:
В реальном мире я бы хотел получать оповещение, если у 20% моих серверов отклик больше 300 мс или отклик серверов больше 300 мс более 20% времени.
Если вы имеете дело с пропорциями, вам нужны гистограммы.
Сводки
Сводки — это расширенные гистограммы. Они тоже показывают сумму и количество измерений, а еще квантили за скользящий период.
Квантили, если что, — это деление плотности вероятности на отрезки равной вероятности.
Итак: гистограммы или сводки?
Все зависит от намерения.
Гистограммы объединяют значения за период времени, предоставляя сумму и количество, по которым можно отследить развитие определенной метрики.
Сводки, с другой стороны, показывают квантили за скользящий период (т. е. непрерывное развитие во времени).
Это особенно удобно, если вам нужно узнать значение, которое представляет 95% значений, записанных за период.
3. Задания и экземпляры
Учитывая последние успехи в распределенных архитектурах и популярность облачных решений, вряд ли вы используете одинокий сервер, работающий сам по себе.
Серверы реплицируются и распределяются по всему миру.
Чтобы это проиллюстрировать, давайте рассмотрим классическую архитектуру из двух серверов HAProxy, которые перераспределяют нагрузку по девяти бэкенд-веб-серверам (Нет-нет, никаких стеков Stackoverflow.)
В этом примере из реальной жизни мы отследим число ошибок HTTP, возвращенных веб-серверами.
На языке Prometheus один веб-сервер называется экземпляром. Заданием будет тот факт, что вы измеряете число ошибок HTTP на всех экземплярах.
Прелесть в том, что задания и экземпляры — это поля в ярлыках, и вы можете фильтровать результаты по определенному экземпляру или заданию.
Удобно же?
4. PromQL
Если вы используете базы данных на основе InfluxDB, вы, наверное, уже знакомы с InfluxQL. Или используете SQL в TimescaleDB.
У Prometheus тоже есть свой язык для запросов и извлечения данных с серверов: PromQL.
Как мы уже знаем, данные представлены в виде пар «ключ-значение». PromQL использует тот же синтаксис и возвращает результаты в виде векторов.
В Prometheus и PromQL есть два вида векторов:
PromQL API предоставляет набор функций для операций с данными в запросах.
Вы можете сортировать значения, применять к ним математические функции (например, рассчитывать производные или экспоненты) и даже строить прогнозы (например, по модели Хольта-Уинтерса).
5. Инструментирование
Инструментирование — это еще одна важная часть Prometheus. Вы инструментируете приложения, прежде чем извлекать из них данные.
На языке Prometheus инструментирование означает добавление клиентских библиотек в приложение, чтобы они предоставляли метрики Prometheus.
Инструментирование доступно для большинства распространенных языков программирования: например, Python, Java, Ruby, Go и даже Node или C#.
По сути, вы создаете объекты памяти (например, измерители или счетчики), которые будут динамически увеличивать или уменьшать значение.
Потом вы выбираете, где предоставлять метрики. Prometheus заберет их оттуда и сохранит в свою базу данных временных рядов.
6. Экспортеры
В написанных вами приложениях очень удобно настраивать предоставляемые метрики и их изменение со временем с помощью инструментирования.
Для известных приложений, серверов и баз данных Prometheus предлагает экспортеры, с помощью которых можно мониторить целевые объекты.
Эти экспортеры обычно представлены в виде образов Docker и легко настраиваются. Они предоставляют готовый набор метрик и часто готовые панели мониторинга, с которыми можно настроить мониторинг за считанные минуты.
Пара слов о взаимной совместимости
Большинство баз данных временных рядов поддерживают взаимную совместимость для своих систем.
Prometheus не единственная система мониторинга со своими требованиями к предоставлению метрик. Например, у InfluxDB (через Telegraf), CollectD, StatsD и Nagios тоже есть свои стандарты.
Поэтому для взаимодействия разных систем создаются экспортеры. Даже если Telegraf отправляет метрики не в том формате, который принимает Prometheus, Telegraf может послать эти метрики в экспортер InfluxDB, откуда их потом заберет Prometheus.
7. Оповещения
При работе с базами данных временных рядов вам нужна обратная связь от данных, и за это отвечают менеджеры оповещений.
В Grafana оповещения обычное дело, но они доступны и в Prometheus через менеджер оповещений.
Менеджер оповещений — это отдельный инструмент, который присоединяется к Prometheus и запускает кастомные оповещатели.
Оповещения определяются в файле конфигурации и задают набор правил для метрик. Если во временных рядах возникает соответствие правилу, оповещение инициируется и отправляется заданным получателям.
Как и в Grafana, в качестве получателя можно указать электронный адрес, вебхук Slack, PagerDuty и кастомные HTTP-объекты.
Часть III. Примеры использования Prometheus
И, конечно, в каждом руководстве должны быть практические примеры. Как я люблю говорить, технология — не самоцель и должна выполнять определенную задачу.
Об этом и поговорим.
1. DevOps
Со всеми этими экспортерами для разных систем, баз данных и серверов очевидно, что Prometheus предназначен, в основном, для сферы DevOps.
Мы знаем, что в этой сфере множество конкурирующих поставщиков и персонализированных решений.
Prometheus идеально подходит для DevOps.
Для настройки и запуска экземпляров почти не требуется усилий, и можно легко активировать и настроить любой вспомогательный инструмент.
Благодаря обнаружению целевых объектов — например, через файловый экспортер, —это отличное решение для стеков, где широко используются контейнеры и распределенные архитектуры.
В среде, где экземпляры то и дело создаются и удаляются, ни один стек DevOps не обойдется без обнаружения сервисов.
2. Здравоохранение
Сегодня решения для мониторинга нужны не только в ИТ. Они используются и в крупных отраслях, которые предоставляют гибкие и масштабируемые архитектуры для здравоохранения.
Спрос растет, и ИТ-архитектуры обязаны ему соответствовать. Если у вас нет надежного инструмента для мониторинга всей инфраструктуры, вы рискуете столкнуться с серьезными перебоями в обслуживании. Уж в сфере здравоохранения такую опасность точно надо свести к минимуму.
3. Финансовые услуги
Последний пример приводился на конференции InfoQ, где обсуждалось использование Prometheus в финансовых учреждениях.
Джейми Кристиан (Jamie Christian) и Алан Стрейдер (Alan Strader) показывали, как они используют Prometheus для мониторинга своей инфраструктуры в Northern Trust. Очень содержательно, советую посмотреть.
Часть X. Что дальше?
Пора переходить от теории к практике.
Сегодня вы познакомились с основами Prometheus, узнали, какие функции он выполняет, с какими инструментами и системами работает и какие термины использует.
Теперь у вас есть все необходимое, чтобы создать свое решение для мониторинга.
Чтобы приступить к работе с Prometheus, изучите все доступные экспортеры.
Потом установите нужные инструменты, создайте свою первую панель мониторинга — и вперед!
Если вам нужно вдохновение, почитайте мою статью о том, как мониторить машину Linux с Prometheus и Grafana. Там есть инструкции по настройке инструментов и первой панели мониторинга.
Надеюсь, вы узнали что-то новое.
Если у вас есть тема для моей следующей статьи, поделитесь.