Ansible Prometheus

Ce rôle installe et gère le serveur Prometheus, Alertmanager, PushGateway, et de nombreux exportateurs Prometheus.

Ce rôle a été conçu pour permettre d’ajouter facilement de nouveaux exportateurs. Les versions régulières garantissent qu'il fournit toujours la dernière version du logiciel Prometheus.

Ce rôle peut enregistrer automatiquement les exportateurs clients avec le serveur Prometheus (voir la gestion des groupes ci-dessous).

Exigences

• Ansible >= 2.8.0
• Les faits doivent être collectés (gather_facts: true)

Logiciels et systèmes d'exploitation pris en charge

Systèmes d'exploitation, distributions et architectures pris en charge

Ce module vise à prendre en charge le plus grand nombre possible de distributions et d'architectures. Le tableau ci-dessous spécifie quelles combinaisons sont actuellement testées. La plupart des exportateurs fonctionneront également sur des architectures ARM :

Système d'exploitation	Version	Architectures
Alpine	3.2 à 3.11, edge	x86_64 (amd64)
AmazonLinux	1 et 2	x86_64 (amd64)
ArchLinux	Actuel	x86_64 (amd64)
Enterprise Linux	6, 7, 8	x86_64 (amd64)
Fedora	20 à 31, rawhide	x86_64 (amd64)
Gentoo (openrc)	Actuel	x86_64 (amd64)
Gentoo (systemd)	Actuel	x86_64 (amd64)
OpenSUSE	13.1 à tumbleweed	x86_64 (amd64)
Oracle Linux	6, 7, 8	x86_64 (amd64)
Ubuntu	16.04 à 20.04	x86_64 (amd64)

Logiciels Prometheus gérés

Le logiciel Prometheus de base prendre en charge en plus de la liste des exportateurs ci-dessous. Ce logiciel est entièrement testé sur tous les systèmes d'exploitation, distributions et architectures prises en charge.

Logiciel Prometheus	Utilisation	Auteur	Testé CI
prometheus	utilisation	prometheus	Oui
alertmanager	utilisation	prometheus	Oui
push_gateway	utilisation	prometheus	Oui

Exportateurs gérés

Tous les exportateurs sont vérifiés pour l'installation. Actuellement, certains modules reçoivent des tests via CI (Intégration Continue) et Inspec.

Voir la page d'utilisation de chaque exportateur pour plus de détails :

Exportateur	Utilisation	Auteur	Testé CI
389ds_exporter_terrycain	utilisation	terrycain	Oui
apache_exporter_lusitaniae	utilisation	Lusitaniae	Oui
aerospike_exporter_alicebob	utilisation	alicebob	Oui
... (et tout le reste des exportateurs) ...	...	...	...

Scripts textfiles gérés par node_exporter

De nombreux scripts textfiles de node_exporter sont pris en charge et peuvent être installés via les variables suivantes. Ces scripts sont installés par défaut sous '/opt/prometheus/scripts' :

Script textfile de node_exporter	Source	Variable d'activation
apt.sh	Exemples node_exporter	prometheus_script_apt: true
btrfs_stats.py	Exemples node_exporter	prometheus_script_btrfs_stats: true
... (et tout le reste des scripts) ...	...	...

Variables de rôle

Un tableau 'prometheus_components' est utilisé pour spécifier le logiciel Prometheus à installer. Cet exemple installe tous les composants prometheus pris en charge :

# Démonstration uniquement. Les clients ne doivent avoir que le logiciel et les exportateurs applicables définis :
prometheus_components:
 # Composants principaux :
 - alertmanager
 - prometheus
 - push_gateway
 # Exportateurs
 - 389ds_exporter_terrycain
 - apache_exporter_lusitaniae
 - aerospike_exporter_alicebob
 # ... (et tout le reste des exportateurs) ...

Documentation des scripts Mesaguy

• promcron pour surveiller l'exécution des tâches cron
• promrun pour surveiller l'exécution des commandes
• sssd_check pour surveiller l'état de SSSD

Variables courantes

Par défaut, si un logiciel ou un binaire d'exportateur Prometheus échoue à s'installer, l'installation échoue. Ce paramètre par défaut peut être remplacé, ce qui permet une installation via le code source, en définissant le booléen global 'prometheus_fallback_to_build' ou un remplacement spécifique au logiciel. Par exemple, pour permettre au blackbox_exporter d'être construit à partir du code source si aucun binaire n'est trouvé :

prometheus_blackbox_exporter_fallback_to_build: true

Toutes les tâches d'installation de daemon ont un paramètre 'runas' pour spécifier quel utilisateur le daemon s'exécutera. Par défaut, tous les utilisateurs s'exécutent en tant que 'prometheus_user' (valeur par défaut : prometheus). Par exemple, pour que le blackbox_exporter s'exécute avec l'utilisateur 'test' :

prometheus_blackbox_exporter_runas: test

Variables globales

Créer un lien symbolique du répertoire etc de Prometheus vers '/etc/prometheus'. Le répertoire etc de Prometheus est par défaut '/opt/prometheus/etc' :

prometheus_link_etc: true

Essayer de forcer le lien symbolique du répertoire etc mentionné ci-dessus :

prometheus_link_etc_force: false

Installer l'utilitaire 'sponge'. Recommandé par le projet Prometheus lors de l'écriture dans le répertoire textfile de node_exporter. Le dépôt EPEL est requis si vous installez sur un dérivé de Red Hat Enterprise Linux. CentOS 8.x nécessite le dépôt yum 'CentOS-PowerTools', OracleLinux 7 nécessite le dépôt 'ol7_optional_archive', et Red Hat Enterprise Linux 8 nécessite le dépôt yum 'Red Hat CodeReady Linux Builder' soit activé :

prometheus_install_sponge: false

Purge les anciennes versions orphelines de logiciels :

prometheus_purge_orphans: false

Purge les sauvegardes des fichiers de configuration de prometheus du répertoire etc de prometheus après 'prometheus_etc_backup_max_age' jours (valeur par défaut : 31j). L'option 'prometheus_etc_purge_backups' est par défaut 'false' :

prometheus_etc_purge_backups: true
prometheus_etc_backup_max_age: 31d

Répertoire racine pour installer le logiciel Prometheus :

prometheus_root_dir: '/opt/prometheus'

Tester chaque port de service après l'installation et le démarrage de chaque service :

prometheus_test_service_port: true

Gérer l'utilisateur et le groupe de service 'prometheus' :

prometheus_manage_group: true
prometheus_manage_user: true

Nom du service et du groupe Prometheus :

prometheus_group: prometheus
prometheus_user: prometheus

Créer l'utilisateur et le groupe Prometheus en tant que comptes système, valeur par défaut 'false' :

prometheus_group_is_system: true
prometheus_user_is_system: true

Configurer les limites pour l'utilisateur 'prometheus' :

prometheus_configure_ulimits: false
prometheus_ulimit_hard_nofile: 8192
prometheus_ulimit_soft_nofile: 4096

Si l'installation d'un binaire d'application Prometheus échoue, passer à l'installation du logiciel Prometheus via le code source. L'installation à partir du code source nécessite généralement l'installation de compilateurs. Il est également possible d'activer 'fallback_to_build' au cas par cas (c'est-à-dire : prometheus_blackbox_exporter_fallback_to_build: true) :

prometheus_fallback_to_build: false

Version Go à utiliser lors de la construction du logiciel Prometheus :

prometheus_go_version: 1.13.10

Le répertoire etc de Prometheus, valeur par défaut '/opt/prometheus/etc' :

prometheus_etc_dir: "{{ prometheus_root_dir }}/etc"

Le répertoire racine dans lequel les exportateurs sont installés, valeur par défaut '/opt/prometheus/exporters' :

prometheus_exporters_dir: "{{ prometheus_root_dir }}/exporters"

Le répertoire racine dans lequel 'go' est installé. Go est uniquement installé si le logiciel Prometheus est installé à partir du code source. Valeur par défaut '/opt/prometheus/go' :

prometheus_go_dir: "{{ prometheus_root_dir }}/go"

Le répertoire dans lequel les logs sont créés. Les systèmes utilisant journalctl utiliseront généralement journalctl au lieu des fichiers :

prometheus_log_dir: "/var/log/prometheus"

Le répertoire à utiliser pour l'espace temporaire, principalement lors de la construction du logiciel Prometheus. Valeur par défaut '/opt/prometheus/tmp' :

prometheus_tmp_dir: "{{ prometheus_root_dir }}/tmp"

Le répertoire à utiliser lors du stockage des données persistantes de Prometheus (c'est-à-dire les données du serveur Prometheus), valeur par défaut '/opt/prometheus/var' :

prometheus_var_dir: "{{ prometheus_root_dir }}/var"

Désactiver éventuellement le lien symbolique des applications d'outils (amtool, promtool, etc.) vers /usr/local/bin. Valeur par défaut 'true' :

prometheus_symlink_tools: false

Mettre en cache les logiciels téléchargés sur l'hôte Ansible et pousser les logiciels en cache vers les hôtes distants que configure Ansible. Valeur par défaut désactivée via 'false' :

prometheus_local_archive: true
prometheus_local_archive_dir: ../archive/prometheus

Variables de gestion des règles Prometheus

Activer la gestion des 'règles' Prometheus :

prometheus_manage_rules: true

Emplacement local pour trouver les fichiers de règles, valeur par défaut vide (désactivé) :

prometheus_rules_source_dirs:
 - ../files/prometheus/rules
 - ../files/prometheus/additional_rules

Propriétés et permissions des fichiers de règles, par défaut :

prometheus_rules_dir_mode: 0755
prometheus_rules_file_mode: 0644
prometheus_rules_group: '{{ prometheus_group }}' # prometheus
prometheus_rules_owner: '{{ prometheus_user }}'  # prometheus

Purge les sauvegardes des fichiers de règles après 'prometheus_rules_backup_max_age' jours (valeur par défaut : 90j). L'option 'prometheus_rules_purge_backups' est par défaut 'false' :

prometheus_rules_purge_backups: true
prometheus_rules_backup_max_age: 90d

Purge les règles non définies (orphelines) des serveurs Prometheus. Par défaut, 'false' :

prometheus_rules_purge_orphans: true

Variables de rotation des logs Prometheus

La rotation des logs est désactivée par défaut, mais peut être configurée simplement en utilisant les variables suivantes. La rotation des logs est configurée pour tous les fichiers .log dans le répertoire des logs de Prometheus (c'est-à-dire : /var/log/prometheus/.log).

Activer l'installation d'un script de rotation des logs de Prometheus. Valeur par défaut 'false' :

prometheus_logrotate: true

Nombre de rotations des logs (jours) à conserver :

prometheus_logrotate_count: 31

Booléen spécifiant si les logs doivent être compressés :

prometheus_logrotate_compress: true

Répertoire du fichier de configuration de rotation des logs :

prometheus_logrotate_dir: /etc/logrotate.d

Variables client Prometheus

Faire en sorte que tous les serveurs Prometheus définis dans une variable de tableau/liste 'prometheus_servers' vérifient la connectivité à chacun des exportateurs des clients :

prometheus_software_server_side_connect_test: true

Configurer les règles firewalld pour permettre aux IP des serveurs définies dans une variable de tableau/liste 'prometheus_server_ips' de se connecter à chacun des exportateurs des clients. Cette fonctionnalité nécessite que le module python 'netaddr' soit installé (c'est-à-dire yum install -y python-netaddr ou dnf install -y python-netaddr ou pip install netaddr). N'activer cette variable que sur les serveurs qui utilisent firewalld, sinon la tâche échouera :

prometheus_manage_client_firewalld: true
# Optionnellement définir :
prometheus_firewalld_zone: public

Si une personnalisation de firewalld est nécessaire, on peut ajouter des règles firewalld en utilisant un playbook comme suit :

- name: Allow incoming prometheus server connections to node_exporter
  become: true
  firewalld:
    immediate: true
    port: 9100/tcp
    permanent: true
    source: "{{ item }}"
    state: enabled
    zone: public
  with_items: "{{ prometheus_server_ips }}"
  when: uses_firewalld is defined and 'node_exporter' in prometheus_components

Configurer des règles iptables pour permettre aux IP des serveurs définies dans une variable de tableau/liste 'prometheus_server_ips' de se connecter à chacun des exportateurs des clients. N'activer cette variable que sur les serveurs qui utilisent iptables, sinon la tâche échouera :

prometheus_manage_client_iptables: true

Si iptables_raw a été installé, vous pouvez activer la variable suivante :

prometheus_manage_client_iptables_raw: true

Ce rôle peut gérer automatiquement vos 'groupes cibles' (tgroups) du serveur Prometheus, créant dynamiquement des fichiers de tgroup dans un répertoire spécifié (/opt/prometheus/etc/tgroups par défaut) pour chaque exportateur client.

La gestion automatique des fichiers de tgroup peut être activée pour l'opération côté client, l'opération côté serveur, ou les deux. En mode client, les exportateurs des clients sont enregistrés automatiquement auprès du serveur Prometheus spécifié dans un tableau 'prometheus_servers'. En mode serveur, l'inventaire est analysé pour déterminer quels exportateurs sont disponibles sur chaque hôte et tous les clients sont enregistrés avec le serveur spécifié dans chacun des tableaux 'prometheus_servers' de ce client.

Par défaut, les tgroups côté client et serveur utilisent les valeurs 'inventory_hostname' (fqdn) et 'inventory_hostname_short' (nom d'hôte) pour les fqdn/nom d'hôte du serveur et ignorent les faits. Cela est fait car la population côté serveur des tgroups ne peut pas tenir compte des faits des clients à moins que les clients ne soient configurés pour mettre en cache leurs faits. Pour utiliser les variables basées sur les faits 'ansible_fqdn' (fqdn) et 'ansible_hostname' (nom d'hôte), activez 'prometheus_tgroup_use_facts'. À ce stade, activer 'prometheus_tgroup_use_facts' pour n'importe quel client désactive la gestion des tgroups côté serveur :

prometheus_tgroup_use_facts: true

Pour activer la génération automatique de fichiers de tgroup côté client, vous devez définir 'prometheus_manage_client_tgroups' comme vrai et énumérer vos serveurs Prometheus dans une variable 'prometheus_servers' dans vos variables Ansible ou votre inventaire. Cela créera des fichiers de tgroup dans /opt/prometheus/etc/ansible_tgroups :

prometheus_manage_client_tgroups: true
prometheus_servers:
 - 'prometheus1'
 - 'prometheus2'
# Optionnel, par défaut à /opt/prometheus/etc/tgroups :
prometheus_managed_tgroup_dir: '/opt/prometheus/etc/ansible_tgroups'

Si ce rôle gère vos fichiers de tgroup, vous pouvez appliquer des étiquettes à votre exportateur/s en utilisant la variable 'prometheus_tgroup_labels' :

- hosts: prometheus_clients
  vars:
    prometheus_components:
      - node_exporter
    prometheus_tgroup_labels:
      environment: development
      site: primary
  roles:
    - mesaguy.prometheus

En utilisant 'set_fact' pour faire de même :

• name: Set Prometheus labels for host set_fact: prometheus_tgroup_labels: environment: 'development' site: primary

Les exportateurs qui ne sont pas gérés par ce rôle peuvent être spécifiés en utilisant une variable 'prometheus_additional_exporters' comme suit. Toute étiquette spécifiée dans 'prometheus_tgroup_labels' sera fusionnée avec les étiquettes définies dans 'prometheus_additional_exporters'. Des règles de pare-feu seront créées pour les exportateurs supplémentaires si 'prometheus_manage_client_firewalld' ou 'prometheus_manage_client_iptables' est défini.

prometheus_additional_exporters:
 - name: docker
   port: 9323
   labels: {}
 - name: foo
   port: 9999
   labels:
     team: foo
     department: IT

Pour activer la génération automatique de fichiers de tgroup côté serveur, vous devez définir 'prometheus_manage_server_tgroups' comme vrai et énumérer vos serveurs Prometheus dans une variable 'prometheus_servers' dans vos variables Ansible ou votre inventaire. Cela créera des fichiers de tgroup dans /opt/prometheus/etc/ansible_tgroups pour tous les clients ayant 'prometheus_components' et/ou 'prometheus_additional_exporters', les clients doivent également avoir le tableau 'prometheus_servers' configuré :

prometheus_manage_server_tgroups: true

Pour ne configurer que les tgroups du serveur et ne réaliser aucune tâche de rôle, activez 'prometheus_manage_server_tgroups_only':

- hosts: prometheus_servers
  vars:
    prometheus_manage_server_tgroups_only: true
  roles:
    - mesaguy.prometheus

Purger les exportateurs indéfinis (orphelins). Lorsque exécuté en mode client, cette option n'affecte que les fichiers orphelins des clients. Lorsque exécuté en mode serveur, cela affecte tous les fichiers tgroup :

prometheus_tgroup_dir_purge_orphans: true

Spécifiez un FQDN pour un hôte lorsque le FQDN n'est pas dans l'inventaire d'Ansible et n'est pas le FQDN officiel de l'hôte. Cette option devrait généralement être évitée, corriger DNS ou l'inventaire d'Ansible est une meilleure option :

prometheus_override_fqdn: weird-hostname.example.org

Configuration du serveur Prometheus

Pour activer le serveur Prometheus incluez la tâche de rôle : prometheus.

Les fichiers de configuration de Prometheus sont validés à l'aide de 'promtool' avant que Prometheus ne redémarre.

Le contenu de la configuration. L'exemple ci-dessous utilise un fichier nommé 'prometheus_server.yml' dans le répertoire 'files' de votre répertoire racine Ansible. Si aucun contenu de configuration n'est défini, un fichier de configuration par défaut est utilisé. Vous voudrez personnaliser le contenu de votre fichier de configuration ! :

prometheus_server_cfg: '{{ lookup("file", "../files/prometheus_server.yml") | from_yaml }}'

Ou en intégrant le YAML directement dans votre playbook :

  prometheus_server_cfg:
    global:
      scrape_interval: 15s

      # Attachez ces étiquettes à toute série temporelle ou alertes lors de la communication avec
      # des systèmes externes (fédération, stockage distant, Alertmanager).
      external_labels:
        monitor: 'codelab-monitor'

    # Une configuration de scrape contenant exactement un point de terminaison à scrapper :
    # Ici, c'est Prometheus lui-même.
    scrape_configs:
      # Le nom du travail est ajouté en tant qu'étiquette `job=<job_name>` à toute série temporelle scrappée à partir de cette config.
      - job_name: 'prometheus'

        # Remplacez le défaut global et scrappez les cibles de ce travail toutes les 5 secondes.
        scrape_interval: 5s

        static_configs:
          - targets: ['localhost:9090']

Un tableau d'options supplémentaires à passer au démon Prometheus :

prometheus_extra_opts: []

La version de Prometheus à installer. La version par défaut peut être trouvée dans le fichier des variables prometheus et la version par défaut peut être remplacée en utilisant la variable suivante :

prometheus_version: "v1.0.0"

Autoriser l'utilisation de versions préliminaires (versions bêta, test, développement, etc.), par défaut 'false' :

prometheus_use_prerelease: true

Où stocker la base de données de Prometheus, par défaut /opt/prometheus/var/prometheus :

prometheus_storage_dir: /opt/prometheus/var/prometheus

Modèles de console web Prometheus à utiliser. Les valeurs par défaut sont suffisantes dans la plupart des cas et cette variable devrait rester non définie dans la plupart des cas :

prometheus_web_console_libraries_dir: /opt/prometheus/prometheus/x.x.x/console_libraries
prometheus_web_console_templates_dir: /opt/prometheus/prometheus/x.x.x/consoles

Port et IP à écouter. Par défaut, écoute sur toutes les IP disponibles sur le port 9090 :

prometheus_host: "0.0.0.0"
prometheus_port: 9090

Exemple de playbook

Serveur Prometheus

L'exemple suivant installe Prometheus (serveur), alertmanager, blackbox_exporter, et le node_exporter. Les paramètres de port et de rétention de stockage de Prometheus (serveur) ont été modifiés par rapport aux valeurs par défaut.

Le serveur Prometheus ne devrait être installé que sur les hôtes serveurs Prometheus désignés. Les clients Prometheus ne devraient avoir que certains exportateurs spécifiques installés.

Méthode d'utilisation de classe :

- hosts: prometheus_servers
  vars:
    prometheus_components:
      - prometheus
      - alertmanager
      - blackbox_exporter
      - node_exporter
    prometheus_port: 10000
    prometheus_extra_opts:
     - '--storage.tsdb.retention=90d'
  roles:
    - mesaguy.prometheus

Méthode d'utilisation 'include_role' plus longue :

- hosts: prometheus_servers
  vars:
    prometheus_port: 10000
    prometheus_extra_opts:
     - '--storage.tsdb.retention=90d'
  tasks:
  - name: Serveur Prometheus
    include_role:
      name: mesaguy.prometheus
      tasks_from: '{{ prometheus_component }}'
    loop_control:
      loop_var: prometheus_component
    with_items:
      - prometheus
      - alertmanager
      - blackbox_exporter
      - node_exporter

Informations supplémentaires

Méthodes d'installation de logiciels

Les installations sont effectuées à l'aide de fichiers binaires précompilés lorsque cela est possible. Lorsque les binaires précompilés ne sont pas disponibles, ce rôle Ansible :

1. Installe les outils nécessaires à la compilation des binaires
2. Compile les binaires
3. Installe les binaires dans un répertoire spécifiant à la fois la version du logiciel Prometheus et la version de Go utilisée pour l'installation (c'est-à-dire : /opt/prometheus/exporters/smokeping_exporter_superq/v0.3.1__go-1.14.14/smokeping_prober)

Si un binaire échoue à s'installer ou est indisponible malgré l'existence de certains binaires précompilés, le module Prometheus sera tout de même installé à l'aide du code source.

Sécurité

Ce module ne gère pas les règles de pare-feu, n'emploie pas le https, ni n'emploie d'authentification pour sécuriser le logiciel Prometheus. Toutes ces mesures de sécurité sont utiles, mais sont actuellement en dehors de portée de ce rôle.

Nous surveillons de près la sortie des nouveaux logiciels Prometheus ainsi que du compilateur Go et publions de nouvelles versions de ce rôle Ansible en conséquence.

Tous les daemons s'exécutent par défaut via un utilisateur 'prometheus' non privilégié.

Lorsque le logiciel Prometheus est installé à l'aide du code source, le répertoire de destination d'installation est nommé pour à la fois la version du logiciel Prometheus et la version du compilateur Go. Cette convention de nommage garantit que l'utilisation de versions plus récentes du compilateur Go force une reconstruction des modules Prometheus construits à partir du code source. Cette convention de nommage différencie également les installations par binaire des installations par code source compilé. Forcer les reconstructions du code source de Prometheus chaque fois qu'une nouvelle version de Go est publiée a l'inconvénient d'introduire plus de travail pour les clients, mais a le bénéfice d'assurer que toutes les vulnérabilités au sein des bibliothèques de base Go sont corrigées. Nous supposons que le logiciel Prometheus qui est fourni sous forme binaire est surveillé pour les vulnérabilités par le développeur et reconstruit si nécessaire.

Futur : Lorsque le code source est compilé, toutes les commandes de compilation sont exécutées à l'aide d'un compte utilisateur non privilégié. Cela, combiné avec l'exécution de daemons sous un utilisateur non privilégié, atténue de nombreux risques de sécurité. -- Cela est actuellement compliqué par des limites avec become.

Licence

MIT Voir le fichier LICENSE

Informations sur l'auteur

Mesaguy

• https://github.com/mesaguy