Un monitoring complet en quelques minutes avec Prometheus ?

Écrit par Franck

En quelques commandes il vous est possible d’avoir une vision assez complète de votre infrastructure. Ici je vais vous montrer un petit projet bootstrap qui utilise Prometheus, Grafana, Alertmanager, Blackbox et Slack. Toute une stack de monitoring et d’alerting en quelques secondes 🙂

Dans cet article, je vais vous donner un projet bootstrap pour lancer un monitoring rapidement sur votre infrastructure. Le but est de montrer comment mettre en place un monitoring complet sur votre infrastructure en quelques secondes avec des projets opensource dans l’air du temps.

Je pars du principe que vous connaissez un peu ces technologies ou que vous en avez entendu parlé et que vous souhaitez commencer à jouer avec. Petit récapitulatif de ce que nous allons utiliser ici (liens github) :

• Prometheus
• Grafana
• Alertmanager
• Blackbox
• Node exporter

Allons droit au but, étant donné que c’est un POC, j’utilise docker-compose pour lancer tous les services sur la même machine. Passons directement à la configuration des outils.

Pour les plus pressés vous retrouverez le repo dans la conclusion de l’article.

Voici l’architecture de mon dossier :

├── alertmanager
│ ├── alertmanager.yml
│ ├── alert.rules
│ │ └── alerts.rules.yml
│ └── templates
│ └── default.tmpl
├── blackbox
│ └── blackbox.yml
├── docker-compose.yml
├── grafana
│ ├── dashboards
│ │ └── monitoring-machine.json
│ ├── dashboards.yml
│ ├── datasource.yml
│ └── grafana.ini
├── prometheus
│ └── prometheus.yml
└── readme.md

Docker compose

Tous les services énoncés ci-dessus vont être installés et lancés sur la même machine avec des configurations spécifiques afin que tout fonctionne au démarrage. J’ai mis deux volumes sur le grafana et sur le prometheus afin de pouvoir conserver les configurations ainsi que les métriques sur une durée (par défaut pour prometheus c’est 15 jours, ici j’ai mis 1 an).

Voici le docker compose que j’ai créé pour le projet :

version: '3'

services:

  prometheus:
    image: prom/prometheus:v2.11.1
    container_name: prometheus
    deploy:
      replicas: 1
    volumes:
      - prometheus-data:/prometheus
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./alertmanager/alert.rules/alerts.rules.yml:/alertmanager/alert.rules/alerts.rules.yml
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=365d'
    network_mode: "host"

  alertmanager:
    image: prom/alertmanager:v0.18.0
    container_name: alertmanager
    deploy:
      replicas: 1
    volumes:
      - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml
      - ./alertmanager/templates/default.tmpl:/etc/alertmanager/templates/default.tmpl
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
    network_mode: "host"

  grafana:
    image: grafana/grafana:6.2.5
    container_name: grafana
    environment:
      - GF_PATHS_CONFIG=/etc/grafana/grafana.ini
    deploy:
      replicas: 1
    depends_on:
      - prometheus
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana/datasource.yml:/etc/grafana/provisioning/datasources/datasource.yml
      - ./grafana/dashboards.yml:/etc/grafana/provisioning/dashboards/dashboards.yml
      - ./grafana/grafana.ini:/etc/grafana/grafana.ini
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    network_mode: "host"

  blackbox:
    image: prom/blackbox-exporter:v0.14.0
    container_name: blackbox_exporter
    deploy:
      replicas: 1
    volumes:
    - ./blackbox:/config
    network_mode: "host"

  node_exporter:
    image: prom/node-exporter:v0.18.1
    container_name: node_exporter
    deploy:
      replicas: 1
    network_mode: "host"

volumes:
  prometheus-data:
  grafana-data:

Pour lancer la stack de monitoring il suffit de se mettre à la racine du repo et de lancer la commande : docker-compose up -d on utilise le -d pour être en mode dettached, si vos containers sont actifs il suffit de lancer la commande : docker ps

Node exporter

Avant toute chose il faut des choses à monitorer. L’exporter le plus populaire va être le node exporter. C’est un exporter prometheus développé en Go qui va exporter sur un endpoint http un panel de métriques applicatives.

Pour déployer cet exporter vous pouvez le faire manuellement avec le readme du projet github mais je vous conseille de le faire via ansible avec le rôle de cloudalchemy que vous retrouverez ici.

Il vous suffira de faire remplir votre fichier d’host avec les machines que vous souhaitez monitorer et de lancer le rôle sur vos machines. Celui-ci va déployer le binaire sur les machines et créer un service node exporter pour que l’exporter démarre automatiquement sur les machines.

Une fois cet exporter installé il faudra remplir les IPs à scrapper dans le fichier de configuration de prometheus pour qu’il stocke les métriques qu’il va scrapper.

Dans cet exemple j’en ai mis un dans le docker-compose en localhost pour avoir un affichage de métrique dans grafana. Si vous en déployez d’autres il vous suffit de dupliquer la configuration de celui dans le prometheus.yml pour que prometheus les scrape en pensant à changer les IPs.

- job_name: 'localhost'     # <-- j'ai mis ce titre de job mais le truc c'est de mettre un nom de job explicite
  static_configs:
    - targets: ['127.0.0.1:9100']
  scrape_interval: 5s

Prometheus

Pour prometheus nous avons fait une configuration assez basique avec un alertmanager configuré en localhost:9093. Dans ce fichier vous allez retrouver une configuration de base mais il va falloir remplir les adresses que vous souhaitez scrapper. C’est normalement les machines sur lesquelles vous avez déployé le node exporter. Donc les IPs du fichier d’host d’ansible fait dans l’étape précédente.

Voici la configuration :

global:
  scrape_interval:     15s # Par défaut prometheus va scrapper les cibles toutes les 15 secondes

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    env: 'infrastructure'   # C'est simplement le nom de votre environnement

# spécification du serveur alertmanager

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093
    scheme: http
    timeout: 10s

# fichier de règles pour l'alerting, c'est dans ce fichier que sont les définitions des alertes

rule_files:
  - "/alertmanager/alert.rules/alerts.rules.yml"

# la scrape configuration de prometheus, les hosts qu'il va contacter pour chercher les métrique
scrape_configs:

  - job_name: 'localhost'     # <-- j'ai mis ce titre de job mais le truc c'est de mettre un nom de job explicite
    static_configs:
      - targets: ['127.0.0.1:9100']
    scrape_interval: 5s

    ### configuration de blackbox, notre probe http 

  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]  # Look for a HTTP 200 response.
    relabel_configs:
      - source_labels: [__address__]
        regex: ([^,]*),(.*)                   # <-- ici on fait une regex pour tagger nos urls avec une virgule
        replacement: $1
        target_label: __param_target
      - source_labels: [__address__]
        target_label: instance
      - target_label: __address__
        replacement: localhost:9115  # The blackbox exporter's real hostname:port.

    static_configs:
      - targets: 
        - http://localhost:9090,prometheus

Alertmanager

Alertmanager est l’outil qui va nous permettre de dire à partir de quand nous allons lancer une alerte et sur quelle période. Cet outil vous permettra d’envoyer des alertes sur une multitude de canaux de communication. Dans cette configuration nous allons envoyer les alertes vers un slack avec un template d’alerte que nous avons fait.

Configuration alertmanager :

global:
  resolve_timeout: 5m

route:
 group_by: ['...']
 # If an alert isn't caught by a route, send it slack.
 receiver: slack_general

receivers:
- name: slack_general
  slack_configs:
  - api_url: https://hooks.slack.com/services/<VOTRE WEBHOOK SLACK>   # <-- Pensez à mettre votre URL de webhook slack ici
    channel: alert-prod                                               # <-- Penser à mettre le bon channel ici
    icon_emoji: ":rotating_light:"                                    # <-- L'emoji de votre choix pour s'afficher dans le channel slack
    title_link: "http://127.0.0.1:9090/alerts"                        # <-- Ici on met l'url d'alertmanage pour reprendre le nom des alertes sur le /alerts
    send_resolved: true                                               # <-- Ce booléen nous permet d'envoyer une seconde alerte quand elle est résolue
    title: '{{ template "custom_title" . }}'                          # <-- Reprise du template
    text: '{{ template "custom_slack_message" . }}'                   # <-- Reprise du template

templates:
  - '/etc/alertmanager/templates/default.tmpl'                        # <-- Template en go pour l'alerte slack, vous pouvez à peu près tout faire

La plupart des alertes que j’ai dans mon dépôt viennent de ce site internet : https://awesome-prometheus-alerts.grep.to

Ils listent des alertes qui sont assez générales et qui peuvent s’implémenter dans la plupart des infrastructures. Si vous avez des idées à partager n’hésitez pas à contribuer sur leur github ! 🙂

Avec le fichier alerts.rules.yml dans le dépôt vous devriez avoir toutes les alertes intéressantes pour votre infrastructure.

Blackbox

Mais voici notre probe http du jour. Blackbox c’est un petit outil qui va nous permettre de faire du monitoring de endpoint http. Il a d’autres fonctionnalités bien sympathique, il permet de connaître l’état de vos certificats SSL et rapporte tout à Prometheus bien gentillement ce qui nous permettra de faire nos alertes. Pour celui-ci j’ai laissé la configuration par défaut tout va se jouer au niveau de l’alerting pour le coup.

La configuration est celle de base :

modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_status_codes: [] #default to 2xx
method: GET

Sur mon projet actuel, nous avons une architecture en microservices qui est très pratiques pour savoir si tous nos services sont actifs.

Les adresses que vous souhaitez monitorer avec blackbox se trouvent dans le fichier de configuration prometheus.yml , vous devrez les ajouter dans la partie static_configs en bas du fichier.

Grafana

Sans lui tout ça manquerait vraiment d’effet “wahouuu”. Grafana, c’est la partie visible de l’iceberg, c’est lui qui va tout afficher et tout nous montrer dans une interface plutôt réussie. C’est notre outil de visualisation.

Ici on a tout fait pour que ce soit le plus simple possible et que tout soit prêt au lancement du logiciel. Avec notre docker compose on va donc avoir un compte admin, la datasource prometheus ainsi qu’un dashboard prêt au démarrage. Pour le reste vous êtes libres de créer vos dashboards, de connecter d’autre datasource et d’ajouter vos utilisateurs pour donner le résultat que vous souhaitez.

L’entreprise a mis à disposition un site pour partager ses dashboards où vous pourrez retrouver toutes les meilleures créations de la communauté : grafana.com

D’ailleurs dans notre exemple nous utilisons le dashboard Node Exporter Full (id :1860 ).

Toute la configuration va se faire dans le fichier grafana.ini mais ici nous n’avons pas fait grand chose à part modifier le compte administrateur par défaut.

Vous pouvez changer le domaine de Grafana, ajouter une authentification SSO, mettre des paramètres de proxy, ajouter un serveur SMTP, etc… Tout est assez bien décrit en commentaire sur le fichier mais également sur la documentation de grafana.

La partie la plus intéressante se trouve dans le docker-compose.yml , c’est ici que nous montons les fichiers qui permettent à notre grafana d’être pré-configuré au démarrage. Avec le fichier de datasource et le fichier de dashboard, le grafana arrive avec la connexion établie à prometheus pour afficher les métriques et un dashboard pour les voir :

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://localhost:9090 

apiVersion: 1

providers:

- name: 'Monitoring'
  orgId: 1
  folder: ''
  type: file
  disableDeletion: false
  updateIntervalSeconds: 10 #how often Grafana will scan for changed dashboards
  options:
    path: /var/lib/grafana/dashboards

L’utilisateur admin par défaut dans notre configuration est le suivant :

[security]
# default admin user, created on startup
admin_user = unicorn
# default admin password, can be changed before first start of grafana,  or in profile settings
admin_password = UnicornsExists!

Conclusion

En deux temps trois mouvements il vous est possible de mettre en place un monitoring complet pour votre infrastructure avec de l’alerting pour être le plus réactif possible sur votre infrastructure. Ici je n’ai mis que l’exporter basique de métrique infrastructure mais il existe une panoplie pour une multitude de services comme Elasticsearch, MongoDB, SprintBoot, etc…

Chez Ouidou, on a fait deux trois trucs avec Consul, la stack ELK et d’autres petites choses. Si cela vous intéresse je pourrais faire d’autres articles sur ce sujet.

Vous pouvez retrouver le github de ce projet ici avec toutes les configurations : https://github.com/ouidou/monitoring-bootstrap