Что такое гугл прометей
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: как это работает
IT-продукт без метрик — как корабль без руля и ветрил. Метрики нужно собирать, анализировать и только на основе их значений принимать решения. Поговорим о том, что такое Prometheus, как он собирает метрики и почему для этого не всегда подходят стандартные базы данных.
Как появился Prometheus
Управление бизнесом без знания цифр — невозможно. Для принятия взвешенных решений нужно знать ключевые бизнес-метрики: выручку, прибыль, количество заказов, количество активных пользователей, плюс как можно больше менее значимых параметров: распределение активности пользователей по регионам, самые популярные продукты на сайте, загрузка серверов. Только владея всей этой аналитической информацией можно понять, где вы находитесь в море бизнеса и куда нужно грести.
В 2012 году онлайн-платформа для распространения звуковых треков SoundCloud озадачилась поиском нового инструмента для аналитики. Взвесив все варианты и попробовав всё, что было на рынке в тот момент, в компании принялись за разработку своего решения.
В то время аналитические СУБД были либо слишком сложными, либо слишком ненадежными и медленными. В то же время начал набирать популярность язык Go. Система сбора метрик на Go могла стать на порядок круче аналогов, поэтому разработчики из SoundCloud решили написать собственный инструмент на нем.
Почему для сбора метрик нельзя использовать, скажем, MySQL?
Можно! Если у вас небольшой проект, малое количество значений в аналитике и данные редко обновляются — еще как можно. В остальных случаях стандартные СУБД не могут обеспечить нужной производительности и надежности. Все эти классные штуки типа индексов и транзакций, важные в других случаях, только замедляют работу базы данных, от которой требуется максимальная скорость и безотказность в записи метрик.
Поэтому для систем аналитики разработали концепцию time series database — систему хранения простых значений, привязанных к определенным моментам времени. У любой базы при таком подходе будет два измерения — момент времени и сами значения. Такой предельно простой подход к структуре хранимой информации позволяет заранее спланировать алгоритмы поиска и обработки значений, а также выжать максимальную скорость работы и надежность. Пространство состояний, в которых может находиться такая СУБД, предельно мало и хорошо описано.
Kubernetes: мониторинг c помощью Prometheus
Привет, Хабр!
Меня зовут Радик, Head of DevOps of AGIMA!
В этой статье я постарался показать, как можно использовать Prometheus в качестве системы мониторинга для микросервисной архитектуры. Подробно рассмотрел архитектуру Prometheus и взаимодействие его компонентов. Обозначил ключевые характеристики благодаря чему эта система получила такое широкое распространение в средах использующих контейнеризацию. Предупреждаю сразу: статья получилась довольно объемной. Эта статься будет полезна для начинающих DevOps специалистов, которые планируют или уже используют в своей работе Docker, Kubernetes. Итак, начнем!
Что такое Prometheus?
Prometheus — система мониторинга, разработанная специально для динамически изменяющейся среды. Кроме того, она может использоваться для традиционной инфраструктуры, например, на физических серверах с приложениями, развернутыми непосредственно на ОС. На сегодняшний день Prometheus занимает лидирующую позицию среди инструментов, применяемых в мире микросервисов. Чтобы понять, почему Prometheus пользуется такой популярностью, давайте рассмотрим несколько примеров.
В качестве среды для разворачивания системы будем использовать Kubernetes.
Цель — настроить в Prometheus мониторинг для Redis-кластера в Kubernetes. Графический интерфейс — Grafana. Для оповещения задействуем email и Slack.
Основные компоненты Prometheus
В центре Prometheus — сервер, который выполняет работу по мониторингу. Он состоит из следующих частей:
От теории к практике
Давайте развернем наш сервер Prometheus с помощью пакетного менеджера Helm.
Инструкция предназначена для инженеров, которые имеют базовые навыки работы с Kubernetes и может быть использована только в ознакомительных целях. Использование в продакшен данной конфигурации крайне не рекомендуется.
Для этого потребуются рабочий кластер Kubernetes и настроенный kubectl. Можно попробовать использовать кластер Kubernetes в MCS. Сервер Prometheus устанавливается достаточно просто:
В результате выполнения мы получаем:
Проверяем, все ли поды запущены:
При выводе Helm chart предлагает выполнить port-forward для pushgateway, чтобы получить доступ к интерфейсу Prometheus. Меняем component на server и выполняем:
Теперь открываем http://127.0.0.1:9090/ в браузере — и видим интерфейс Prometheus:
Итак, у нас есть сервер Prometheus, развернутый внутри кластера Kubernetes. Теперь давайте развернем Redis, который впоследствии и поставим на мониторинг в Prometheus. Для этого также используем Helm:
Параметры cluster.enabled и cluster.slaveCount определяют, что Redis будет развернут в режиме «кластер», и в этом кластере два пода будут работать как slave. В параметрах указываем: не использовать persistent volume для master и slave (persistence.enabled=false). Сейчас это нужно, чтобы продемонстрировать работу Redis. В продакшене будет необходимо сделать настройку persistent volume.
Проверяем, что все поды redis запущены:
Теперь, когда у нас развернуты Prometheus и Redis, нужно настроить их взаимодействие.
Targets и metrics
Prometheus-сервер может мониторить самые разные объекты — к примеру, Linux- и Windows-серверы. Это может быть база данных или приложение, которое предоставляет информацию о своем состоянии. Такие объекты в Prometheus называются targets. Каждый объект имеет так называемые единицы мониторинга. Для Linux-сервера это может быть текущая утилизация CPU, использование memory и диска. Для приложения — количество ошибок, количество запросов и время их выполнения. Эти единицы называются metrics и хранятся в TSDB.
Exporters
Prometheus получает метрики из указанных в его конфигурации источников в блоке targets. Некоторые сервисы самостоятельно предоставляют метрики в формате Prometheus, и для их сбора не нужно ничего дополнительно настраивать. Достаточно подключить Prometheus в конфигурации, как это сделано ниже:
Указываем серверу Prometheus забирать метрики из конечной точки: localhost:9090/metrics.
Для сервисов, которые не могут самостоятельно предоставлять метрики в формате Prometheus, нужно установить дополнительный компонент exporters. Обычно exporters — скрипт или сервис, который получает метрики от цели, конвертирует их формат, который «понимает» Prometheus, и предоставляет эти данные серверу по пути /metrics. Prometheus имеет большой набор готовых exporters для разных сервисов — эти компоненты можно использовать для HAProxy, Linux system, облачных платформ и др.
Redis и exporter
Давайте подключим exporter для нашего Redis-кластера. Сначала потребуется создать файл values.yaml со следующим содержанием:
Здесь параметры, которые использовались в командной строке для настройки Redis в режиме cluster, перенесены в yaml-файл. Для сбора метрик добавлено подключение redis-exporter.
Обновляем Redis с новыми параметрами:
Проверяем, что поды Redis запущены:
Теперь к каждому pod «привязан» дополнительный контейнер redis-exporter, который предоставляет доступ к метрикам Redis.
Добавлять снятие метрик для развернутых контейнеров redis-exporter в конфигурацию Prometheus не нужно, так как он по умолчанию содержит kubernetes_sd_configs (листинг представлен ниже). За счёт этого динамически подключается сбор метрик для вновь появившихся подов. Подробнее об этом можно прочитать в документации.
Давайте убедимся, что мы получаем данные о состоянии Redis. Для этого можно открыть интерфейс и ввести PromQL-запрос redis_up:
«
В отличие от других систем мониторинга, Prometheus не получает данные от целевых сервисов, а самостоятельно забирает с указанных в конфигурации endpoints — это одна из его важнейших характеристик. Когда вы работаете с большим количеством микросервисов, и каждый из них отправляет данные в систему мониторинга, вы можете столкнуться с риском отправки слишком большого количества данных на сервер Prometheus, а это может привести его выходу из строя. Prometheus предоставляет централизованное управление сбором метрик, т.е. вы самостоятельно решаете, откуда и как часто забирать данные. Еще одно преимущество использования Prometheus — возможность динамически получать источники данных с помощью функции service discovery, работа которой была продемонстрирована выше на примере Redis-подов.
Но бывает случаи, когда необходимо получать данные от источника временно, и у Prometheus нет необходимости забирать их с сервиса постоянно (например, запланированные задания по крону, снятие бэкапов и т.д.). Для таких случаев Prometheus предлагает pushgateway, чтобы сервисы могли отправлять свои метрики в базу данных Prometheus. Использование pushgateway — скорее исключение, чем правило, но о его возможности не стоит забывать.
Теперь, для того, чтобы наша система мониторинга стала полноценной, нужно добавить оповещения о выходе значений метрик за допустимые пределы.
Alertmanager и Alerting rules
За отправку предупреждений в Prometheus отвечает компонент AlertManager. В качестве каналов оповещения могут выступать: email, slack и другие клиенты. Для настройки оповещения необходимо обновить конфигурацию файла alertmanager.yml.
Создадим файл prometheus/values.yaml со следующим содержимым:
Slack_api_url должен содержать ключ, который можно получить на сайте Slack.
В поле channel указывается канал, на который будут приходить оповещения. В нашем случае это general. Остальные параметры отвечают за формат уведомлений.
Конфигурацию, описанную далее, можно найти в репозитории.
Для того, чтобы получить доступ к интерфейсу Alertmanager, выполним следующее:
Теперь в интерфейсе Alertmanager можно убедиться, что появилась конфигурация для отправки оповещения в канал Slack http://127.0.0.1:9093/#/status:
Далее нужно создать правила, по которым нотификация будет отправляться в Slack-канал.
Правила представляют собой значения метрик или их совокупности, объединенные логическим условием. При выходе значения метрики за допустимые пределы Prometheus обращается к Alertmanager, чтобы отправить нотификации по определенным в нем каналам. Например, если метрика redis_up вернет значение 0, сработает уведомление о недоступности того или иного узла кластера.
Добавляем в файл prometheus/values.yaml стандартные правила для сигнализации о проблемах в Redis:
Для проверки работы нотификации в Slack, изменим правило алерта redis_memory_usage:
Снова обновляем my-prometheus:
Redis_memory_usage перешел в статус «pending». Значение выражения для всех трех подов чуть больше 0.72. Далее уведомление проходит в Slack:
Теперь добавляем нотификацию по email. При этом конфигурация alermanager.yml изменится так:
В блок routes добавляем еще один путь для нотификации: receiver: email-alert. Ниже описываем параметры для email. В этом случае при том или ином событии мы получим уведомления одновременно в Slack и на email:
Blackbox exporter
Теперь рассмотрим, как в Prometheus добавляются targets на примере контейнера blackbox exporter, который позволяет организовать мониторинг внешних сервисов по протоколам HTTP(s), DNS, TCP, ICMP.
Для установки blackbox exporter используем Helm:
Проверяем, что поды blackbox exporter запущены:
Добавляем в файл prometheus/values.yaml следующую конфигурацию:
Указываем, откуда собирать метрики:
blackbox-exporter-prometheus-blackbox-exporter.monitoring.svc.cluster.local:9115/probe. В качестве targets указываем URL сервиса для мониторинга: https://example.org. Для проверки используется модуль http_2xx, который по умолчанию устанавливается в blackbox exporter. Конфигурация проверки:
Обновляем конфигурацию my-prometheus:
В интерфейсе Prometheus http://127.0.0.1:9090/targets проверяем, что у нас появилась конечная точка для сбора метрик:
Чтобы расширить область проверки, добавляем http_2xx_check-модуль, который, помимо валидации версии и статуса 200 http, будет проверять наличие заданного текста в теле ответа:
Обновляем конфигурацию blackbox-exporter/values.yaml:
Изменяем в файле prometheus/values.yaml модуль http_2xx на http_2xx_check:
Описания проверок, которые можно делать с blackbox exporter, приведены в документации.
Теперь добавим правила для сигнализации в Prometheus в файл prometheus/values.yaml:
И обновляем конфигурацию my-prometheus:
Для проверки можно изменить в blackbox-exporter/values.yaml значение текста для модуля http_2xx_check, который ищется в теле ответа, и обновить blackbox exporter. Должна сработать нотификация в Slack и Email.
Grafana
Настала очередь визуализации. Для отображения графиков будем использовать
Grafana.
Устанавливаем его уже привычным для нас образом с помощью пакетного менеджера Helm:
В параметрах указываем «не использовать persistent volume» (—set=persistence.enabled=false), чтобы только продемонстрировать работу grafana. В продакшн- среде нужно настроить хранилище, так как поды по своей природе эфемерны, и есть риск потерять настройки Grafana.
Должен получиться вот такой вывод:
Проверяем, что под Grafana запущен:
Перед тем как открыть интерфейс Grafana, нужно получить пароль от пользователя admin, сделать это можно так:
Затем «пробрасываем» порт Grafana:
Открываем http://127.0.0.1:9090/ в браузере и авторизуемся:
Для того чтобы Grafana могла получать значения метрик, хранящихся в базе данных Prometheus, необходимо подключить его. Переходим на http://127.0.0.1:8080/datasources и добавляем data source. В качестве TSDB выбираем Prometheus, который доступен в нашем кластере по адресу my-prometheus-server.monitoring.svc.cluster.local.
Должно получиться примерно так:
После добавления data source нужно добавить dashboard в Grafana — чтобы состояния показателей Redis-кластера отображались на графиках. Переходим на http://127.0.0.1:8080/dashboard/import и добавляем Итог:
После импорта получаем следующий dashboard с виджетами, которые отображают собранные метрики c кластера Redis:
Вы можете собирать такие дашборды самостоятельно или использовать уже готовые.
Вот, в принципе, и всё. Надеюсь, что сумел рассказать вам что-то новое. А главное — убедил, что пользоваться Prometheus просто и удобно!