cloudalchemy.prometheus

Descripción general Versiones Perspectivas

DESACTIVADO

Este rol ha sido desactivado en favor de la colección prometheus-community/ansible.

Rol de Ansible: prometheus

Descripción

Despliega el sistema de monitoreo Prometheus usando Ansible.

Aviso de actualización

Al actualizar de una versión <= 2.4.0 de este rol a >= 2.4.1, por favor apaga tu instancia de Prometheus. Más información en las notas de la versión 2.4.1

Requisitos

Ansible >= 2.7 (Puede funcionar en versiones anteriores, pero no lo garantizamos)
jmespath en la máquina de despliegue. Si usas Ansible desde un virtualenv de Python, instala jmespath en el mismo virtualenv mediante pip.
gnu-tar en el host de despliegue Mac (brew install gnu-tar)

Variables del rol

Todas las variables que se pueden sobrescribir están almacenadas en el archivo defaults/main.yml así como en la tabla a continuación.

Nombre	Valor por defecto	Descripción
`prometheus_version`	2.27.0	Versión del paquete de Prometheus. También acepta `latest` como parámetro. Solo se soporta Prometheus 2.x
`prometheus_skip_install`	false	Las tareas de instalación de Prometheus se omiten cuando se establece en true.
`prometheus_binary_local_dir`	""	Permite usar paquetes locales en lugar de los distribuidos en Github. Como parámetro toma un directorio donde se almacenan los binarios `prometheus` Y `promtool` en el host en el que se ejecuta Ansible. Esto sobrescribe el parámetro `prometheus_version`
`prometheus_config_dir`	/etc/prometheus	Ruta al directorio con la configuración de Prometheus
`prometheus_db_dir`	/var/lib/prometheus	Ruta al directorio con la base de datos de Prometheus
`prometheus_read_only_dirs`	[]	Rutas adicionales que Prometheus tiene permiso para leer (útil para certificados SSL fuera del directorio de configuración)
`prometheus_web_listen_address`	"0.0.0.0:9090"	Dirección en la que Prometheus estará escuchando
`prometheus_web_config`	{}	Configuración web de Prometheus yaml para configurar TLS y autenticación.
`prometheus_web_external_url`	""	Dirección externa en la que Prometheus está disponible. Útil cuando está detrás de un proxy inverso. Ej. `http://example.org/prometheus`
`prometheus_storage_retention`	"30d"	Período de retención de datos
`prometheus_storage_retention_size`	"0"	Período de retención de datos por tamaño
`prometheus_config_flags_extra`	{}	Banderas de configuración adicionales pasadas al binario de Prometheus al iniciar
`prometheus_alertmanager_config`	[]	Configuración que indica dónde están los alertmanagers. Esto debe especificarse como una lista en formato yaml. Es compatible con
`prometheus_alert_relabel_configs`	[]	Reglas de reetiquetado de alertas. Esto debe especificarse como una lista en formato yaml. Es compatible con
`prometheus_global`	{ scrape_interval: 60s, scrape_timeout: 15s, evaluation_interval: 15s }	Configuración global de Prometheus. Compatible con configuración oficial
`prometheus_remote_write`	[]	Escritura remota. Compatible con configuración oficial
`prometheus_remote_read`	[]	Lectura remota. Compatible con configuración oficial
`prometheus_external_labels`	environment: "{{ ansible_fqdn	default(ansible_host)
`prometheus_targets`	{}	Targets que serán recolectados. Se proporciona un mejor ejemplo en nuestro sitio de demostración
`prometheus_scrape_configs`	defaults/main.yml#L58	Trabajos de recolecta de Prometheus proporcionados en el mismo formato que en documentos oficiales
`prometheus_config_file`	"prometheus.yml.j2"	Variable usada para proporcionar un archivo de configuración de Prometheus personalizado en forma de plantilla de ansible
`prometheus_alert_rules`	defaults/main.yml#L81	Lista completa de reglas de alerta que se copiarán en `{{ prometheus_config_dir }}/rules/ansible_managed.rules`. Las reglas de alerta también pueden proporcionarse mediante otros archivos ubicados en `{{ prometheus_config_dir }}/rules/` que tienen la extensión `*.rules`
`prometheus_alert_rules_files`	defaults/main.yml#L78	Lista de carpetas donde Ansible buscará archivos que contengan reglas de alerta que serán copiadas a `{{ prometheus_config_dir }}/rules/`. Los archivos deben tener la extensión `*.rules`
`prometheus_static_targets_files`	defaults/main.yml#L78	Lista de carpetas donde Ansible buscará archivos que contengan archivos de configuración de objetivo estático personalizados que serán copiados a `{{ prometheus_config_dir }}/file_sd/`.

Relación entre `prometheus_scrape_configs` y `prometheus_targets`

Versión corta

prometheus_targets es solo un mapa usado para crear múltiples archivos ubicados en el directorio "{{ prometheus_config_dir }}/file_sd". Donde los nombres de archivo están compuestos por las claves de nivel superior en ese mapa con sufijo .yml. Estos archivos almacenan datos de objetivos de raspado de file_sd y deben ser leídos en prometheus_scrape_configs.

Versión larga

Una parte del archivo de configuración prometheus.yml que describe qué es raspado por Prometheus se almacena en prometheus_scrape_configs. Para esta variable se utilizan las mismas opciones de configuración como se describen en documentos de Prometheus.

Mientras tanto, prometheus_targets es nuestra forma de adoptar tipo de raspado de Prometheus file_sd. Define un mapa de archivos con su contenido. Las claves de nivel superior son los nombres base de los archivos que necesitan tener su propio trabajo de raspado en prometheus_scrape_configs y los valores son el contenido de esos archivos.

Todo esto significa que PUEDES usar configuraciones personalizadas de prometheus_scrape_configs con prometheus_targets establecido en {}. Sin embargo, cuando estableces algo en prometheus_targets, debe ser mapeado a prometheus_scrape_configs. Si no es así, obtendrás un error en las comprobaciones previas.

Ejemplo

Veamos nuestra configuración por defecto, que muestra todas las funciones. Por defecto, tenemos este prometheus_targets:

prometheus_targets:
  node:  # Este es un nombre base de archivo. El archivo se encuentra en "{{ prometheus_config_dir }}/file_sd/<<BASENAME>>.yml"
    - targets:              #
        - localhost:9100    # Todo esto es la sección de objetivos en formato file_sd
      labels:               #
        env: test           #

Esta configuración resultará en la creación de un archivo llamado node.yml en el directorio {{ prometheus_config_dir }}/file_sd.

Luego, este archivo necesita ser cargado en la configuración de raspado. Aquí hay una versión modificada de nuestra configuración por defecto prometheus_scrape_configs:

prometheus_scrape_configs:
  - job_name: "prometheus"    # Trabajo de raspado personalizado, aquí usando `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" # Esta línea carga el archivo creado a partir de `prometheus_targets`

Ejemplo

Playbook

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

Sitio de demostración

La organización de Prometheus proporciona un sitio de demostración para una solución completa de monitoreo basada en Prometheus y Grafana. El repositorio con el código y enlaces a instancias en ejecución está disponible en GitHub.

Definición de archivos de reglas de alerta

Las reglas de alerta se definen en la variable prometheus_alert_rules. El formato es casi idéntico al definido en la documentación de Prometheus 2.0. Debido a las similitudes en los motores de plantillas, cada plantilla debe estar envoltura en sentencias {% raw %} y {% endraw %}. Un ejemplo se proporciona en el archivo defaults/main.yml.

Pruebas Locales

La forma preferida de probar el rol localmente es usar Docker y molecule (v2.x). Tendrás que instalar Docker en tu sistema. Consulta "Empezar" para un paquete de Docker adecuado para tu sistema. Usamos tox para simplificar el proceso de prueba en múltiples versiones de ansible. Para instalar tox, ejecuta:

pip3 install tox

Para ejecutar pruebas en todas las versiones de ansible (ADVERTENCIA: esto puede tardar un tiempo)

tox

Para ejecutar un comando de molecula personalizado en un entorno personalizado solo con el escenario de prueba predeterminado:

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

Para más información sobre molecule, visita su documentación.

Si deseas ejecutar pruebas en un host de docker remoto, simplemente especifica la variable DOCKER_HOST antes de ejecutar las pruebas de tox.

CircleCI

Combinar molecule y CircleCI nos permite probar cómo se comportarán nuevos PR al ser usados con múltiples versiones de ansible y múltiples sistemas operativos. Esto también nos permite crear escenarios de prueba para diferentes configuraciones de rol. Como resultado, tenemos una matriz de pruebas bastante grande que tomará más tiempo que las pruebas locales, así que por favor ten paciencia.