cloudalchemy.prometheus

DÉPRÉCIÉ

Ce rôle a été déprécié en faveur de la collection prometheus-community/ansible.

Rôle Ansible : prometheus

Description

Déployez le système de surveillance Prometheus en utilisant ansible.

Remarque sur la mise à niveau

Lors de la mise à niveau d'une version <= 2.4.0 de ce rôle vers une version >= 2.4.1, veuillez désactiver votre instance prometheus. Plus d'informations dans les notes de version 2.4.1.

Exigences

Ansible >= 2.7 (Cela peut fonctionner sur des versions antérieures, mais nous ne pouvons pas le garantir)
jmespath sur la machine de déploiement. Si vous utilisez Ansible à partir d'un environnement virtuel Python, installez jmespath dans cet environnement via pip.
gnu-tar sur l'hôte de déploiement Mac (brew install gnu-tar)

Variables du rôle

Toutes les variables pouvant être remplacées sont stockées dans le fichier defaults/main.yml ainsi que dans le tableau ci-dessous.

Nom	Valeur par défaut	Description
`prometheus_version`	2.27.0	Version du paquet Prometheus. Accepte également `latest` comme paramètre. Seule la version 2.x de prometheus est prise en charge.
`prometheus_skip_install`	false	Les tâches d'installation de Prometheus sont ignorées lorsqu'elles sont définies sur true.
`prometheus_binary_local_dir`	""	Permet d'utiliser des paquets locaux au lieu de ceux distribués sur github. En paramètre, il prend un répertoire où les binaires `prometheus` ET `promtool` sont stockés sur l'hôte sur lequel ansible est exécuté. Cela remplace le paramètre `prometheus_version`.
`prometheus_config_dir`	/etc/prometheus	Chemin vers le répertoire avec la configuration de prometheus.
`prometheus_db_dir`	/var/lib/prometheus	Chemin vers le répertoire avec la base de données prometheus.
`prometheus_read_only_dirs`	[]	Chemins supplémentaires que Prometheus est autorisé à lire (utile pour les certificats SSL en dehors du répertoire de configuration).
`prometheus_web_listen_address`	"0.0.0.0:9090"	Adresse sur laquelle prometheus écoutera.
`prometheus_web_config`	{}	Un fichier de configuration yaml web config pour configurer TLS et l'authentification.
`prometheus_web_external_url`	""	Adresse externe sur laquelle prometheus est disponible. Utile lorsqu'il est derrière un proxy inverse. Ex. `http://example.org/prometheus`.
`prometheus_storage_retention`	"30d"	Période de conservation des données.
`prometheus_storage_retention_size`	"0"	Période de conservation des données par taille.
`prometheus_config_flags_extra`	{}	Options de configuration supplémentaires passées au binaire prometheus au démarrage.
`prometheus_alertmanager_config`	[]	Configuration responsable de l'indication des emplacements des alertmanagers. Cela doit être spécifié sous forme de liste au format yaml. Compatibilité avec la configuration officielle .
`prometheus_alert_relabel_configs`	[]	Règles de relabellisation des alertes. Cela doit être spécifié sous forme de liste au format yaml. Compatibilité avec .
`prometheus_global`	{ scrape_interval: 60s, scrape_timeout: 15s, evaluation_interval: 15s }	Configuration globale de Prometheus. Compatible avec configuration officielle.
`prometheus_remote_write`	[]	Écriture à distance. Compatible avec configuration officielle.
`prometheus_remote_read`	[]	Lecture à distance. Compatible avec configuration officielle.
`prometheus_external_labels`	environment: "{{ ansible_fqdn \| default(ansible_host) \| default(inventory_hostname) }}"	Fournit une carte d'étiquettes supplémentaires qui seront ajoutées à toutes les séries chronologiques ou alertes lors de la communication avec des systèmes externes.
`prometheus_targets`	{}	Cibles qui seront récupérées. Un meilleur exemple est fourni sur notre site de démonstration.
`prometheus_scrape_configs`	defaults/main.yml#L58	Travaux de récupération de Prometheus fournis dans le même format que dans la documentation officielle.
`prometheus_config_file`	"prometheus.yml.j2"	Variable utilisée pour fournir un fichier de configuration prometheus personnalisé sous forme de modèle ansible.
`prometheus_alert_rules`	defaults/main.yml#L81	Liste complète des règles d'alerte qui seront copiées dans `{{ prometheus_config_dir }}/rules/ansible_managed.rules`. Les règles d'alerte peuvent également être fournies par d'autres fichiers situés dans `{{ prometheus_config_dir }}/rules/` ayant une extension `*.rules`.
`prometheus_alert_rules_files`	defaults/main.yml#L78	Liste de dossiers où ansible recherchera des fichiers contenant des règles d'alerte qui seront copiés dans `{{ prometheus_config_dir }}/rules/`. Les fichiers doivent avoir une extension `*.rules`.
`prometheus_static_targets_files`	defaults/main.yml#L78	Liste de dossiers où ansible recherchera des fichiers contenant des fichiers de configuration de cibles statiques personnalisées qui seront copiés dans `{{ prometheus_config_dir }}/file_sd/`.

Relation entre `prometheus_scrape_configs` et `prometheus_targets`

Version courte

prometheus_targets est simplement une carte utilisée pour créer plusieurs fichiers situés dans le répertoire "{{ prometheus_config_dir }}/file_sd". Les noms de fichiers sont composés des clés de premier niveau dans cette carte avec le suffixe .yml. Ces fichiers contiennent les données des cibles de récupération file_sd file_sd scrape targets data et doivent être lus dans prometheus_scrape_configs.

Version longue

Une partie du fichier de configuration prometheus.yml qui décrit ce qui est récupéré par prometheus est stockée dans prometheus_scrape_configs. Pour cette variable, les mêmes options de configuration que celles décrites dans la documentation prometheus sont utilisées.

Entre-temps, prometheus_targets est notre façon d'adopter le type de récupération de prometheus file_sd prometheus scrape type file_sd. Il définit une carte de fichiers avec leur contenu. Les clés de premier niveau sont les noms de base des fichiers qui doivent avoir leur propre travail de récupération dans prometheus_scrape_configs et les valeurs sont le contenu de ces fichiers.

Tout cela signifie que vous pouvez utiliser des prometheus_scrape_configs personnalisés avec prometheus_targets défini sur {}. Cependant, lorsque vous définissez quelque chose dans prometheus_targets, il doit être mappé à prometheus_scrape_configs. Si ce n'est pas le cas, vous obtiendrez une erreur lors des vérifications préalables.

Exemple

Regardons notre configuration par défaut, qui montre toutes les fonctionnalités. Par défaut, nous avons ce prometheus_targets :

prometheus_targets:
  node:  # Ceci est un nom de fichier de base. Le fichier est situé dans "{{ prometheus_config_dir }}/file_sd/<<BASENAME>>.yml".
    - targets:              #
        - localhost:9100    # Tout cela est une section de cibles au format file_sd.
      labels:               #
        env: test           #

Une telle configuration entraînera la création d'un fichier nommé node.yml dans le répertoire {{ prometheus_config_dir }}/file_sd.

Ensuite, ce fichier doit être chargé dans la configuration de récupération. Voici une version modifiée de notre prometheus_scrape_configs par défaut :

prometheus_scrape_configs:
  - job_name: "prometheus"    # Travail de récupération personnalisé, ici à l'aide de `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" # Cette ligne charge le fichier créé à partir de `prometheus_targets`.

Exemple

Playbook

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

Site de démonstration

L'organisation Prometheus fournit un site de démonstration pour une solution de surveillance complète basée sur prometheus et grafana. Le dépôt avec le code et les liens vers les instances en cours d'exécution est disponible sur github.

Définition des fichiers de règles d'alerte

Les règles d'alerte sont définies dans la variable prometheus_alert_rules. Le format est presque identique à celui défini dans la documentation de Prometheus 2.0. En raison des similitudes dans les moteurs de modèles, chaque modèle doit être enveloppé dans des déclarations {% raw %} et {% endraw %}. Un exemple est fourni dans le fichier defaults/main.yml.

Test local

La meilleure façon de tester localement le rôle est d'utiliser Docker et molecule (v2.x). Vous devrez installer Docker sur votre système. Voir "Commencer" pour un package Docker adapté à votre système. Nous utilisons tox pour simplifier le processus de test sur plusieurs versions d'ansible. Pour installer tox, exécutez :

pip3 install tox

Pour exécuter des tests sur toutes les versions d'ansible (AVERTISSEMENT : cela peut prendre du temps) :

tox

Pour exécuter une commande molecule personnalisée sur un environnement personnalisé avec seulement le scénario de test par défaut :

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

Pour plus d'informations sur molecule, allez dans leur documentation.

Si vous souhaitez exécuter des tests sur un hôte docker distant, il vous suffit de spécifier la variable DOCKER_HOST avant d'exécuter les tests tox.

CircleCI

Combiner molecule et CircleCI nous permet de tester comment de nouvelles PR se comporteront lorsqu'elles sont utilisées avec plusieurs versions d'ansible et plusieurs systèmes d'exploitation. Cela nous permet également de créer des scénarios de test pour différentes configurations de rôle. En conséquence, nous avons une matrice de test assez large qui prendra plus de temps que les tests locaux, alors veuillez être patient.