Comment utiliser Alertmanager et Blackbox Exporter pour surveiller votre serveur Web sur Ubuntu 16.04

L’auteur a choisi le Tech Education Fund pour recevoir un don de 300 $ dans le cadre du programme Write for DOnations .

introduction

En cas de problème, l’envoi d’alertes à l’équipe appropriée accélère considérablement l’identification de la cause première du problème, permettant ainsi aux équipes de résoudre rapidement les incidents.

Prometheus est un système de surveillance open source qui collecte les métriques de vos services et les stocke dans une base de données chronologique. Alertmanager est un outil de traitement des alertes, qui permet de dédoubler, de grouper et d’envoyer des alertes au destinataire approprié. Il peut gérer les alertes provenant d’applications clientes telles que Prometheus et prend en charge de nombreux destinataires, notamment la messagerie électronique, PagerDuty, OpsGenie et https. : //slack.com/ [Slack].

Grâce aux nombreux exportateurs Prometheus disponibles, vous pouvez configurer des alertes pour chaque élément de votre infrastructure, notamment web et https://prometheus.io/docs/. instrumenting / exporters / # bases de données [serveurs de bases de données], messaging systems ou https://prometheus.io/docs/instrumenting/exporters/#apis [Apis].

Blackbox Exporter analyse les points de terminaison via les protocoles HTTP, HTTPS, DNS, TCP ou ICMP, en renvoyant des métriques détaillées sur la demande, indiquant notamment si elle a abouti et combien de temps il a fallu pour la recevoir. une réponse.

Dans ce didacticiel, vous allez installer et configurer Alertmanager et Blackbox Exporter pour surveiller la réactivité d’un serveur Web Nginx. Vous configurerez ensuite Alertmanager pour vous avertir par e-mail et Slack si votre serveur ne répond pas.

Conditions préalables

Pour ce tutoriel, vous aurez besoin de:

Étape 1 - Création d’utilisateurs de service

Pour des raisons de sécurité, nous allons créer deux nouveaux comptes utilisateur, * blackbox_exporter * et * alertmanager *. Nous utiliserons ces comptes tout au long du didacticiel pour exécuter Blackbox Exporter et Alertmanager, ainsi que pour isoler la propriété des fichiers et répertoires principaux appropriés. Cela garantit que Blackbox Exporter et Alertmanager ne peuvent pas accéder aux données qu’ils ne possèdent pas et les modifier.

Créez ces utilisateurs avec la commande + useradd + en utilisant les indicateurs + - no-create-home + et + - shell / bin / false + pour que ces utilisateurs ne puissent pas se connecter au serveur:

sudo useradd --no-create-home --shell /bin/false blackbox_exporter
sudo useradd --no-create-home --shell /bin/false alertmanager

Avec les utilisateurs en place, téléchargeons et configurons Blackbox Exporter.

Étape 2 - Installation de Blackbox Exporter

Tout d’abord, téléchargez la dernière version stable de Blackbox Exporter dans votre répertoire personnel. Vous pouvez trouver les fichiers binaires les plus récents avec leurs sommes de contrôle sur la page de téléchargement Prometheus.

cd ~
curl -LO https://github.com/prometheus/blackbox_exporter/releases/download/v/blackbox_exporter-.linux-amd64.tar.gz

Avant de décompresser l’archive, vérifiez les sommes de contrôle du fichier à l’aide de la commande + sha256sum + suivante:

sha256sum blackbox_exporter-.linux-amd64.tar.gz

Comparez le résultat de cette commande avec la somme de contrôle de la page de téléchargement Prometheus pour vous assurer que votre fichier est à la fois authentique et non corrompu:

Output  blackbox_exporter-.linux-amd64.tar.gz

Si les sommes de contrôle ne correspondent pas, supprimez le fichier téléchargé et répétez les étapes précédentes pour télécharger à nouveau le fichier.

Lorsque vous êtes sûr que les sommes de contrôle correspondent, décompressez l’archive:

tar xvf blackbox_exporter-.linux-amd64.tar.gz

Cela crée un répertoire appelé + blackbox_exporter-.linux-amd64 +, contenant le fichier binaire + blackbox_exporter +, une licence et des exemples de fichiers.

Copiez le fichier binaire dans le répertoire + / usr / local / bin +.

sudo mv ./blackbox_exporter-.linux-amd64/blackbox_exporter /usr/local/bin

Définissez la propriété de l’utilisateur et du groupe sur le binaire sur l’utilisateur * blackbox_exporter *, afin que les utilisateurs non root ne puissent pas modifier ou remplacer le fichier:

sudo chown  /usr/local/bin/blackbox_exporter

Enfin, nous supprimerons l’archive et le répertoire décompressé, car ils ne sont plus nécessaires.

rm -rf ~/blackbox_exporter-.linux-amd64.tar.gz ~/blackbox_exporter-.linux-amd64

Ensuite, configurons Blackbox Exporter pour sonder les points de terminaison via le protocole HTTP, puis exécutez-le.

Étape 3 - Configuration et exécution de Blackbox Exporter

Créons un fichier de configuration définissant la manière dont Blackbox Exporter doit vérifier les points de terminaison. Nous allons également créer un fichier unité systemd afin de pouvoir gérer le service Blackbox à l’aide de + systemd +.

Nous spécifierons la liste des ordinateurs d’extrémité à analyser dans la configuration de Prometheus à l’étape suivante.

Tout d’abord, créez le répertoire pour la configuration de Blackbox Exporter. Selon les conventions Linux, les fichiers de configuration sont placés dans le répertoire + / etc +, nous allons donc utiliser ce répertoire pour contenir également le fichier de configuration de Blackbox Exporter:

sudo mkdir /etc/blackbox_exporter

Définissez ensuite la propriété de ce répertoire sur l’utilisateur * blackbox_exporter * créé à l’étape 1:

sudo chown  /etc/blackbox_exporter

Dans le répertoire nouvellement créé, créez le fichier + blackbox.yml + qui contiendra les paramètres de configuration de Blackbox Exporter:

sudo nano /etc/blackbox_exporter/blackbox.yml

Nous allons configurer Blackbox Exporter pour utiliser le prober + http + par défaut pour sonder les points de terminaison. Probers définissent comment Blackbox Exporter vérifie si un point de terminaison est en cours d’exécution. Le prober + http + vérifie les points de terminaison en envoyant une requête HTTP au point de terminaison et en testant son code de réponse. Vous pouvez sélectionner la méthode HTTP à utiliser pour l’analyse, ainsi que les codes d’état à accepter comme réponses réussies. Parmi les autres probers populaires, citons le prober + tcp + pour tester via le protocole TCP, le prober + icmp + pour détecter via le protocole ICMP et le prober + dns + pour la vérification des entrées DNS.

Pour ce tutoriel, nous utiliserons le prober + http + pour sonder le point de terminaison exécuté sur le port + 8080 + via la méthode HTTP + GET +. Par défaut, l’évaluateur suppose que les codes d’état valides de la plage + 2xx + sont valables. Il n’est donc pas nécessaire de fournir une liste des codes d’état valides.

Nous allons configurer un délai d’expiration de * 5 * secondes, ce qui signifie que Blackbox Exporter attendra la réponse pendant 5 secondes avant de signaler un échec. En fonction de votre type d’application, choisissez une valeur qui correspond à vos besoins.

Ajoutez la configuration suivante au fichier:

/etc/blackbox_exporter/blackbox.yml

modules:
 http_2xx:
   prober: http
   timeout:
   http:
     valid_status_codes: []
     method: GET

Pour plus d’informations sur les options de configuration, consultez la page https://github.com/prometheus/blackbox_exporter/blob/master/CONFIGURATION.md dans la documentation de Blackbox Exporter].

Enregistrez le fichier et quittez votre éditeur de texte.

Avant de créer le fichier de service, définissez la propriété de l’utilisateur et du groupe du fichier de configuration sur l’utilisateur * blackbox_exporter * créé à l’étape 1.

sudo chown  /etc/blackbox_exporter/blackbox.yml

Créez maintenant le fichier de service pour pouvoir gérer Blackbox Exporter à l’aide de + systemd +:

sudo nano /etc/systemd/system/blackbox_exporter.service

Ajoutez le contenu suivant au fichier:

/etc/systemd/system/blackbox_exporter.service

[Unit]
Description=Blackbox Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=blackbox_exporter
Group=blackbox_exporter
Type=simple
ExecStart=/usr/local/bin/blackbox_exporter --config.file /etc/blackbox_exporter/blackbox.yml

[Install]
WantedBy=multi-user.target

Ce fichier de service indique + systemd + pour exécuter Blackbox Exporter en tant qu’utilisateur * blackbox_exporter * avec le fichier de configuration situé sous + / etc / blackbox_exporter / blackbox.yml +. Les détails des fichiers de service + systemd + vont au-delà de la portée de ce tutoriel, mais si vous souhaitez en savoir plus, consultez la page https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and- unit-files # où-sommes-systemd-unit-files-found [Comprendre les unités Systemd et les fichiers d’unités].

Enregistrez le fichier et quittez votre éditeur de texte.

Enfin, rechargez + systemd + pour utiliser votre fichier de service nouvellement créé:

sudo systemctl daemon-reload

Maintenant démarrez Blackbox Exporter:

sudo systemctl start blackbox_exporter

Assurez-vous que le démarrage a réussi en vérifiant l’état du service:

sudo systemctl status blackbox_exporter

La sortie contient des informations sur le processus de Blackbox Exporter, notamment l’identifiant de processus principal (PID), l’utilisation de la mémoire, les journaux, etc.

Output● blackbox_exporter.service - Blackbox Exporter
  Loaded: loaded (/etc/systemd/system/blackbox_exporter.service; disabled; vendor preset: enabled)
  Active:  since Thu 2018-04-05 17:48:58 UTC; 5s ago
Main PID: 5869 (blackbox_export)
   Tasks: 4
  Memory: 968.0K
     CPU: 9ms
  CGroup: /system.slice/blackbox_exporter.service
          └─5869 /usr/local/bin/blackbox_exporter --config.file /etc/blackbox_exporter/blackbox.yml

Si l’état du service n’est pas «++», suivez les journaux à l’écran et retracez les étapes précédentes pour résoudre le problème avant de poursuivre le didacticiel.

Enfin, activez le service pour vous assurer que Blackbox Exporter démarrera au redémarrage du serveur:

sudo systemctl enable blackbox_exporter

Maintenant que Blackbox Exporter est entièrement configuré et en cours d’exécution, nous pouvons configurer Prometheus pour qu’il collecte des métriques sur les requêtes d’analyse de notre point de terminaison, afin de pouvoir créer des alertes en fonction de ces métriques et configurer des notifications pour les alertes à l’aide d’Alertmanager.

Étape 4 - Configuration de Prometheus pour supprimer l’exportateur Blackbox

Comme indiqué à l’étape 3, la liste des ordinateurs d’extrémité à analyser figure dans le fichier de configuration Prometheus, dans le cadre de la directive + cibles + de Blackbox Exporter. Au cours de cette étape, vous configurerez Prometheus afin qu’il utilise Blackbox Exporter pour récupérer le serveur Web Nginx fonctionnant sur le port + 8080 + que vous avez configuré dans les didacticiels préalables.

Ouvrez le fichier de configuration Prometheus dans votre éditeur:

sudo nano /etc/prometheus/prometheus.yml

À ce stade, il devrait ressembler à ceci:

/etc/prometheus/prometheus.yml

global:
 scrape_interval: 15s

scrape_configs:
 - job_name: 'prometheus'
   scrape_interval: 5s
   static_configs:
     - targets: ['localhost:9090']
 - job_name: 'node_exporter'
   scrape_interval: 5s
   static_configs:
     - targets: ['localhost:9100']

A la fin de la directive + scrape_configs +, ajoutez l’entrée suivante, qui indiquera à Prometheus de sonder le point de terminaison exécuté sur le port local + 8080 + à l’aide du module de Blackbox Exporter + http_2xx +, configuré à l’étape 3.

/etc/prometheus/prometheus.yml

...
 - job_name: 'blackbox'
   metrics_path: /probe
   params:
     module: [http_2xx]
   static_configs:
     - targets:
       - http://localhost:8080
   relabel_configs:
     - source_labels: [__address__]
       target_label: __param_target
     - source_labels: [__param_target]
       target_label: instance
     - target_label: __address__
       replacement: localhost:9115

Par défaut, Blackbox Exporter s’exécute sur le port + 9115 + avec les métriques disponibles sur le noeud final + / probe +.

La configuration + scrape_configs + pour Blackbox Exporter diffère de celle des autres exportateurs. La différence la plus notable est la directive + cibles +, qui répertorie les points d’extrémité interrogés au lieu de l’adresse de l’exportateur. L’adresse de l’exportateur est spécifiée à l’aide du jeu approprié d’étiquettes + adresse +.

Vous trouverez une explication détaillée des directives + relabel + dans la documentation Prometheus.

Votre fichier de configuration Prometheus ressemblera maintenant à ceci:

Fichier de configuration Prometheus - /etc/prometheus/prometheus.yml

global:
 scrape_interval: 15s

scrape_configs:
 - job_name: 'prometheus'
   scrape_interval: 5s
   static_configs:
     - targets: ['localhost:9090']
 - job_name: 'node_exporter'
   scrape_interval: 5s
   static_configs:
     - targets: ['localhost:9100']
 - job_name: 'blackbox'
   metrics_path: /probe
   params:
     module: [http_2xx]
   static_configs:
     - targets:
       - http://localhost:8080
   relabel_configs:
     - source_labels: [__address__]
       target_label: __param_target
     - source_labels: [__param_target]
       target_label: instance
     - target_label: __address__
       replacement: localhost:9115

Enregistrez le fichier et fermez votre éditeur de texte.

Redémarrez Prometheus pour que les modifications prennent effet:

sudo systemctl restart prometheus

Assurez-vous qu’il fonctionne comme prévu en vérifiant l’état du service Prometheus:

sudo systemctl status prometheus

Si l’état du service n’est pas «++», suivez les journaux à l’écran et retracez les étapes précédentes pour résoudre le problème avant de poursuivre le didacticiel.

À ce stade, vous avez configuré Prometheus pour extraire les métriques de Blackbox Exporter. Afin de recevoir des alertes d’Alertmanager, vous allez créer à l’étape suivante un ensemble approprié de règles d’alerte Prometheus.

Étape 5 - Création de règles d’alerte

Prometheus Alerting est séparé en deux parties. La première partie est gérée par le serveur Prometheus et comprend la génération d’alertes sur la base de règles d’alertes et leur envoi à l’adresse Alertmanager. La deuxième partie est effectuée par Alertmanager, qui gère les alertes reçues et les envoie aux destinataires appropriés, en fonction de la configuration.

Au cours de cette étape, vous apprendrez la syntaxe de base des règles d’alerte lors de la création d’une règle d’alerte pour vérifier si votre serveur est disponible.

Commencez par créer un fichier pour stocker vos alertes. Créez un fichier vide nommé + alert.rules.yml + dans le répertoire + / etc / prometheus +:

sudo touch /etc/prometheus/alert.rules.yml

Comme ce fichier fait partie de la configuration de Prometheus, assurez-vous que la propriété est définie sur l’utilisateur * prometheus * que vous avez créé dans le didacticiel préalable de Prometheus:

sudo chown  /etc/prometheus/alert.rules.yml

Une fois le fichier d’alertes en place, nous devons en informer Prometheus en ajoutant la directive appropriée au fichier de configuration.

Ouvrez le fichier de configuration Prometheus dans votre éditeur:

sudo nano /etc/prometheus/prometheus.yml

Ajoutez la directive + rule_files + après la directive + global + pour que Prometheus charge le fichier d’alertes que vous venez de créer au démarrage de Prometheus.

/etc/prometheus/prometheus.yml

global:
 scrape_interval: 15s




scrape_configs:
...

Enregistrez le fichier et quittez votre éditeur de texte.

Construisons maintenant une règle qui vérifie si le noeud final est en panne.

Pour créer la règle d’alerte, vous utiliserez la métrique + probe_success + de Blackbox Exporter qui renvoie * 1 * si le terminal est actif et * 0 * si ce n’est pas le cas.

La métrique + probe_success + contient deux libellés: le libellé + instance + avec l’adresse du noeud final et le libellé + job + avec le nom de l’exportateur qui a collecté la métrique.

Ouvrez le fichier de règles d’alerte dans votre éditeur:

sudo nano /etc/prometheus/alert.rules.yml

À l’instar du fichier de configuration Prometheus, le fichier de règles d’alertes utilise le format YAML, qui interdit formellement les onglets et nécessite deux espaces pour l’indentation. Prometheus ne pourra pas démarrer si le fichier n’est pas correctement formaté.

Tout d’abord, nous allons créer une règle d’alerte appelée + EndpointDown + pour vérifier si la métrique + probe_sucess + est égale à * 0 * avec une durée de * 10 * secondes. Cela garantit que Prometheus n’enverra aucune alerte si le système d’extrémité n’est pas disponible pendant moins de 10 secondes. Vous êtes libre de choisir la durée de votre choix en fonction de votre type d’application et de vos besoins.

En outre, nous attachons deux étiquettes indiquant la gravité critique et un résumé de l’alerte, afin que nous puissions facilement gérer et alertes de filtre.

Si vous souhaitez inclure plus de détails dans les libellés et les annotations de l’alerte, vous pouvez utiliser les libellés `+ {{$. }} + `syntaxe pour obtenir la valeur de l’étiquette. Nous allons l’utiliser pour inclure l’adresse du noeud final à partir du libellé `+ instance + 'de la métrique.

Ajoutez la règle suivante au fichier d’alertes:

/etc/prometheus/alert.rules.yml

groups:
- name: alert.rules
 rules:
 - alert: EndpointDown
   expr: probe_success == 0
   for: 10s
   labels:
     severity: "critical"
   annotations:
     summary: "Endpoint {{ $labels.instance }} down"

Enregistrez le fichier et quittez votre éditeur de texte.

Avant de redémarrer Prometheus, assurez-vous que votre fichier d’alertes est correct du point de vue de la syntaxe à l’aide de la commande + promtool + suivante:

sudo promtool check rules /etc/prometheus/alert.rules.yml

La sortie contient le nombre de règles trouvées dans le fichier, ainsi que des informations permettant de déterminer si les règles sont syntaxiquement correctes:

OutputChecking /etc/prometheus/alert.rules.yml
 SUCCESS: 1 rules found

Enfin, redémarrez Prometheus pour appliquer les modifications:

sudo systemctl restart prometheus

Vérifiez que le service est en cours d’exécution avec la commande + status +:

sudo systemctl status prometheus

Si l’état du service n’est pas + active +, suivez les journaux à l’écran et retracez les étapes précédentes pour résoudre le problème avant de poursuivre le didacticiel.

Avec les règles d’alerte en place, nous pouvons télécharger et installer Alertmanager.

Étape 6 - Télécharger Alertmanager

Blackbox Exporter est configuré et nos règles d’alerte sont en place. Téléchargeons et installons Alertmanager pour traiter les alertes reçues par Prometheus.

Vous pouvez trouver les derniers fichiers binaires avec leurs sommes de contrôle sur la page de téléchargement Prometheus. Téléchargez et décompressez la version stable actuelle d’Alertmanager dans votre répertoire personnel:

cd ~
curl -LO https://github.com/prometheus/alertmanager/releases/download/v/alertmanager-.linux-amd64.tar.gz

Avant de décompresser l’archive, vérifiez les sommes de contrôle du fichier à l’aide de la commande + sha256sum + suivante:

sha256sum alertmanager-.linux-amd64.tar.gz

Comparez le résultat de cette commande avec la somme de contrôle de la page de téléchargement de Prometheus pour vous assurer que votre fichier est à la fois authentique et non corrompu.

Output  alertmanager-.linux-amd64.tar.gz

Si les sommes de contrôle ne correspondent pas, supprimez le fichier téléchargé et répétez les étapes précédentes pour télécharger à nouveau le fichier.

Une fois le téléchargement vérifié, décompressez l’archive:

tar xvf alertmanager-.linux-amd64.tar.gz

Cela crée un répertoire appelé + alertmanager-.linux-amd64 + contenant deux fichiers binaires (+ alertmanager + et + amtool +), une licence et un exemple de fichier de configuration.

Déplacez les deux fichiers binaires dans le répertoire + / usr / local / bin +:

sudo mv alertmanager-.linux-amd64/alertmanager /usr/local/bin
sudo mv alertmanager-.linux-amd64/amtool /usr/local/bin

Définissez la propriété des utilisateurs et des groupes sur les fichiers binaires sur l’utilisateur * alertmanager * que vous avez créé à l’étape 1:

sudo chown  /usr/local/bin/alertmanager
sudo chown  /usr/local/bin/amtool

Supprimez les fichiers restants de votre répertoire personnel car ils ne sont plus nécessaires:

rm -rf alertmanager-.linux-amd64 alertmanager-.linux-amd64.tar.gz

Maintenant que les fichiers requis se trouvent à l’emplacement approprié, nous pouvons configurer Alertmanager pour envoyer des notifications d’alertes par courrier électronique.

Étape 7 - Configuration d’Alertmanager pour l’envoi d’alertes par courrier électronique

Au cours de cette étape, vous allez créer le répertoire et les fichiers dans lesquels stocker les données et les paramètres de configuration d’Alertmanager, puis configurer Alertmanager pour qu’il envoie des alertes par courrier électronique.

Conformément aux conventions standard de Linux, nous allons créer un répertoire dans + / etc + pour stocker le fichier de configuration d’Alertmanager.

sudo mkdir /etc/alertmanager

Définissez la propriété des utilisateurs et des groupes pour le répertoire nouvellement créé sur l’utilisateur * alertmanager *:

sudo chown  /etc/alertmanager

Nous allons stocker le fichier de configuration dans le fichier + alertmanager.yml +, alors créez ce fichier et ouvrez-le dans votre éditeur:

sudo nano /etc/alertmanager/alertmanager.yml

Comme d’autres fichiers liés à Prometheus, celui-ci utilise également le format YAML. Assurez-vous donc d’utiliser deux espaces au lieu de tabulations pour l’indentation.

Nous allons configurer Alertmanager pour envoyer des courriers électroniques à l’aide de Postfix, que vous avez installé en suivant le didacticiel requis. Nous devons fournir l’adresse du serveur SMTP, en utilisant la directive + smtp_smarthost +, ainsi que l’adresse à partir de laquelle nous voulons envoyer des courriels, en utilisant la directive + smtp_from +. Comme Postfix est exécuté sur le même serveur qu’Alertmanager, l’adresse du serveur est + localhost: 25 +. Nous allons utiliser l’utilisateur * alertmanager * pour l’envoi de courriels.

Par défaut, TLS n’a pas été configuré pour Postfix. Nous devons donc demander à Alertmanager d’autoriser les serveurs SMTP non TLS à utiliser la directive + smtp_require_tls +.

Placez la configuration SMTP sous la directive + global +, car elle permet de spécifier des paramètres valables dans tous les autres contextes de configuration. Cela inclut la configuration SMTP dans notre cas et peut également inclure des jetons API pour diverses intégrations:

Partie de fichier de configuration Alertmanager 1 - /etc/alertmanager/alertmanager.yml

global:
 smtp_smarthost: 'localhost:25'
 smtp_from: 'alertmanager@'
 smtp_require_tls: false

À ce stade, Alertmanager sait comment envoyer des courriers électroniques, mais nous devons définir comment il gérera les alertes entrantes à l’aide de la directive + route +. La directive + route + est appliquée à chaque alerte entrante et définit des propriétés telles que le mode de regroupement des alertes par Alertmanager, le destinataire par défaut ou le délai d’attente avant l’envoi d’une alerte par Alertmanager.

Pour grouper les alertes, utilisez la sous-directive + group_by +, qui prend un tableau en ligne d’étiquettes (comme + ['', ''] +). Le regroupement garantit que les alertes contenant les mêmes étiquettes seront regroupées et envoyées dans le même lot.

Chaque directive + route + a un seul récepteur défini à l’aide de la sous-directive + receiver +. Si vous souhaitez ajouter plusieurs destinataires, vous devez définir plusieurs destinataires sous la même directive ou imbriquer plusieurs directives + route + à l’aide de la sous-directive + routes +. Dans ce tutoriel, nous aborderons la première approche pour configurer les alertes Slack.

Dans ce cas, nous ne grouperons que par les étiquettes "+ instance " de Blackbox et les étiquettes " severity +" que nous avons jointes à l’alerte à l’étape 6, afin de nous assurer que nous aurons plusieurs alertes pour notre point de terminaison avec une gravité critique dans un courrier.

Ajoutez la directive + group_by + suivante:

Partie de fichier de configuration Alertmanager 2 - /etc/alertmanager/alertmanager.yml

...
route:
 group_by: ['instance', 'alert']

Nous définirons ensuite des intervalles, tels que le délai d’attente d’Alertmanager avant l’envoi des alertes initiales et nouvelles.

À l’aide de la sous-directive + group_wait +, nous définirons le délai d’attente d’Alertmanager avant l’envoi de l’alerte initiale. Pendant cette période, Alertmanager attendra que Prométhée envoie d’autres alertes, le cas échéant, pour pouvoir les envoyer dans le même lot. Comme nous n’avons qu’une alerte, nous choisirons une valeur arbitraire de 30 secondes.

Ensuite, en utilisant l’intervalle + groupe_intervalle +, nous définirons la durée d’attente d’Alertmanager avant l’envoi du prochain lot d’alertes s’il y a de nouvelles alertes dans le même groupe. Vous êtes libre de choisir n’importe quelle valeur en fonction de vos besoins, mais nous le définirons toutes les 5 minutes.

Le dernier intervalle que nous configurerons est le + repeat_interval +, qui définit la durée d’attente d’Alertmanager avant l’envoi d’une notification si les alertes ne sont pas encore résolues. Vous pouvez choisir la valeur qui vous convient, mais nous utiliserons la valeur arbitraire de 3 heures.

Enfin, à l’aide de la sous-directive + receiver +, définissez qui recevra les notifications pour les alertes. Nous allons utiliser un récepteur appelé + team-1 +, que nous définirons plus tard.

Modifiez la directive route pour qu’elle ressemble à ceci:

Partie de fichier de configuration Alertmanager 2 - /etc/alertmanager/alertmanager.yml

route:
 group_by: ['instance', 'severity']
 group_wait: 30s
 group_interval: 5m
 repeat_interval: 3h
 receiver:

Si vous souhaitez faire correspondre et envoyer des notifications uniquement concernant des alertes spécifiques, vous pouvez utiliser les sous-directives + match + et + match_re + pour filtrer les alertes en fonction de la valeur de leur libellé. La sous-directive + match + représente la correspondance d’égalité, la sous-directive + match_re + représentant la correspondance via des expressions régulières.

Nous allons maintenant configurer le récepteur + team-1 + afin que vous puissiez recevoir des notifications d’alertes. Sous la directive + receivers + vous pouvez définir des destinataires contenant le nom et la sous-directive de configuration appropriée. La liste des destinataires disponibles et les instructions pour les configurer est disponible dans la section Alertmanager].

Afin de configurer le récepteur de messagerie + team-1 +, nous allons utiliser la sous-directive + email_configs + sous la directive + receivers +:

Partie de fichier de configuration Alertmanager 3 - /etc/alertmanager/alertmanager.yml

receivers:
 - name: ''
   email_configs:
     - to: ''

À ce stade, vous avez configuré Alertmanager pour envoyer des notifications d’alertes à votre adresse de messagerie. Votre fichier de configuration devrait ressembler à:

Fichier de configuration Alertmanager - /etc/alertmanager/alertmanager.yml

global:
 smtp_smarthost: 'localhost:25'
 smtp_from: 'alertmanager@'
 smtp_require_tls: false

route:
 group_by: ['instance', 'severity']
 group_wait: 30s
 group_interval: 5m
 repeat_interval: 3h
 receiver:

receivers:
 - name: ''
   email_configs:
     - to: ''

Dans la prochaine étape, nous configurerons Alertmanager pour qu’il envoie des alertes à votre canal Slack. Si vous ne souhaitez pas configurer Slack, vous pouvez passer directement à l’étape 10 où nous allons créer le fichier de service et configurer Prometheus pour qu’il fonctionne avec Alertmanager.

Étape 8 - Configuration d’Alertmanager pour l’envoi d’alertes sur du temps mort

Avant de poursuivre, assurez-vous d’avoir créé un compte Slack et de disposer d’un espace de travail Slack.

Pour envoyer des alertes à Slack, créez d’abord un Incoming Webhook.

Pointez votre navigateur sur la page de création Webhook entrant disponible à l’adresse + https: //. Slack.com / services / new / incoming-webhook / +. Vous obtiendrez la page contenant des détails sur les Webhooks entrants, ainsi qu’un menu déroulant à partir duquel vous devez choisir le canal sur lequel vous souhaitez envoyer des alertes.

image: https: //assets.digitalocean.com/articles/prometheus_blackbox_alertmanager_1604/uBKKA4O.png [Retrait de la page Web entrante]

Une fois que vous avez choisi le canal, cliquez sur le bouton * Ajouter une intégration WebHooks entrante *.

Vous verrez une nouvelle page confirmant que le Webhook a été créé avec succès. Copiez l’URL * Webhook * affichée sur cette page, car vous l’utiliserez pour configurer les notifications Slack d’Alertmanager.

Ouvrez le fichier de configuration Alertmanager dans votre éditeur pour configurer les notifications Slack:

sudo nano /etc/alertmanager/alertmanager.yml

Premièrement, ajoutez la sous-directive + slack_api_url + à la partie + global + de votre configuration, en utilisant l’URL que vous avez obtenue lors de la création de Slack Incoming Webhook.

Partie de fichier de configuration Alertmanager 1 - /etc/alertmanager/alertmanager.yml

global:
 smtp_smarthost: 'localhost:25'
 smtp_from: 'alertmanager@'
 smtp_require_tls: false

 slack_api_url: ''

Il existe deux manières d’envoyer des alertes à plusieurs destinataires:

  1. Incluez plusieurs configurations de récepteur sous la même entrée. C’est la solution la moins sujette aux erreurs et la méthode la plus simple.

  2. Créez plusieurs entrées de récepteur et imbriquez plusieurs directives + route +.

Nous ne couvrirons pas la deuxième approche de ce didacticiel, mais si cela vous intéresse, jetez un œil à la partie Route Configuration de la documentation d’Alertmanager.

Dans le récepteur + team-1 +, ajoutez une nouvelle sous-directive appelée https://prometheus.io/docs/alerting/configuration/#slack_config [+ slack_configs +] et indiquez le nom du canal à recevoir. alertes. Dans ce cas, nous utiliserons le canal + general:

Partie de fichier de configuration Alertmanager 2 - /etc/alertmanager/alertmanager.yml

receivers:
 - name: ''
   email_configs:
     - to: ''

     general<^>'

Votre fichier de configuration terminé ressemblera à ceci:

Fichier de configuration Alertmanager - /etc/alertmanager/alertmanager.yml

global:
 smtp_smarthost: 'localhost:25'
 smtp_from: 'alertmanager@'
 smtp_require_tls: false

 slack_api_url: ''

route:
 group_by: ['instance', 'severity']
 group_wait: 30s
 group_interval: 5m
 repeat_interval: 3h
 receiver:

receivers:
 - name: ''
   email_configs:
     - to: ''
   slack_configs:
     - channel: ''

Enregistrez le fichier et quittez votre éditeur.

Nous sommes maintenant prêts à exécuter Alertmanager pour la première fois.

Étape 9 - Exécution d’Alertmanager

Lançons Alertmanager. Nous allons d’abord créer un fichier unité systemd pour permettre à Alertmanager de gérer son service à l’aide de + systemd +. Ensuite, nous mettrons à jour Prometheus pour qu’il utilise Alertmanager.

Créez un nouveau fichier unité + systemd + et ouvrez-le dans votre éditeur de texte:

sudo nano /etc/systemd/system/alertmanager.service

Ajoutez ce qui suit au fichier pour configurer systemd afin qu’il exécute Alertmanager en tant qu’utilisateur * alertmanager *, à l’aide du fichier de configuration situé sous + / etc / alertmanager / alertmanager.yml + et de l’adresse Alertmanager configurée pour utiliser l’adresse IP de votre serveur:

/etc/systemd/system/alertmanager.service

[Unit]
Description=Alertmanager
Wants=network-online.target
After=network-online.target

[Service]
User=alertmanager
Group=alertmanager
Type=simple
WorkingDirectory=/etc/alertmanager/
ExecStart=/usr/local/bin/alertmanager --config.file=/etc/alertmanager/alertmanager.yml --web.external-url http://:9093

[Install]
WantedBy=multi-user.target

Ceci lancera Alertmanager en tant qu’utilisateur * alertmanager *. Il demande également à Alertmanager d’utiliser l’URL + http: //: 9093 + pour son interface Web, où + 9093 + est le port par défaut d’Alertmanager. Assurez-vous d’inclure le protocole (+ http: // +), sinon les choses ne fonctionneront pas.

Enregistrez le fichier et fermez votre éditeur de texte.

Ensuite, nous devons informer Prometheus d’Alertmanager en ajoutant le répertoire de découverte du service Alertmanager approprié au fichier de configuration Prometheus. Par défaut, Alertmanager fonctionne sur le port + 9093 + et, comme il se trouve sur le même serveur que Prometheus, nous utiliserons l’adresse + localhost: 9093 +.

Ouvrez le fichier de configuration Prometheus:

sudo nano /etc/prometheus/prometheus.yml

Après la directive + rule_files +, ajoutez la directive + alerting + suivante:

Fichier de configuration Prometheus - /etc/prometheus/prometheus.yml

...
rule_files:
 - alert.rules.yml






...

Une fois que vous avez terminé, enregistrez le fichier et fermez votre éditeur de texte.

Pour pouvoir suivre les URL des alertes que vous recevez, vous devez indiquer à Prometheus l’adresse IP ou le nom de domaine de votre serveur à l’aide de l’indicateur + -web.external-url + lorsque vous démarrez Prometheus.

Ouvrez le fichier unité + systemd + pour Prometheus:

sudo nano /etc/systemd/system/prometheus.service

Remplacez la ligne + ExecStart + existante par la suivante:

ExecStart=/usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml \
   --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles \
   --web.console.libraries=/etc/prometheus/console_libraries \
   --web.external-url http://

Votre nouveau fichier d’unité Prometheus ressemblera à ceci:

Fichier de service Prometheus - /etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml \
   --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles \
   --web.console.libraries=/etc/prometheus/console_libraries \
   --web.external-url http://

[Install]
WantedBy=multi-user.target

Enregistrez le fichier et fermez votre éditeur de texte.

Rechargez + systemd + et redémarrez Prometheus pour appliquer les modifications:

sudo systemctl daemon-reload
sudo systemctl restart prometheus

Assurez-vous que Prometheus fonctionne comme prévu en vérifiant le statut du service:

sudo systemctl status prometheus

Si l’état du service n’est pas «++», suivez les journaux à l’écran et retracez les étapes précédentes pour résoudre le problème avant de poursuivre le didacticiel.

Enfin, démarrez Alertmanager pour la première fois:

sudo systemctl start alertmanager

Vérifiez le statut du service pour vous assurer que Alertmanager fonctionne comme prévu:

sudo systemctl status alertmanager

Si l’état du service n’est pas «++», suivez les messages à l’écran et suivez les étapes précédentes pour résoudre le problème avant de poursuivre le didacticiel.

Enfin, activez le service pour vous assurer que Alertmanager démarrera au démarrage du système:

sudo systemctl enable alertmanager

Pour accéder à l’UI Web d’Alertmanager, autorisez le trafic sur le port + 9093 + via votre pare-feu:

sudo ufw allow 9093/tcp

Alertmanager est maintenant configuré pour envoyer des notifications d’alertes par courrier électronique et par Slack. Veillons à ce que cela fonctionne.

Étape 10 - Tester Alertmanager

Assurez-vous qu’Alertmanger fonctionne correctement et envoie des courriels et des notifications Slack. Nous allons désactiver le point de terminaison en supprimant le bloc de serveur Nginx que vous avez créé dans les tutoriels préalables:

sudo rm /etc/nginx/sites-enabled/

Rechargez Nginx pour appliquer les modifications:

sudo systemctl reload nginx

Si vous souhaitez confirmer sa désactivation, vous pouvez indiquer à votre navigateur Web l’adresse de votre serveur. Vous devriez voir un message indiquant que le site n’est plus accessible. Si vous ne le faites pas, revenez sur les étapes précédentes et assurez-vous d’avoir supprimé le bloc de serveur correct et rechargé Nginx.

En fonction de l’intervalle + group_wait +, qui est * 30 secondes * dans notre cas, vous devriez recevoir un courrier électronique et des notifications Slack après 30 secondes.

Si ce n’est pas le cas, vérifiez l’état du service à l’aide des commandes + status + suivantes et suivez les journaux à l’écran pour trouver la cause du problème:

sudo systemctl status alertmanager
sudo systemctl status prometheus

Vous pouvez également vérifier l’état de l’alerte à partir de l’interface utilisateur Web de Prometheus en faisant pointer votre navigateur Web sur le signe + http: /// alerts +. Il vous sera demandé de saisir le nom d’utilisateur et le mot de passe choisis en suivant le didacticiel Prometheus. En cliquant sur le nom de l’alerte, vous verrez l’état, la règle d’alerte et les étiquettes associées:

image: https: //assets.digitalocean.com/articles/prometheus_blackbox_alertmanager_1604/ikIPV9Q.png [Interface utilisateur Prometheus - alertes]

Une fois que vous avez vérifié qu’Alertmanager fonctionne, activez le noeud final en recréant le lien symbolique depuis le répertoire + sites-available + dans le répertoire + sites-enabled +:

sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled

Rechargez à nouveau Nginx pour appliquer les modifications:

sudo systemctl reload nginx

Dans la prochaine étape, nous verrons comment utiliser l’interface de ligne de commande d’Alertmanager.

Étape 11 - Gestion des alertes à l’aide de la CLI

Alertmanager est fourni avec l’outil de ligne de commande + amtool +, qui vous permet de surveiller, de gérer et de désactiver les alertes.

L’outil + amtool + nécessite que vous fournissiez l’URL d’Alertmanager à l’aide de l’indicateur + - alertmanager.url + chaque fois que vous exécutez une commande. Pour utiliser + amtool + sans fournir l’URL, nous allons commencer par créer un fichier de configuration.

Les emplacements par défaut du fichier de configuration sont + $ HOME / .config / amtool / config.yml +, ce qui rend la configuration disponible uniquement pour votre utilisateur actuel, et + / etc / amtool / config.yml +, ce qui rend la configuration disponible pour tous les utilisateurs du serveur.

Vous êtes libre de choisir ce qui vous convient, mais pour ce tutoriel, nous utiliserons le fichier + $ HOME / .config / amtool / config.yml +.

Tout d’abord, créez le répertoire. L’indicateur + -p + indique à + mkdir + `de créer les répertoires parents nécessaires en chemin:

mkdir -p $HOME/.config/amtool

Créez le fichier + config.yml + et ouvrez-le dans votre éditeur de texte:

nano $HOME/.config/amtool/config.yml

Ajoutez la ligne suivante pour indiquer à + ​​amtool + d’utiliser Alertmanager avec l’URL + http: // localhost: 9093 +:

~ / .config / amtool / config.yml

alertmanager.url: http://localhost:9093

Enregistrez le fichier et quittez votre éditeur de texte.

Nous allons maintenant examiner ce que nous pouvons faire avec l’outil en ligne de commande + amtool +.

À l’aide de la commande + amtool alert query, vous pouvez répertorier toutes les alertes envoyées à Alertmanager:

amtool alert query

La sortie affiche le nom de l’alerte, l’heure de sa première apparition et le récapitulatif de l’alerte que vous avez fourni lors de la configuration:

OutputAlertname     Starts At                Summary
EndpointDown  2018-04-03 08:48:47 UTC  Endpoint http://localhost:8080 down

Vous pouvez également filtrer les alertes en fonction de leurs étiquettes à l’aide du matcher approprié. Un matcher contient le nom de l’étiquette, l’opération appropriée, qui peut être + = + pour une correspondance complète et + = ~ + pour une correspondance partielle, ainsi que la valeur de l’étiquette.

Si vous souhaitez répertorier toutes les alertes auxquelles une étiquette de gravité critique est attachée, utilisez le matcher + severity = critical + dans la commande + alert query +:

amtool alert query

Comme auparavant, la sortie contient le nom de l’alerte, l’heure de la première apparition de l’alerte et son résumé.

OutputAlertname     Starts At                Summary
EndpointDown  2018-04-03 08:48:47 UTC  Endpoint http://localhost:8080 down

Vous pouvez utiliser des expressions régulières pour faire correspondre les étiquettes à l’opérateur + = ~ +. Par exemple, pour répertorier toutes les alertes relatives aux points de terminaison + http: // localhost + ne dépendant pas du port, vous pouvez utiliser l’outil de correspondance + instance = ~ http: // localhost. * +:

amtool alert query

Comme vous n’avez qu’une alerte et un noeud final, le résultat sera le même que dans l’exemple précédent.

Pour examiner la configuration d’Alertmanager, utilisez la commande + amtool config +:

amtool config

La sortie contiendra le contenu du fichier + / etc / alertmanager / alertmanager.yml +.

Voyons maintenant comment désactiver les alertes avec + amtool +.

La désactivation des alertes vous permet de désactiver les alertes sur la base de l’outil de correction pour une période donnée. Pendant cette période, vous ne recevrez aucun courrier électronique ni aucune notification Slack pour l’alerte silencieuse.

La commande + amtool silence add + prend le matcher en tant qu’argument et crée une nouvelle silence_ en fonction du matcher.

Pour définir l’expiration d’une alerte, utilisez l’indicateur + - expires + avec la durée souhaitée du silence, tel que + 1h + ou l’indicateur + - expire-on + avec le délai d’expiration défini dans le champ https. : //www.ietf.org/rfc/rfc3339.txt [format RFC3339]. Par exemple, le format + 2018-10-04T07: 50: 00 + 00: 00 + représente 07h50 le 4 octobre 2018.

Si le signe + - expires + ou si le drapeau `+ - expires-on + 'n’est pas fourni, les alertes seront désactivées pendant * 1 heure *.

Pour désactiver toutes les alertes pour l’instance + http: // localhost: 8080 + pendant * 3 heures *, vous devez utiliser la commande suivante:

amtool silence add instance= --expires

La sortie contient un numéro d’identification pour le silence, assurez-vous donc de le noter car vous en aurez besoin au cas où vous souhaiteriez supprimer le silence:

Output

Si vous souhaitez fournir des informations supplémentaires lors de la création du silence, telles que l’auteur et les commentaires, utilisez les indicateurs + - author + et + - comment +:

amtool silence add severity=critical --expires 3h

Comme auparavant, la sortie contient l’ID du silence:

Output

La commande + amtool silence query affichera la liste de tous les silences non expirés:

amtool silence query

La sortie contient l’ID du silence, la liste des correspondants, l’horodatage d’expiration, l’auteur et un commentaire:

OutputID                                    Matchers                        Ends At                  Created By       Comment
12b7b9e1-f48a-4ceb-bd85-65ac882ceed1  severity=critical               2018-04-04 08:02:58 UTC  Sammy The Shark  Investigating in the progress
4e89b15b-0814-41d3-8b74-16c513611732  instance=http://localhost:8080  2018-04-04 08:14:21 UTC  sammy

Semblable à la commande + alert query +, vous pouvez utiliser des identificateurs d’étiquettes pour filtrer la sortie en fonction des étiquettes attachées à la création:

amtool silence query instance=http://localhost:8080

Comme auparavant, le résultat comprendra le numéro d’identification et les détails de l’alerte:

OutputID                                    Matchers                        Ends At                  Created By  Comment
4e89b15b-0814-41d3-8b74-16c513611732  instance=http://localhost:8080  2018-04-04 08:14:21 UTC  sammy

Enfin, pour expirer un silence, utilisez le amtool silence expire + avec l’ID du silence que vous voulez expirer:

amtool silence expire
amtool silence expire

Aucune sortie ne représente une exécution réussie de la commande. Si vous voyez une erreur, assurez-vous d’avoir fourni le bon identifiant du silence.

Conclusion

Dans ce didacticiel, vous avez configuré Blackbox Exporter et Alertmanager pour qu’ils fonctionnent avec Prometheus afin que vous puissiez recevoir des alertes par courrier électronique et Slack. Vous avez également utilisé l’interface de ligne de commande d’Alertmanager, + amtool +, pour gérer et faire taire les alertes.

Si vous souhaitez en savoir plus sur les autres intégrations d’Alertmanager, consultez la partie [Configuration] https://prometheus.io/docs/alerting/configuration/ de la documentation d’Alertmanager.

Vous pouvez également voir comment intégrer les alertes Prometheus à d’autres services tels que Grafana.