prometheus что это такое
Мониторинг с помощью Prometheus
Мониторинг приложений и серверов приложений — важная часть DevOps-культуры. Вы наверняка хотите постоянно мониторить состояние приложения и серверов, загрузку центрального процессора, потребление памяти, дисковую утилизацию и т.д. Также вы наверняка хотите получать уведомления, если у сервера заканчивается доступная память или приложение перестает отвечать на запросы, что позволит предотвратить проблемы.
Для мониторинга есть ряд бесплатных и платных инструментов, таких как Amazon CloudWatch, Nagios, New Relic, Prometheus, Zabbix и другие. В этом посте мы рассмотрим Prometheus — инструмент для одновременного мониторинга десятков тысяч служб.
Что такое Prometheus и чем он отличается от других систем мониторинга?
Prometheus — популярный CNCF-проект с открытым исходных кодом, большая часть компонентов которого написана на Golang, а часть — на Ruby. Это означает, что у вас будет всего один бинарный файл, который нужно скачать и запустить вместе с компонентами Prometheus. Prometheus полностью совместим с Docker и доступен на Docker Hub. Для начала давайте рассмотрим основные компоненты Prometheus.
Компоненты Prometheus
Сервер Prometheus
Prometheus имеет центральный компонент, называемый Prometheus Server. Его основная задача — хранить и мониторить определенные объекты. Объектом может стать что угодно: Linux-сервер, сервер Apache, один из процессов, сервер базы данных или любой другой компонент системы, которую вы хотите контролировать. В терминах Prometheus главная служба мониторинга называется сервером Prometheus, а объекты мониторинга — целевыми объектами. Как я сказал ранее, целевым объектом может быть один сервер, или целевые объекты для проверки конечных точек через HTTP, HTTPS, DNS, TCP и ICMP (*Black-Box Exporter), или простая конечная точка HTTP, которую выдает приложение. Через конечную точку HTTP сервер Prometheus проверяет статус приложения.
Каждый элемент целевого объекта, который вы хотите мониторить (статус центрального процессора, память или любой другой элемент), называется метрикой. Таким образом, Prometheus собирает через HTTP метрики целевых объектов, хранит их локально или удаленно и отображает.
Вы запрашиваете у базы данных временных рядов Prometheus информацию о месте хранения метрик, используя язык запросов PromQL. Другими словами, с помощью PromQL вы просите сервер Prometheus показать статус конкретного целевого объекта в данный момент времени и получаете метрики.
Prometheus предоставляет клиентские библиотеки на нескольких языках, которые вы можете использовать для обеспечения работоспособности приложения. Но Prometheus — это не только мониторинг приложений. Вы можете использовать экспортеры (exporters) для мониторинга сторонних систем (таких как сервер Linux, демон MySQL и т.д.). Экспортер — часть программного обеспечения, которое получает существующие метрики от сторонней системы и экспортирует их в формат, понятный серверу Prometheus.
Примерной метрикой с сервера Prometheus может быть текущее использование свободной памяти или файловой системы через Node Exporter на сервере Prometheus.
Важно знать, что Prometheus использует стандартную модель данных с метрикой на основе ключа, которая может не совпадать с моделью сторонней системы Именно поэтому вы используете экспортеры для преобразования метрик. Я не буду вдаваться в подробности каждого синтаксиса показателей Prometheus и того, как они отличаются.
Уровень визуализации с Grafana
Вы можете использовать Grafana в качестве стороннего компонента для визуализации метрик, хранящихся в базе данных временных рядов Prometheus. Вместо того чтобы писать запросы PromQL непосредственно на сервер Prometheus, вы используете доски графического интерфейса Grafana для запроса метрик с сервера Prometheus и визуализации их на панели мониторинга Grafana.
Управление оповещениями с Prometheus Alert Manager
Prometheus имеет компонент управления оповещениями, называемый AlertManager. Он служит для запуска оповещений через Email, Slack или другие клиентские уведомления.
Настройка Prometheus в контейнерах Docker
Добавление Node Exporter
Следующее, что нужно сделать, — развернуть контейнер Node Exporter и прикрепить его к серверу Prometheus, как показано в следующем файле YAML:
Здесь вы добавили еще один сервис docker-compose под названием nodexporter. Как упоминалось выше, экспортер – часть программного обеспечения, которая переводит метрики из сторонней системы в метрический формат, понятняй Prometheus. Node Exporter экспортирует метрики ОС на сервер Prometheus, который получает и хранит их в базе данных временных рядов. Вы монтируете тома хост-системы и передаете пару флагов службе Node Exporter, чтобы помочь обнаружить информацию о хост-системе, используя точки монтирования procfs и sysfs. procfs и sysfs – файловые системы в Unix-подобных операционных системах, которые показывают в иерархической файловой структуре и каталогах информацию о процессах и другую системную информацию, такую как хранилище и т. д. Структура варьируется от дистрибутива к дистрибутиву. Вы монтируете эти каталоги хоста в виде volumes в сервис Node Exporter, чтобы Node Exporter мог видеть системную информацию узла и вы могли передавать некоторые флаги командной строки со значением местоположения этих каталогов в контейнер Node Exporter.
При запуске сервера Prometheus вы должны увидеть или выполнить запросы PromQL с префиксом node_ на сервере Prometheus. Запуск PromQL-запросов в Prometheus покажет информацию о процессах хоста, хранении и другие метрики.
Добавление визуализации с Grafana
Grafana — средство визуализации и мониторинга данных с поддержкой нескольких баз данных, включая TSDB Prometheus. С помощью Grafana вы можете создать графический пользовательский интерфейс для метрик, которые собираете на сервере Prometheus, как показано ниже:
Вы пишете запросы PromQL в элементах панели Grafana, а не на сервере Prometheus. Но Grafana вытаскивает метрики с сервера Prometheus с интервалом, который вы выбираете в верхнем правом углу панели мониторинга Grafana, и графически отображает их в своей панели мониторинга. Grafana запускается в контейнере Docker, поэтому добавьте службу Grafana в файл compose. Окончательный docker-compose файл выглядит так:
Перейдите на публичный IP-адрес системы с портом 3000 и вбейте admin: admin в качестве имени пользователя и пароля, чтобы увидеть статистику сервера в панели Grafana. Вы увидите что-то подобное:
Заключение
Вы увидели простейший пример того, как настроить сервер Prometheus с Node Exporter и Grafana для визуализации статистики сервера на Ubuntu 16.0. Вы можете хранить данные временного ряда Prometheus в стороннем хранилище, таком как InfluxDB, а не в локальной файловой системе. Важно отметить, что Prometheus не связан с логированием и трассировкой. Мы рассмотрели, как добавить компонент Prometheus Alert Manager в вышеуказанный стек для отправки оповещений по электронной почте или в Slack, если что-то идет не так, и как использовать service discovery в Prometheus.
Здесь вы можете найти полный исходный код. Также рекомендую прочитать документациюPrometheus, чтобы узнать больше о его компонентах и архитектуре.
Prometheus — практическое использование
Одной из важнейших задач при разработке приложений с микросервисной архитектурой является задача мониторинга. Слежение за состоянием сервисов и серверов позволяет не только вовремя реагировать на неисправности, но и анализировать их работу. Наличие такой информации трудно переоценить, ведь она предоставляет дополнительные возможности по улучшению производительности и качества работы Вашего ПО.
Знакомство с Prometheus
Всерьез с микросервисной архитектурой я столкнулся совсем недавно, начав работу с уже существующей инфраструктурой сервисов. Для слежения за состоянием серверов и сбора метрик использовался Zabbix. Конфигурацией Zabbix занимались администраторы и все изменения/добавления графиков должны были проходить через них. Такой подход позволяет разделить зону ответственности, особенно в случаях, когда одной системой мониторинга пользуются разные команды разработчиков. Но, в то же время, приводит к задержке или неточностям при добавлении новых графиков, ведь администратор может не обратить внимание на детали, очевидные для поставившего задачу разработчика или попросту будет занят другими задачами. Проблема становится особенно острой, когда для дальнейшей разработки требуется быстрый доступ к историческим данным по метрикам сервиса. В качестве средства решения этой проблемы, я решил поискать легкую и простую в настройке систему мониторинга, которая бы хорошо “ложилась” на уже существующую инфраструктуру и упрощала работу по анализу метрик.
Минимальная конфигурация системы мониторинга Prometheus состоит из сервера Prometheus и отслеживаемого приложения, достаточно только указать по какому адресу необходимо запрашивать метрики. Сбор метрик выполняется согласно pull-модели по протоколу HTTP, но существует и push-gateway компонент для слежения за короткоживущими сервисами. При использовании pull-модели Ваши приложения не знают о системе мониторинга, а значит можно запускать несколько серверов Prometheus для мониторинга, тем самым застраховавшись от возможных потерь данных. Для подготовки приложений к дальнейшему мониторингу предлагается использовать клиентские библиотеки, реализующие необходимый инструментарий по созданию и выводу метрик для различных языков. Рекомендуется использовать именно их, но при этом Вы можете применить свою реализацию, если она будет удовлетворять спецификации exposition formats.
Такой подход полностью удовлетворял моим требованиям, так как сбор метрик для Zabbix производился по схожей схеме. Для сохранения совместимости с Zabbix и с уже используемой библиотекой метрик был написан адаптер, преобразовывающий существующий формат в подходящий для Prometheus. Такое решение позволило безболезненно экспериментировать с Prometheus не “задевая” мониторинг в Zabbix и сохраняя стабильность работы существующих сервисов.
Использование
Преимущество использования Prometheus обнаружилось сразу же. Возможность в любой момент получать динамику изменения метрики, сравнивать с другими, преобразовывать, просматривать их в текстовом формате или в виде графика не покидая главной страницы web-интерфейса трудно переоценить.
Для фильтрации и преобразования метрик используется очень удобный язык запросов. К сожалению, отсутствует возможность сохранить сформированный запрос непосредственно через web-интерфейс. Для этого нужно создавать консоль, представляющую собой html-страницу, с возможностью использования Go-templates, и уже в ней строить графики, таблицы, сводки и т.д.
Хорошим решением будет создание обобщенных консолей. К примеру, необходимо мониторить несколько HTTP-серверов. Каждый из них имеет метрику, например, “http_requests_total”, показывающую количество принятых HTTP-запросов. Создадим консоль, отображающую список таких сервисов в виде ссылок на консоли с более подробной информацией:
В результате, мы получим список из ссылок на консоль “job-overview.html”, в которую передается параметр «instance». Теперь этот параметр можно использовать в качестве фильтра для построения графиков:
Как источник дополнительных примеров можно использовать стандартный набор консолей.
Производительность
Как утверждают разработчики, один сервер Prometheus может с легкостью обслуживать миллионы time-series. Этого достаточно для сбора данных с тысячи серверов с интервалом в 10 секунд. В случаях же, когда этого недостаточно — предусмотрена возможность масштабирования.
На практике заявленная производительность подтверждается. При мониторинге 800 сервисов, около 80 метрик в каждом, Prometheus использует около 6% одного ядра и 3 GB RAM, а собранные за 15 дней метрики занимают 17 GB памяти на диске. Не обязательно выделять для Prometheus отдельный сервер, с таким незначительным потреблением ресурсов он может быть установлен рядом с другими сервисами не принося никаких неудобств.
Prometheus хранит собранные метрики в оперативной памяти и при достижении лимита по размеру, или по прошествии определенного интервала времени, сохраняет их на диск. В случаях, когда приходится собирать большое количество данных (больше 100к time series, к примеру) может возрасти нагрузка на диск. В документации Prometheus приводятся полезные советы по оптимизации в таких случаях.
Бывают случаи, когда нужно сформировать график, требующий тяжелых вычислений, захватывающий большие временные периоды или имеющий высокое посещение. Для того, чтобы облегчить работу Prometheus и не вычислять такие данные на каждом запросе, существует возможность предварительного расчета. Такая опция будет особенно полезной при создании дашбордов.
Кастомизация
Откровенно говоря, web-интерфейс показался мне немного “сыроватым”. При работе с графиками, метриками, разделом наблюдаемых сервисов (/targets) возникала необходимость дополнительного функционала. С этим не возникло никаких проблем, и, вскоре, я добавил возможность быстрого поиска по тэгам метрик, а так же изменил layout раздела консолей. Когда раздел /targets увеличился до 800 сервисов — пришлось скрыть эндпоинты на странице, объединив их в группы (иначе они занимали слишком много места). Когда какой-то из эндпоинтов перестает нормально работать, то к группе добавляется иконка, уведомляющая об ошибке. Развернув лист, можно найти проблемный эндпоинт и узнать подробную информацию об ошибке:
Простота web-интерфейсов Prometheus открывает широкие возможности для создания themes, модифицирующих стандартный интерфейсы или добавляя новые разделы. Как подтверждение сказанного, предлагаю ознакомится с графическим генератором конфигурации.
Дополнительное ПО
Команда разработчиков Prometheus создает максимально открытый для интеграции проект, который можно использовать совместно с другими технологиями, а комьюнити всячески старается в этом помочь. На сайте Prometheus Вы сможете найти перечень поддерживаемых exporters — пакетов, снимающих метрики с других сервисов и технологий. Мы используем только некоторые: node_exporter, postgres_exporter и grok_exporter. Для них построены обобщенные консоли, графики в которых строятся относительно просматриваемого сервиса. Все ново добавленные или обнаруженные (service discovery) сервисы автоматически становятся доступными для просмотра в ранее созданных консолях. Если у Вас целый “зоопарк” технологий, то придется установить массу exporters для их мониторинга, но такому подходу есть вполне логическое обоснование.
Странной может показаться ситуация с безопасностью. Изначально, сервис Prometheus и установленные exporters “открыты миру”. Любой желающий, знающий нужный адрес и порт, сможет получить данные по вашим метрикам. Позиция разработчиков здесь такова — Prometheus это система мониторинга, а не безопасности. Пользователям не составит труда использовать в этих целях сторонние 3rd-party продукты, давно и успешно реализовывающие такие задачи, позволив разработчикам Prometheus сфокусироваться на задачах мониторинга. В моем же случае, успешно используется Nginx как reverse-proxy с http basic auth, настройка которого заняла совсем незначительное время.
Для тех, кто хочет лишить себя сна и покоя, разработчики предоставляют возможность использования AlertManager. Он чрезвычайно прост в настройке и позволяет работать с уже упомянутым языком запросов. AlertManager может интегрироваться с HipChat, Slack, PagerDuty, а в случае необходимости интеграции с еще не поддерживаемыми сервисами, рекомендую ознакомиться со статьей интеграции для аудио-оповещения.
В качестве практического примера привожу правило из моей текущей конфигурации AlertManager:
Это правило сработает в случае заполнения дискового пространства более чем на 70% на любом из серверов, где запущен node_exporter, после чего будет выслано соответствующее уведомление на почту.
Заключение
Я рекомендую Вам непременно познакомиться с Prometheus ближе. Для меня он стал легкой, простой и понятной системой мониторинга, с которой просто приятно работать, расширять и модифицировать под свои нужды. Если у кого-то возникнут вопросы относительно практического применения — буду рад ответить в комментариях.
Мониторинг сервисов с 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, поделитесь впечатлениями. Будем благодарны за любые полезные замечания и дополнения.
Для желающих узнать больше приводим несколько полезных ссылок:
Если вы по тем или иным причинам не можете оставлять комментарии здесь — приглашаем в наш блог.