prometheus

УСТАРЕВШАЯ ВЕРСИЯ

Эта роль устарела в пользу коллекции prometheus-community/ansible.

Ansible Роль: prometheus

Описание

Развертывание системы мониторинга Prometheus с использованием ansible.

Уведомление об обновлении

При обновлении с версии <= 2.4.0 этой роли до >= 2.4.1, пожалуйста, отключите ваш экземпляр prometheus. Подробнее в заметках о выпуске 2.4.1.

Требования

Ansible >= 2.7 (может работать на более ранних версиях, но мы не можем это гарантировать)
jmespath на машине развертывания. Если вы используете Ansible из Python виртуального окружения, установите jmespath в то же виртуальное окружение через pip.
gnu-tar на хосте развертывателя Mac (brew install gnu-tar)

Переменные роли

Все переменные, которые можно переопределить, хранятся в файле defaults/main.yml, а также в таблице ниже.

Имя	Значение по умолчанию	Описание
`prometheus_version`	2.27.0	Версия пакета Prometheus. Также принимает `latest` как параметр. Поддерживается только prometheus 2.x.
`prometheus_skip_install`	false	Задачи установки Prometheus пропускаются, если установлено значение true.
`prometheus_binary_local_dir`	""	Позволяет использовать локальные пакеты вместо тех, что распространяются на github. В качестве параметра принимает директорию, где хранятся бинарные файлы `prometheus` и `promtool` на хосте, на котором выполняется ansible. Это переопределяет параметр `prometheus_version`.
`prometheus_config_dir`	/etc/prometheus	Путь к директории с конфигурацией prometheus.
`prometheus_db_dir`	/var/lib/prometheus	Путь к директории с базой данных prometheus.
`prometheus_read_only_dirs`	[]	Дополнительные пути, которые может читать Prometheus (полезно для SSL сертификатов вне каталога конфигурации).
`prometheus_web_listen_address`	"0.0.0.0:9090"	Адрес, на котором будет слушать prometheus.
`prometheus_web_config`	{}	Конфигурация веба для Prometheus web config yaml для настройки TLS и аутентификации.
`prometheus_web_external_url`	""	Внешний адрес, по которому доступен prometheus. Полезно, если за обратным прокси. Например, `http://example.org/prometheus`.
`prometheus_storage_retention`	"30d"	Период хранения данных.
`prometheus_storage_retention_size`	"0"	Период хранения данных по размеру.
`prometheus_config_flags_extra`	{}	Дополнительные флаги конфигурации, передаваемые бинарному файлу prometheus при запуске.
`prometheus_alertmanager_config`	[]	Конфигурация, указывающая, где находятся alertmanagers. Это должно быть указано как список в формате yaml. Совместимо с официальным .
`prometheus_alert_relabel_configs`	[]	Правила переименования уведомлений. Это должно быть указано как список в формате yaml. Совместимо с официальным .
`prometheus_global`	{ scrape_interval: 60s, scrape_timeout: 15s, evaluation_interval: 15s }	Глобальная конфигурация Prometheus. Совместимо с официальной конфигурацией.
`prometheus_remote_write`	[]	Удаленная запись. Совместимо с официальной конфигурацией.
`prometheus_remote_read`	[]	Удаленное чтение. Совместимо с официальной конфигурацией.
`prometheus_external_labels`	environment: "{{ ansible_fqdn	default(ansible_host)
`prometheus_targets`	{}	Цели, которые будут обрабатываться. Лучший пример представлен на нашем демо-сайте.
`prometheus_scrape_configs`	defaults/main.yml#L58	Работы по сбору данных Prometheus, представленные в том же формате, что и в официальной документации.
`prometheus_config_file`	"prometheus.yml.j2"	Переменная, используемая для предоставления настраиваемого файла конфигурации prometheus в виде шаблона ansible.
`prometheus_alert_rules`	defaults/main.yml#L81	Полный список правил уведомлений, которые будут скопированы в `{{ prometheus_config_dir }}/rules/ansible_managed.rules`. Правила уведомлений также могут быть предоставлены другими файлами, расположенными в `{{ prometheus_config_dir }}/rules/`, которые имеют расширение `*.rules`.
`prometheus_alert_rules_files`	defaults/main.yml#L78	Список папок, где ansible будет искать файлы, содержащие правила уведомлений, которые будут скопированы в `{{ prometheus_config_dir }}/rules/`. Файлы должны иметь расширение `*.rules`.
`prometheus_static_targets_files`	defaults/main.yml#L78	Список папок, где ansible будет искать файлы, содержащие настраиваемые файлы конфигурации статической цели, которые будут скопированы в `{{ prometheus_config_dir }}/file_sd/`.

Взаимосвязь между `prometheus_scrape_configs` и `prometheus_targets`

Краткая версия

prometheus_targets - это просто карта, используемая для создания нескольких файлов, расположенных в каталоге "{{ prometheus_config_dir }}/file_sd". Имена файлов формируются из ключей верхнего уровня в этой карте с суффиксом .yml. Эти файлы хранят данные целевых объектов file_sd scrape targets и должны быть прочитаны в prometheus_scrape_configs.

Длинная версия

Часть конфигурационного файла prometheus.yml, которая описывает, что собирается prometheus, хранится в prometheus_scrape_configs. Для этой переменной используются те же параметры конфигурации, что описаны в документации prometheus.

Тем временем prometheus_targets - это наш способ адаптации scrape type prometheus file_sd. Он определяет карту файлов с их содержимым. Ключи верхнего уровня - это базовые имена файлов, которые должны иметь свою собственную работу по сбору данных в prometheus_scrape_configs, а значения - это содержимое этих файлов.

Все это означает, что вы можете использовать настраиваемые prometheus_scrape_configs, устанавливая prometheus_targets в {}. Однако при установке чего-либо в prometheus_targets это должно быть связано с prometheus_scrape_configs. Если этого не сделать, вы получите ошибку при предварительной проверке.

Пример

Посмотрим на нашу конфигурацию по умолчанию, которая показывает все функции. По умолчанию у нас есть такой prometheus_targets:

prometheus_targets:
  node:  # Это базовое имя файла. Файл находится в "{{ prometheus_config_dir }}/file_sd/<<BASENAME>>.yml"
    - targets:              #
        - localhost:9100    # Все это - секция целей в формате file_sd
      labels:               #
        env: test           #

Такая конфигурация приведет к созданию одного файла с именем node.yml в каталоге {{ prometheus_config_dir }}/file_sd.

Затем этот файл должен быть загружен в конфигурацию сбора данных. Вот измененная версия нашей конфигурации prometheus_scrape_configs:

prometheus_scrape_configs:
  - job_name: "prometheus"    # Пользовательская работа по сбору данных, здесь используется `static_config`
    metrics_path: "/metrics"
    static_configs:
      - targets:
          - "localhost:9090"
  - job_name: "example-node-file-servicediscovery"
    file_sd_configs:
      - files:
          - "{{ prometheus_config_dir }}/file_sd/node.yml" # Эта строка загружает файл, созданный из `prometheus_targets`

Пример

Плейбук

---
- hosts: all
  roles:
  - cloudalchemy.prometheus
  vars:
    prometheus_targets:
      node:
      - targets:
        - localhost:9100
        - demo.cloudalchemy.org:9100
        labels:
          env: demosite

Демонстрационный сайт

Организация Prometheus предоставляет демонстрационный сайт для полного решения мониторинга на основе prometheus и grafana. Репозиторий с кодом и ссылками на работающие экземпляры доступен на github.

Определение файлов правил уведомлений

Правила уведомлений определяются в переменной prometheus_alert_rules. Формат почти идентичен тому, что определен в документации Prometheus 2.0. Из-за схожести в шаблонах, каждый шаблон должен быть обернут в конструкции {% raw %} и {% endraw %}. Пример предоставлен в файле defaults/main.yml.

Локальное тестирование

Предпочтительный способ локального тестирования роли - использовать Docker и molecule (v2.x). Вам нужно будет установить Docker на вашей системе. Смотрите "Начало работы", чтобы получить подходящий пакет Docker для вашей системы. Мы используем tox для упрощения процесса тестирования на нескольких версиях ansible. Для установки tox выполните:

pip3 install tox

Чтобы запустить тесты на всех версиях ansible (ПРЕДУПРЕЖДЕНИЕ: это может занять некоторое время):

tox

Чтобы запустить пользовательскую команду molecule в пользовательской среде только с тестовым сценарием по умолчанию:

tox -e py35-ansible28 -- molecule test -s default

Для получения более подробной информации о molecule перейдите в их документацию.

Если вы хотите запустить тесты на удаленном хосте Docker, просто укажите переменную DOCKER_HOST перед запуском тестов tox.

CircleCI

Сочетание molecule и CircleCI позволяет нам тестировать, как новые PR будут вести себя при использовании с несколькими версиями ansible и несколькими операционными системами. Это также позволяет создавать тестовые сценарии для различных конфигураций роли. В результате у нас получается довольно большая тестовая матрица, что займет больше времени, чем локальное тестирование, так что, пожалуйста, наберитесь терпения.