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 Operator в Kubernetes
В основу этой статьи легла наша внутренняя документация для DevOps-инженеров, объясняющая, как работает Prometheus под управлением Prometheus Operator в разворачиваемых и обслуживаемых кластерах Kubernetes.
С первого взгляда Prometheus может показаться достаточно сложным продуктом, но, как и любая хорошо спроектированная система, она состоит из явно выраженных функциональных компонентов и по сути делает всего три вещи: а) собирает метрики, б) выполняет правила, в) сохраняет результат в базу данных временных рядов (time series). Статья посвящена не столько самому Prometheus, сколько интеграции этой системы с Kubernetes, для чего мы активно используем вспомогательный инструмент под названием Prometheus Operator. Но начать всё же необходимо с самого Prometheus…
Prometheus: что он делает?
Итак, если подробнее остановиться на двух первых функциях Prometheus, то они работают следующим образом:
Prometheus: как он настраивается?
У сервера Prometheus есть config и rule files (файлы с правилами).
В config имеются следующие секции:
Prometheus: откуда берётся список целей?
Общий алгоритм работы Prometheus выглядит следующим образом:
Таким образом, Prometheus сам отслеживает:
Prometheus Operator: что он делает?
Для пресловутого «упрощения», во-первых, в Prometheus Operator с помощью механизма CRD (Custom Resource Definitions) заданы три ресурса:
Что в поде с Prometheus?
Под состоит из двух контейнеров:
Под использует три тома (volumes):
Как обрабатываются Service Monitors?
Как обрабатываются ConfigMaps с правилами?
Вот и всё!
Подробнее о том, как мы используем Prometheus (и не только) для мониторинга в Kubernetes, я планирую рассказать на конференции RootConf 2018, что будет проходить 28 и 29 мая в Москве, — приходите послушать и пообщаться.
Мониторинг приложений с Prometheus
На этой неделе мы запускаем четвёртый по счёту поток курса «DevOps: практики и инструменты», так что по традиции небольшая интересная статья для вас.
В этом практическом руководстве мы рассмотрим, как интегрировать мониторинг Prometheus в существующее приложение. Мониторинг приложения может дать представление о том, как и когда приложение используется. Более того, можно предугадать потенциальные проблемы.
Prometheus представляет собой базу данных временных рядов с UI и весьма сложным языком запросов (PromQL). Prometheus может парсить метрики, счетчики, индикаторы и гистограммы через HTTP при помощи plaintext и более эффективного протокола.
Глоссарий:
Встраивание endpoints /metrics в существующее приложение, называется инструментированием (instrumentation). А когда endpoint /metrics является частью автономного процесса — экспортером (Expoter).
Один из самых популярных экспортеров — NodeExporter. Когда NodeExporter запущен на хосте, он предоставляет детали нагрузки ввода-вывода, памяти, диска и CPU. Его можно запустить как Docker контейнер, но это требует большого количества дополнительных флагов, поэтому рекомендуется запускать его напрямую на хосте, где ведется мониторинг.
Prometheus предоставляет собственный набор метрик — что, по сути, dogfooding (использование своих собственных продуктов в целях тестирования). Он уже встроен и обычно включен по умолчанию.
Экспортеры, поддерживаемые сообществом
Интересные экспортеры, написанные к Саммиту Docker в Берлине — экспортеры Docker Hub и GitHub Эдварда Маршала (Edward Marshall). Эти экспортеры собирают метрики сайтов Docker Hub и GitHub путем периодического запроса API и передачи этих значений.
При создании экспортера Эд использовал клиентские библиотеки Python, но доступны и другие языковые привязки.
Мой Bitcoin экспортер написан на Node.js и использует метрики типов Гистограмма и Радиальный датчик.
Создание своего экспортера
И тут все становится намного интересней — мониторить можно почти все что угодно. Представим, что у нас есть магазин в Shopify (то есть: карманный онлайн-магазин), в котором мы следим за продажами и статусами заказов.
Вот несколько идей для метрик, за которыми можно следить:
Prometheus с Docker
Prometheus написан на Golang и может использоваться как самостоятельный статически скомпилированный бинарный файл без зависимостей. Проект также упаковывает бинарный файл с разумной конфигурацией в Docker контейнер.
Запуск Prometheus в Docker
Определим Docker Compose, который позволяет командным строкам оставаться простыми и повторяемыми:
Разверните файл стека:
Для деплоя стек-файлов необходим Swarm режим, поэтому запустите docker swarm init, если не сделали этого ранее.
Зайдите на http://localhost:9090/, чтобы взглянуть на интерфейс.
На скриншоте выше можно увидеть количество используемых go_routines, записанных самим Prometheus. Чтобы посмотреть на сырые метрики, которые собирает Prometheus про самого себя, откройте браузер и перейдите на http://localhost:9090/metrics
Go routine — облегченная версия потока, которая используется в Golang для обеспечения конкурентности.
Вероятно, вам и не нужно мониторить Prometheus. Но сам факт наличия такой возможности означает, что вы сразу можете познакомиться с метриками.
Посмотрим на инструментирование вашего приложения.
Существует два подхода к инструментированию, но оба они включают необходимость открытия или имплементации endpoint’а HTTP/s. По умолчанию endpoint — /metrics, но его можно перенастроить на ваш файл prometheus.yml. Prometheus будет использовать endpoint для сбора метрик с регулярным интервалом в 5с или 30с.
Нужно ли править код приложения?
Можно сделать /metrics endpoint частью существующего кода приложения. Это осуществимо, если у вас уже есть реквизиты и данные для взаимодействия с уровнями оплаты или базы данных. Минус — нужно включить новую библиотеку, endpoint и зависимость в ваш продукт или проект.
В чем заключается другой вариант?
Можно написать отдельный процесс, который выступает в качестве прослойки для получения доступа к информации из вашего приложения или окружения. В случае с экспортером Docker Hub, происходило считывание данных из внешнего API, управлять которым было невозможно. Поэтому, если вам трудно получить разрешение на изменение существующего приложения, этот способ может сработать.
Преимущество отдельного процесса заключается в том, что вам не придется повторно развертывать приложение, если возникла необходимость обновить то, что вы мониторите.
Prometheus может считывать данные из двух форматов “экспозиции”. Зайдем на localhost:9090/metrics и посмотрим на результат предыдущего примера go_routines.
Используйте клиентскую библиотеку
Существует множество библиотек для работы с метриками, и большинство из них может выводить текст и более эффективный бинарный формат (Protobuf), упомянутый выше.
Форматы экспозиции Prometheus
Проект поддерживает языковые связки для Golang, Java, Python и Ruby, но в открытом доступе есть и многие другие.
С полным списком можно ознакомиться здесь:
Библиотеки Prometheus
Стоит ли писать собственную?
Формат plaintext настолько прост, что можно с легкостью встроить протокол, следуя форматам экспозиции Prometheus.
И перед тем, как создавать свою, убедитесь, что точно не удастся использовать существующие проверенные клиентские библиотеки.
Инструментирование Golang приложения
Создадим простое приложение и инструментируем его напрямую с помощью библиотеки Golang Prometheus.
Нужно написать веб-сервис для предоставления SHA-256 хэшей по требованию. Для этого нужно знать несколько вещей:
Полный код, включая Dockerfile, доступен на GitHub: alexellis/hash-browns
Вот пример “server.go” файла:
Здесь мы регистрируем путь нашего приложения и metrics.
После этого записывать потраченное время можно с помощью вызова histogram.Observe(seconds).
Можно сгенерировать хэш:
Последний шаг — отредактировать prometheus.yml и начать парсить новый код приложения. После этого вы найдете метрики в выпадающем списке и сможете визуализировать значения.
Нужно изменить конфиг Prometheus, для этого воспользуемся небольшим трюком по извлечению дефолтного конфига из официального образа Docker:
Теперь поправим файл prometheus.yml, созданный в текущей директории. В секции scrape_config добавим следующее:
Docker Swarm позволяет сервисам обращаться друг к другу через встроенный DNS, поэтому цель — просто метка (“hashbrowns”) из компоновочного файла.
Теперь создадим новый файл docker-compose.yml:
Развернем файл стека:
Примечание: Обращение к сервису по имени будет работать до тех пор, пока у вас только одна реплика. Если вы захотите масштабировать сервис, придется разобраться, как позволить Prometheus находить реплики по отдельности.
Вот как это выглядит в интерфейсе Prometheus:
Дадим ответы в формате PromQL с помощью метрик, которые мы собрали выше. Мне потребовалось некоторое время, чтобы привыкнуть к PromQL, но повезло, что Джулиус написал очень детальную статью, доступную здесь.
Как всегда ждём вопросы и комментарии тут или на Дне открытых дверей.
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. Благодаря своей гибкости он подходит для таких инструментов и архитектур гораздо лучше других существующих платформ.