0x0i.prometheus
Rôle Ansible :fire: :straight_ruler: Prometheus
Table des Matières
- Plateformes Supportées
- Exigences
- Variables de Rôle
- Dépendances
- Exemple de Playbook
- Licence
- Informations sur l’Auteur
Rôle Ansible qui installe et configure Prometheus : une base de données de séries temporelles multi-dimensionnelle et un outil de surveillance/alerte.
Plateformes Supportées :
* Debian
* Redhat (CentOS/Fedora)
* Ubuntu
Exigences
Nécessite l'utilitaire unzip/gtar installé sur l'hôte cible. Voir les notes du module ansible unarchive ici pour plus de détails.
Variables de Rôle
Les variables sont organisées selon les étapes suivantes de provisionnement logiciel et matériel :
- installation
- configuration
- lancement
- désinstallation
Installation
prometheus et son alertmanager associé peuvent être installés à l'aide d'archives compressées (.tar, .zip), téléchargées et extraites de diverses sources.
Les variables suivantes peuvent être personnalisées pour contrôler divers aspects de ce processus d'installation, de la version du logiciel et de l'emplacement source des binaires à l'annuaire d'installation où ils sont stockés :
managed_services: <liste-de-services (prometheus | alertmanager)> (par défaut: ['prometheus'])
- liste des services de l'outil Prometheus à gérer via ce rôle
prometheus_user: <nom-utilisateur-service> (par défaut: prometheus)
- utilisateur et groupe de service dédiés utilisés par
prometheuspour la séparation des privilèges (voir ici pour plus de détails)
install_dir: </chemin/vers/annuaire/d'installation> (par défaut: /opt/prometheus)
- chemin sur l'hôte cible où les binaires
prometheusdoivent être extraits
archive_url: <chemin-ou-url-vers-archive> (par défaut: voir defaults/main.yml)
- adresse d'une archive tar ou zip compressée contenant des binaires
prometheus. Cette méthode supporte techniquement l'installation de n'importe quelle version disponible deprometheus. Des liens vers les versions officielles peuvent être trouvés ici.
archive_checksum: <chemin-ou-url-vers-checksum> (par défaut: voir defaults/main.yml)
- adresse d'un fichier de somme de contrôle pour vérifier l'intégrité des données de l'archive spécifiée
prometheus. Bien que recommandé et généralement considéré comme une bonne pratique, spécifier une somme de contrôle n'est pas obligatoire et peut être désactivé en fournissant une chaîne vide ('') pour sa valeur.
checksum_format: <chaîne> (par défaut: voir sha256)
- algorithme de hachage utilisé pour la vérification des fichiers associée à la somme de contrôle de l'archive spécifiée. Référence ici pour plus d'informations sur les checksums/cryptographic hashes.
alertmgr_installdir: </chemin/vers/annuaire/d'installation> (par défaut: /opt/alertmanager)
- chemin sur l'hôte cible où les binaires
alertmanagerdoivent être extraits
exporter_installdir: </chemin/vers/annuaire/d'installation> (par défaut: {{ install_dir }}/exporters)
- chemin sur l'hôte cible où les binaires des exportateurs Prometheus doivent être extraits
alertmgr_archive_url: <chemin-ou-url-vers-archive> (par défaut: voir defaults/main.yml)
- adresse d'une archive tar ou zip compressée contenant des binaires
alertmanager. Cette méthode supporte techniquement l'installation de n'importe quelle version disponible dealertmanager. Des liens vers les versions officielles peuvent être trouvés ici.
alertmgr_archive_checksum: <chemin-ou-url-vers-checksum> (par défaut: voir defaults/main.yml)
- adresse d'un fichier de somme de contrôle pour vérifier l'intégrité des données de l'archive spécifiée
alertmanager. Bien que recommandé, spécifier une somme de contrôle n'est pas obligatoire et peut être désactivé en fournissant une chaîne vide ('') pour sa valeur.
alertmgr_checksum_format: <chaîne> (par défaut: voir sha256)
- algorithme de hachage utilisé pour la vérification des fichiers associée à la somme de contrôle de l'archive spécifiée. Référence ici pour plus d'informations sur les checksums/cryptographic hashes.
filesd_path: </chemin/vers/fichiers-sd> (par défaut: {{ install_dir }}/filesd)
- chemin sur l'hôte cible où les fichiers de découverte de fichiers Prometheus doivent être stockés par défaut
rules_path: </chemin/vers/fichiers-de-règles> (par défaut: {{ install_dir }}/rules.d)
- chemin sur l'hôte cible où les fichiers de règles Prometheus doivent être stockés par défaut
templates_path: </chemin/vers/fichiers-modèles-alertmanager> (par défaut: {{ alertmgr_installdir }}/templates)
- chemin sur l'hôte cible où les fichiers de modèles alertmanager doivent être stockés par défaut
Configuration
Avec ce rôle, la configuration d'une installation de prometheus est organisée selon les composants suivants :
- configuration du service prometheus (
prometheus.yml) - découverte de services de fichiers (
file_sd - *.[json|yml]) - règles d'enregistrement et d'alerte (
rule_files - *.[json|yml]) - configuration du service alertmanager (
alertmanager.yml) - fichiers de modèles alertmanager (
*.tmpl)
Chaque configuration peut être exprimée au sein des variables suivantes pour personnaliser le contenu et les paramètres des fichiers de configuration désignés à rendre :
config_dir: </chemin/vers/annuaire/de/configuration> (par défaut: {{ install_dir }})
- chemin sur l'hôte cible où les fichiers de configuration
prometheusdoivent être rendus
data_dir: </chemin/vers/annuaire/de/données> (par défaut: /var/data/prometheus)
- chemin sur l'hôte cible où
prometheusstocke les données
alertmgr_configdir: </chemin/vers/annuaire/de/configuration> (par défaut: {{ alertmgr_installdir }})
- chemin sur l'hôte cible où les fichiers de configuration
alertmanagerdoivent être rendus
alertmgr_datadir: </chemin/vers/annuaire/de/données> (par défaut: /var/data/alertmanager)
- chemin sur l'hôte cible où
alertmanagerstocke les données
Configuration du Service Prometheus
La configuration du service Prometheus peut être exprimée au sein du hash, prometheus_config, qui contient une série de paires clé-valeur représentant une section indiquant les différentes cibles de scraping (sources à partir desquelles collecter des métriques), mécanismes de découverte de services, ensembles de règles d'enregistrement/d'alerte et configurations pour l'interfaçage avec les systèmes de lecture/écriture distants utilisés par le service Prometheus.
Les valeurs de ces clés sont généralement des dicts ou des listes de dicts contenant elles-mêmes un ensemble de paires clé-valeur représentant les spécifications/settings associées (par exemple, l'intervalle de scraping ou la fréquence à laquelle récupérer les cibles pour les métriques globalement) pour chaque section. Ce qui suit fournit un aperçu et des exemples de configurations pour chacun.
:global
[prometheus_config:] global: <clé: valeur,...> (par défaut: voir defaults/main.yml)
- spécifie des paramètres qui sont valides et servent de valeurs par défaut dans tous les autres contextes de configuration. Voir ici pour plus de détails.
Exemple
prometheus_config:
global:
# À quelle fréquence récupérer les cibles par défaut.
scrape_interval: 15s
# Après combien de temps une requête de scraping expire.
scrape_timeout: 30s
# À quelle fréquence évaluer les règles.
evaluation_interval: 30s
# Les labels à ajouter à toute série temporelle ou alertes lors de la communication avec
# des systèmes externes (fédération, stockage à distance, Alertmanager).
external_labels:
monitor: example
foo: bar
:scrape_configs
[prometheus_config:] scrape_configs: <liste-des-dicts> (par défaut: voir defaults/main.yml)
- spécifie un ensemble de cibles et les paramètres décrivant comment les récupérer organisés en travaux
Les cibles peuvent être configurées statiquement ou découvertes dynamiquement à l'aide de l'un des mécanismes de découverte de services supportés. Voir ici pour plus de détails et ici pour une liste des méthodes de découverte de services supportées.
Exemple
prometheus_config:
scrape_configs:
- job_name: static-example
static_configs:
- targets: ['localhost:9090', 'localhost:9191']
labels:
example: label
- job_name: kubernetes-example
kubernetes_sd_configs:
- role: endpoints
api_server: 'https://localhost:1234'
namespaces:
names:
- default
:rule_files
[prometheus_config:] rule_files: <liste> (par défaut: voir defaults/main.yml)
- spécifie une liste de motifs indiquant les noms de fichiers et chemins
Les règles et alertes sont lues à partir de tous les fichiers correspondants. Les règles tombent dans l'une des deux catégories : règles d'enregistrement et règles d'alerte. Voir ici pour des détails autour des règles d'enregistrement et ici pour des détails autour des règles d'alerte.
Exemple
prometheus_config:
rule_files:
- "example.yml"
- "example_rules/*"
:remote_read
[prometheus_config:] remote_read: <liste-des-dicts> (par défaut: voir defaults/main.yml)
- spécifie les paramètres liés à la fonctionnalité de lecture distante
Voir ici pour plus de détails. Pour une liste des plugins d'intégration de lecture/stockage à distance disponibles, consultez ce lien.
Exemple
prometheus_config:
remote_read:
- url: http://remote1/read
read_recent: true
name: default
- url: http://remote2/read
read_recent: false
name: read_special
required_matchers:
job: special
tls_config:
cert_file: valid_cert_file
key_file: valid_key_file
:remote_write
[prometheus_config:] remote_write: <liste-des-dicts> (par défaut: voir defaults/main.yml)
- spécifie les paramètres liés à la fonctionnalité d'écriture distante
Voir ici pour plus de détails. Pour une liste des plugins d'intégration d'écriture/stockage à distance disponibles, consultez ce lien.
Exemple
prometheus_config:
remote_write:
- name: drop_expensive
url: http://remote1/push
write_relabel_configs:
- source_labels: [__name__]
regex: expensive.*
action: drop
- name: rw_tls
url: http://remote2/push
tls_config:
cert_file: valid_cert_file
key_file: valid_key_file
:alerting
[prometheus_config:] alerting: <clé: valeur,...> (par défaut: voir defaults/main.yml)
- spécifie les paramètres liés à l’Alertmanager en plus des instances Alertmanager auxquelles le serveur Prometheus envoie des alertes
Cette section fournit les paramètres pour configurer comment communiquer avec ces Alertmanagers. Les Alertmanagers peuvent être configurés statiquement via le paramètre de configuration statique ou découvert dynamiquement à l'aide de l'un des mécanismes de découverte de services supportés. Voir ici pour plus de détails.
Exemple
prometheus_config:
alerting:
alertmanagers:
- scheme: https
static_configs:
- targets:
- "1.2.3.4:9093"
- "1.2.3.5:9093"
Découverte de Services par Fichier
La découverte de services par fichier fournit un moyen plus générique de configurer des cibles statiques et sert d'interface pour brancher des mécanismes de découverte de services personnalisés. Elle lit un ensemble de fichiers contenant une liste de zéro ou plusieurs <static_config>s. Les changements dans tous les fichiers définis sont détectés via des surveillances de disque et appliqués immédiatement. Les fichiers peuvent être fournis en format YAML ou JSON. Seuls les changements aboutissant à des groupes cibles bien formés sont appliqués. Voir ici pour plus de détails.
prometheus_file_sd: <liste-des-dicts> (par défaut: [])
- spécifie les configurations file_sd prometheus à rendre
Avec ce rôle, les paramètres de configuration de découverte de services par fichier peuvent être exprimés au sein du hash, prometheus_file_sd, qui contient une liste de dicts encapsulant le chemin, le nom et le contenu de configuration d'un fichier yaml ou json à charger par prometheus pour la découverte par fichier.
[prometheus_file_sd : <entrée>:] name: <chaîne> (par défaut: AUCUN - obligatoire)
- nom du fichier_sd à rendre
[prometheus_file_sd : <entrée>:] path: <chaîne> (par défaut: {{ install_dir }}/file_sd)
- chemin du fichier_sd à rendre
[prometheus_file_sd : <entrée>:] config: <liste-des-dicts> (par défaut: AUCUN - obligatoire)
- liste de dictionnaires représentant les paramètres indiquant un ensemble de cibles statiques à spécifier dans le fichier_sd
Exemple
prometheus_file_sd:
- name: example-file.slow.json
config:
- targets: ["host1:1234"]
labels:
test-label: example-slow-file-sd
- name: file.yml
path: /etc/prometheus/file_sd
config:
- targets: ["host2:1234"]
NB : Une configuration de scrape_config file_sd associée est attendue dans le fichier prometheus.yml pour un chargement réussi.
Fichiers de Règles
Prometheus prend en charge deux types de règles qui peuvent être configurées puis évaluées à des intervalles réguliers : les règles d'enregistrement et les règles d'alerte. Les règles d'enregistrement vous permettent de calculer à l'avance des expressions fréquemment nécessaires ou coûteuses en calcul et d'enregistrer leur résultat comme un nouvel ensemble de séries temporelles. Les règles d'alerte vous permettent de définir des conditions d'alerte basées sur les expressions du langage d'expression de Prometheus et d'envoyer des notifications pour les alertes déclenchées à un service externe. Voir ici pour plus de détails.
prometheus_rule_files: <liste-des-dicts> (par défaut: [])
- spécifie les fichiers de règles prometheus à rendre
Avec ce rôle, les deux types de règles peuvent être exprimés au sein du hash, prometheus_rule_files, qui contient une liste de dicts encapsulant le chemin, le nom et le contenu de configuration d'un fichier yaml ou json à charger par prometheus pour la configuration des règles.
[prometheus_rule_files : <entrée>:] name: <chaîne> (par défaut: AUCUN - obligatoire)
- nom du fichier de règles à rendre
[prometheus_rule_files : <entrée>:] path: <chaîne> (par défaut: {{ install_dir }}/rules.d)
- chemin du fichier de règles à rendre
[prometheus_rule_files : <entrée>:] config: <liste-des-dicts> (par défaut: AUCUN - obligatoire)
- liste de dictionnaires représentant les paramètres indiquant un ensemble de groupes de règles à spécifier dans le fichier de règles
Exemple
prometheus_rule_files:
- name: example-rules.yml
config:
groups:
- name: exemple de règle d'enregistrement
rules:
- record: job:http_inprogress_requests:sum
expr: sum(http_inprogress_requests) by (job)
- name: nondefault-path-example-rules.yml
path: /etc/prometheus/rules.d
config:
groups:
- name: exemple de règle d'alerte
rules:
- alert: HighRequestLatency
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
for: 10m
labels:
severity: page
annotations:
summary: Latence de requête élevée
NB : Une section rule_files associée est attendue dans le fichier prometheus.yml pour un chargement réussi.
Configuration du Service Alertmanager
La configuration du service Alertmanager peut être exprimée au sein du hash, alertmanager_config, qui contient une série de paires clé-valeur représentant l'une d'un ensemble de sections indiquant diverses configurations de routage, récepteur, modèles et inhibition des alertes.
Les valeurs de ces clés sont généralement des dicts ou des listes de dicts contenant elles-mêmes un ensemble de paires clé-valeur représentant les spécifications/settings associées (par exemple, l'URL API à utiliser pour les notifications Slack) pour chaque section. Ce qui suit fournit un aperçu et des exemples de configurations pour référence.
:global
[alertmanager_config:] global: <clé: valeur,...> (par défaut: voir defaults/main.yml)
- spécifie des paramètres valides qui servent de valeurs par défaut dans tous les autres contextes de configuration. Voir ici pour plus de détails.
Exemple
alertmanager_config:
global:
# Le smarthost et l'expéditeur SMTP utilisés pour les notifications par mail.
smtp_smarthost: 'localhost:25'
smtp_from: '[email protected]'
smtp_auth_username: 'alertmanager'
smtp_auth_password: 'password'
# Le token d'authentification pour Hipchat.
hipchat_auth_token: '1234556789'
# L'hôte alternatif pour Hipchat.
hipchat_api_url: 'https://hipchat.foobar.org/'
:route
[alertmanager_config:] route: <clé: valeur,...> (par défaut: voir defaults/main.yml)
- définit un nœud dans un arbre de routage et ses enfants
Chaque alerte entre dans l'arbre de routage au niveau du routeur supérieur configuré, qui doit correspondre à toutes les alertes (c'est-à-dire ne pas avoir de matchers configurés). Elle traverse ensuite les nœuds enfants. Si continue est défini sur false, il s'arrête après le premier enfant correspondant. Si continue est vrai sur un nœud correspondant, l'alerte continuera de correspondre aux frères suivants. Voir ici pour plus de détails.
Exemple
alertmanager_config:
route:
receiver: 'récepteur-par-défaut'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [cluster, alertname]
# Toutes les alertes qui ne correspondent pas aux routes enfants suivantes
# resteront au nœud racine et seront envoyées au 'récepteur-par-défaut'.
routes:
# Toutes les alertes avec service=mysql ou service=cassandra
# sont envoyées au pager de la base de données.
- receiver: 'database-pager'
group_wait: 10s
match_re:
service: mysql|cassandra
# Toutes les alertes avec le label team=frontend correspondent à cette sous-route.
# Elles sont regroupées par produit et environnement plutôt que par cluster
# et nom d'alerte.
- receiver: 'frontend-pager'
group_by: [produit, environnement]
match:
team: frontend
:receivers
[alertmanager_config:] inhibit_rules: <liste-des-dicts> (par défaut: voir defaults/main.yml)
- spécifie une liste de récepteurs de notifications
Les récepteurs sont une configuration nommée d'une ou plusieurs intégrations de notification. Voir ici pour plus de détails.
Exemple
alertmanager_config:
receivers:
- name: 'team-X-mails'
email_configs:
- to: '[email protected]'
pagerduty_configs:
- service_key: <team-X-key>
hipchat_configs:
- auth_token: <auth_token>
room_id: 85
message_format: html
notify: true
:inhibit_rules
[alertmanager_config:] inhibit_rules: <liste-des-dicts> (par défaut: voir defaults/main.yml)
- spécifie une liste de règles d'inhibition
Une règle d'inhibition mute une alerte (cible) correspondant à un ensemble de matchers lorsqu'une alerte (source) existe qui correspond à un autre ensemble de matchers. Voir ici pour plus de détails.
Exemple
alertmanager_config:
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
# Appliquer l'inhibition si le nom de l'alerte est le même.
equal: ['alertname', 'cluster', 'service']
:templates
[alertmanager_config:] templates: <liste> (par défaut: voir defaults/main.yml)
- spécifie des fichiers et des répertoires à partir desquels les modèles de notification sont lus
Le dernier composant peut utiliser un motif générique, par exemple, templates/*.tmpl. Voir ici pour une référence de modèles de notification et ce lien pour des exemples.
Exemple
alertmanager_config:
templates:
- '/etc/alertmanager/template/*.tmpl'
Modèles d'Alertmanager
Prometheus crée et envoie des alertes à l'Alertmanager qui envoie ensuite des notifications à différents récepteurs en fonction de leurs labels. Les notifications envoyées aux récepteurs sont construites via des modèles. L'Alertmanager est livré avec des modèles par défaut, mais ils peuvent aussi être personnalisés. Voir ici pour plus de détails.
alertmanager_templates: <liste-des-dicts> (par défaut: [])
- spécifie les configurations de modèle de notification d'alertmanager à rendre
Avec ce rôle, les paramètres de configuration de modèle d'alertmanager peuvent être exprimés au sein du hash, alertmanager_templates, qui contient une liste de dicts représentant et encapsulant le chemin, le nom et le contenu de configuration d'un fichier tmpl à charger par alertmanager.
[alertmanager_templates : <entrée>:] name: <chaîne> (par défaut: AUCUN - obligatoire)
- nom du fichier de modèle à rendre
[alertmanager_templates : <entrée>:] path: <chaîne> (par défaut: {{ alertmgr_installdir }}/templates)
- chemin du fichier de modèle à rendre
[alertmanager_templates : <entrée>:] config: <liste-des-dicts> (par défaut: AUCUN - obligatoire)
- liste de dictionnaires représentant les paramètres indiquant un ensemble de configurations de modèle à rendre
Exemple
alertmanager_templates:
- name: test
config:
- define: "myorg.test.guide"
template: 'https://internal.myorg.net/wiki/alerts/\{\{ .GroupLabels.app \}\}/\{\{ .GroupLabels.alertname \}\}'
- name: test2
path: /etc/alertmanager/templates
config:
- define: "myorg.test.text"
template: 'summary: \{\{ .CommonAnnotations.summary \}\}\ndescription: \{\{ .CommonAnnotations.description \}\}'
NB : Une section de configuration templates associée est attendue dans le fichier alertmanager.yml pour un chargement réussi.
Lancement
Ce rôle prend en charge le lancement de tous les composants de l'écosystème de surveillance et d'alerte de Prometheus. Cela consiste en services Prometheus et Alertmanager ainsi qu'une multitude d'exportateurs de métriques. L'exécution de chacun est réalisée en utilisant l'outil de gestion de services systemd qui gère les services en tant que processus d'arrière-plan ou démons, soumis à la configuration et au potentiel d'exécution fournis par son infrastructure de gestion sous-jacente.
Les variables suivantes peuvent être personnalisées pour gérer la définition de l'unité [Service] de systemd et le profil/application d'exécution des services :
Prometheus
extra_run_args: <options-cli-prometheus> (par défaut: [])
- liste des arguments en ligne de commande
prometheusà passer au binaire à l'exécution pour personnaliser le lancement.
Supportant l'expression complète de prometheus's cli, cette variable permet de personnaliser le lancement selon les spécifications de l'utilisateur.
custom_unit_properties: <hash-des-paramètres-du-service-systemd> (par défaut: [])
- hash des paramètres utilisés pour personnaliser la configuration de l'unité
[Service]et l'environnement d'exécution du service systemd de Prometheus.
Alertmanager
extra_alertmgr_args: <options-cli-alertmanager> (par défaut: [])
- liste des arguments en ligne de commande
alertmanagerà passer au binaire à l'exécution pour personnaliser le lancement.
Supportant l'expression complète de alertmanager's cli, cette variable permet de personnaliser le lancement selon les spécifications de l'utilisateur.
custom_alertmgr_properties: <hash-des-paramètres-du-service-systemd> (par défaut: [])
- hash des paramètres utilisés pour personnaliser la configuration de l'unité
[Service]et l'environnement d'exécution du service systemd de Alertmanager.
Exportateurs
prometheus_exporters: <liste-des-dicts> (par défaut: [])
- spécifie les exportateurs prometheus à installer, lancer et gérer en tant que services systemd.
Chaque entrée dict d'exportateur doit indiquer plusieurs propriétés, y compris le nom ; l'URL et l'adresse d'écoute, de l'exportateur cible pour un bon paramétrage et communication avec un serveur Prometheus. D'autres propriétés utilisées pour personnaliser l'opération de l'exportateur peuvent être spécifiées via une variable extra_args, qui ajoute les arguments de ligne de commande fournis à l'option ExecStart de l'unité. Voir ici pour plus de détails et une liste des plugins d'exportateurs en référence.
[prometheus_exporters : <entrée>:] name: <chaîne> (par défaut: AUCUN - obligatoire)
- nom de l'exportateur Prometheus à installer
[prometheus_exporters : <entrée>:] url: <chaîne> (par défaut: AUCUN - obligatoire)
- URL de l'exportateur Prometheus à installer
[prometheus_exporters : <entrée>:] description: <chaîne> (par défaut: <nom-exportateur>)
- description ou documentation de l'exportateur Prometheus à inclure dans le fichier d'unité de l'exportateur
[prometheus_exporters : <entrée>:] unit_properties: <hash> (par défaut: {})
- hash des paramètres utilisés pour personnaliser la configuration de l'unité
[Service]et l'environnement d'exécution du service desystemd.
Exemple
prometheus_exporters:
- name: node_exporter
url: https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
description: https://github.com/prometheus/node_exporter
unit_properties:
User: exporter
Group: exporter
extra_args:
- '--web.listen-address=0.0.0.0:9110'
- '--log.level=debug'
Désinstallation
Le support de la désinstallation et de la suppression des artefacts nécessaires au provisionnement permet aux utilisateurs/opérateurs de ramener un hôte cible à son état configuré avant l'application de ce rôle. Cela peut être utile pour recycler les nœuds et les rôles et peut-être fournir des transitions plus gérées/propres entre les mises à jour des outils.
Les variable(s) suivantes peuvent être personnalisées pour gérer ce processus de désinstallation :
perform_uninstall: <true | false> (par défaut: false)
- pour savoir s'il faut désinstaller et supprimer tous les artefacts et restes de cette installation
prometheussur un hôte cible (voir:handlers/main.ymlpour plus de détails)
Dépendances
- 0x0i.systemd
Exemple de Playbook
exemple par défaut :
- hosts: all
roles:
- role: 0x0I.prometheus
installer uniquement et gérer le service Prometheus (désactiver la configuration de l'alertmanager) :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
managed_services: ['prometheus']
installer une version spécifique de Prometheus :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
archive_url: https://github.com/prometheus/prometheus/releases/download/v2.15.0/prometheus-2.15.0.linux-amd64.tar.gz
archive_checksum: 1c2175428e7a70297d97a30a04278b86ccd6fc53bf481344936d6573482203b4
ajuster les annuaires d'installation, de configuration et de données de Prometheus et Alertmanager :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
install_dir: /usr/local
config_dir: /etc/prometheus
data_dir: /var/lib/prometheus
alertmgr_installdir: /usr/local
alertmgr_configdir: /etc/alertmanager
alertmgr_datadir: /var/lib/alertmanager
personnaliser les réglages globaux de scraping et d'évaluation :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
global:
scrape_interval: 30s
scrape_timeout: 30s
evaluation_interval: 30s
personnaliser la configuration d'alerte/alertmanager de prometheus :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
alerting:
alertmanagers:
- scheme: https
static_configs:
- targets:
- "1.2.3.4:9093"
créer des règles d'enregistrement et d'alerte :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
rule_files:
- /etc/prometheus/rules.d/*
prometheus_rule_files:
- name: example-rules.yml
path: /etc/prometheus/rules.d/*
config:
groups:
- name: recording rule example
rules:
- record: job:http_inprogress_requests:sum
expr: sum(http_inprogress_requests) by (job)
- name: another-example.yml
path: /etc/prometheus/rules.d
config:
groups:
- name: alerting rule example
rules:
- alert: HighRequestLatency
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
for: 10m
labels:
severity: page
annotations:
summary: High request latency
configuration de cible statique avec des réglages de scraping et d'évaluation :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: static-example
static_configs:
- targets: ['localhost:9090', 'localhost:9191']
labels:
my: label
your: label
scrape_interval: 10s
scrape_timeout: 10s
evaluation_interval: 10s
configuration de scrape_config basée sur fichier avec des réglages de scraping et d'évaluation :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: file-sd-example
file_sd_configs:
- files:
- foo/*.slow.json
- single/file.yml
refresh_interval: 10m
- files:
- bar/*.yml
prometheus_file_sd:
- name: example-file.slow.json
path: foo
config:
- targets: ["host1:1234"]
labels:
test-label: example-slow-file-sd
- name: foo.yml
path: bar
config:
- targets: ["host2:1234"]
- name: file.yml
path: single
config:
- targets: ["host3:1234"]
configuration de cible dns :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: dns-example
dns_sd_configs:
- refresh_interval: 15s
names:
- first.dns.address.domain.com
- second.dns.address.domain.com
- names:
- third.dns.address.domain.com
configuration de cible kubernetes avec TLS et authentification basique :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: kubernetes-example
kubernetes_sd_configs:
- role: endpoints
api_server: 'https://localhost:1234'
tls_config:
cert_file: valid_cert_file
key_file: valid_key_file
basic_auth:
username: 'myusername'
password: 'mysecret'
configuration de cible ec2 :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: ec2-example
ec2_sd_configs:
- region: us-east-1
access_key: access
secret_key: mysecret
profile: profile
filters:
- name: tag:environment
values:
- prod
- name: tag:service
values:
- web
- db
configuration de cible openstack :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: openstack-example
openstack_sd_configs:
- role: instance
region: RegionOne
port: 80
refresh_interval: 1m
configuration de cible azure :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: azure-example
azure_sd_configs:
- environment: AzurePublicCloud
authentication_method: OAuth
subscription_id: 11AAAA11-A11A-111A-A111-1111A1111A11
tenant_id: BBBB222B-B2B2-2B22-B222-2BB2222BB2B2
client_id: 333333CC-3C33-3333-CCC3-33C3CCCCC33C
client_secret: mysecret
port: 9100
configuration de cible marathon :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: marathon-example
marathon_sd_configs:
- servers:
- 'https://marathon.example.com:443'
auth_token: "mysecret"
configuration de cible consul :
- hosts: all
roles:
- role: 0x0I.prometheus
vars:
prometheus_config:
scrape_configs:
- job_name: consul-example
consul_sd_configs:
- server: 'localhost:1234'
token: mysecret
services: ['nginx', 'cache', 'mysql']
tags: ["canary", "v1"]
node_meta:
rack: "123"
allow_stale: true
scheme: https
Licence
MIT
Informations sur l’Auteur
Ce rôle a été créé en 2019 par O1.IO.
Prometheus - a multi-dimensional time-series data monitoring and alerting toolkit
ansible-galaxy install 0x0i.prometheus