blog.bressure.net

Remplacer munin par Prometheus se serait complet sans la partie envoi des alertes. Dans mon cas un simple mail suffira.

Alertmanager

Comme tout est dockerisé chez moi, je vais donc ajouter dans mon application de monitoring le service alertmanager. Le rôle de l’alertmanager est de recevoir les demandes de notification quand une métrique a une valeur donnée. Les fonctions de l’alertmanager sont entre autres de temporiser, relayer ou inhiber les notifications.

Grafana peut également envoyer des notifications mais comme je l’ai déjà mentionné, je ne vais l’utiliser que pour sa fonction de tableau de bord. Par ailleurs Grafana peut envoyer des alertes vers l’alertmanager donc ce dernier jouera parfaitement son rôle en recevant les demandes de notification de la part de Promethéus ou Grafana.

Alertes

Créer des alerte est relativement simple. Si munin est fournit avec beaucoup de plugin déjà éprouvés, il va falloir ajouter les alertes de bases comme: la saturation cpu, mémoire ou disque.

Paramétrage d’une destination mail dans l’alertmanager

Comme je définis un volume pour le conteneur alertmanager via mon fichier docker-compose.yml de l’appication de monitoring

   alertmanager:
      image: 'prom/alertmanager'
      restart: always 
      volumes:
        - alertmanager_conf:/etc/alertmanager

Il suffit depuis l’hôte docker de modifier le fichier /var/lib/docker/volumes/monitoring_alertmanager_conf/_data/alertmanager.yml

Voici le contenu qui permet de configurer l’envoi de mail, à modifier pour adapter à votre configuration de mail !

global:
  resolve_timeout: 5m
  smtp_smarthost: 'mon.serveur.smtp.com:587'
  smtp_from: 'monadresse@mail.com'
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'mail_to_admin'
receivers:
- name: 'web.hook'
  webhook_configs:
  - url: 'http://127.0.0.1:5001/'
- name: 'mail_to_admin'
  email_configs:
  - to: destinataire@mail.com
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

Configuration de prometheus pour utiliser l’alertmanager

L’application de monitoring utilise une image personnalisée de prométheus dont le seul but est de fournir une configuration de base visible dans le fichier prometheus.yml.

La partie importante est celle-ci:

rule_files:
  - '/etc/prometheus/rules/*'
alerting:
  alertmanagers:
  - static_configs:
    - targets: ['alertmanager:9093']
    scheme: http
    timeout: 10s
    api_version: v1

Ajout d’un alerte d’occupation disque

Dans le fichier de configuration prometheus.yml on a indiqué de prendre tous les fichiers du répertoire /etc/prometheus comme règles. Il suffit alors d’ajouter dans ce répertoire les fichiers de règles des alertes. Comme prométheus est dans un conteneur, il faudra aller sur machine hôte dans le répertoire /var/lib/docker/volumes/monitoring_prometheus_conf/_data/rules/

Voici par exemple le contenu d’un fichier qui donne l’alerte quand l’occupation disque dépasse 80%

groups:
- name: disk
  rules:
  - alert: diskUsage
    expr: 1 - node_filesystem_free_bytes / node_filesystem_size_bytes > 0.8
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: consommation disque eleve

Règles enregistrées

On pourra factoriser les calculs de métriques qui peuvent être coûteux et partager le résultat dans des définitions d’alerte. Ainsi dans l’exemple suivant on calcul un seul fois l’occupation d’overcommit et 2 alertes réutilisent le résultat:

groups:
- name: memoire
  rules:
  - record: memoire:overcommit
    expr: node_memory_Committed_AS_bytes / (node_memory_MemTotal_bytes + node_memory_SwapTotal_bytes) 
  - alert: overcommit
    expr: memoire:overcommit > 0.9
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: surconsommation memoire
  - alert: overcommit
    expr: memoire:overcommit > 0.8 and memoire:overcommit <= 0.9
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: surconsommation memoire

L’étape suivante sera la surveillance de l’espace disque occupé par docker. Il peut être intéressant de suivre l’évolution de cette métrique et se sera l’occasion d’apprendre à étendre le node-exporter de prométheus. La suite au prochain billet…