Navigation

Si les métriques exposées par les services permettent de rendre compte du nombre d’utilisateurs, de requêtes, etc, elles ne sont pas très pratiques pour savoir si le service en question est en bonne santé.

L’idée est d’utiliser un service tiers dont le rôle sera simplement de pinger nos services et de servir quelques métriques simples (service up, temps de réponse, etc).

C’est exactement ce que fait Blackbox exporter, un projet développé par l’équipe derrière Prometheus.

Note:

Blackbox est avant tout un exporter, c’est-à-dire un serveur web qui expose des métriques quand on lui demande.

Ainsi, on ne détaille pas dans cette documentation la mise en place avec Docker et Traefik, qui est exactement la même que pour les exporters des services. Seules les cibles vmagent changent, voir plus bas.

Blackbox se configure essentiellement en lui disant comment évaluer la santé des différents types de services. Exemple :

snippet.yaml

modules:
  http_2xx:
    # Probe web services and give up after 10s of no response
    prober: http
    timeout: 10s
    http:
      method: GET
      # Because Traefik could redirect to
      # HTTPS, we need to follow to see if service is up
      follow_redirects: true
      headers:
        Origin: blackbox.picasoft.net
      # Docker often blocks v6 without further configuration,
      # prevent false failures using v4 by default
      preferred_ip_protocol: ip4
      # All our services must be HTTPS
      fail_if_not_ssl: true

  dns_soa:
    # To detect DNS servers failures
    prober: dns
    dns:
      query_name: picasoft.net
      query_type: SOA

Ici, on indique à Blackbox qu’il sera amener à évaluer l’état de santé des services de deux manières différentes :

http_2xx évaluera un service web comme vivant s’il répond à une requête GET avec un code 2XX dans les 10 secondes et que la connexion est chiffrée.
dns_soa évaluera un serveur DNS comme vivant s’il renvoie le champ SOA de la zone picasoft.net

Note:

On peut imaginer des modules plus compliqués. tcp, par exemple, permet d’initier une session TCP et de vérifier la réponse du serveur. On pourrait par exemple vérifier qu’un serveur Postfix fonctionne, s’il renvoie 220 .+ ESMTP Postfix (Debian/GNU) après l’initiation de la connexion… Un tel module commencerait comme ça :

snippet.yaml

  smtp_check:
    prober: tcp
    tcp:
      query_response:
        - expect: "^220 ([^ ]+) ESMTP (.+)$"

C’est effectivement ce genre de choses qu’on utilise pour vérifier que le serveur mail est fonctionnel.

En supposant que Blackbox est déployé avec la configuration précédente sur blackbox.picasoft.net, il suffit de lui envoyer une requête GET sur le chemin /probe avec en paramètres :

module : le type de test à effectuer
target : la cible du test (URL ou IP avec port optionel)

Ainsi, pour générer des métriques sur la disponibilité de Mattermost, on appellera l’URL suivante :

https://blackbox.picasoft.net/probe?module=http_2xx&target=team.picasoft.net

On aura alors typiquement :

# HELP probe_duration_seconds Returns how long the probe took to complete in seconds
# TYPE probe_duration_seconds gauge
probe_duration_seconds 0.065375161
[...]
# HELP probe_success Displays whether or not the probe was a success
# TYPE probe_success gauge
probe_success 1

Qui indique que le service est en bonne santé et que l’évaluation a pris 6ms.

Important:

Et c’est tout! Blackbox ne fait qu’exposer des métriques quand on lui demande : c’est bien un exporter. Il faut maintenant demander à vmagent de récupérer périodiquement les métriques pour l’ensemble des cibles.

Comme pour les exporters des services, il suffirait de créer autant de jobs que de services, du style :

snippet.yaml

- job_name: blackbox-mattermost
    scheme: "https"
    basic_auth:
      username: "%{BLACKBOX_METRICS_USER}"
      password: "%{BLACKBOX_METRICS_PASSWORD}"
    # Blackbox servers metrics under /probe
    metrics_path: /probe
    params:
      module: [http_2xx]
      target: [team.picasoft.net]
    static_configs:
      - targets:
        - blackbox.picasoft.net

Cette configuration générera la même URL que dans la section précédente. Le problème est qu’il faudrait multiplier cette configuration pour l’ensemble des cibles, ce qui fait énormément de duplication. On va donc se servir du relabeling pour n’utiliser qu’un seul job.

Note:

Chaque métrique est attachée à un ou plusieurs labels. Par exemple, probe_http_duration_seconds{phase="connect"} a un label phase. Ces labels peuvent être modifiés lors de l’enregistrement des métriques, ce qui servira plus tard pour l’alerting ou la visualisation.

Par exemple, vmagent ajoute automatiquement un label instance valant adresse:port à chaque métrique récupérée. C’est assez moche pour la visualisation, alors on pourrait lui demander de ne garder que l’adresse sans le port, ou simplement le premier sous-domaine.

Voici l’astuce :

snippet.yaml

  - job_name: blackbox-http
    scheme: "https"
    basic_auth:
      username: "%{BLACKBOX_METRICS_USER}"
      password: "%{BLACKBOX_METRICS_PASSWORD}"
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - team.picasoft.net
        - pad.picasoft.net
        - wiki.picasoft.net
        - [...]
    relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: blackbox.picasoft.net  # The blackbox exporter’s real hostname:port.

Note:

Voir cet excellent article pour l’ensemble des explications.

Ici, sans relabeling, on appellerait les URL team.picasoft.net/probe?module=http_2xx, etc, ce qui n’est pas du tout ce qu’on veut. Mais le relabeling permet de faire ce qu’on veut, à savoir appeler autant de fois blackbox.picasoft.net qu’il y a de cibles.

__address__ est un label interne qui contient la cible courante issues de static_configs. On l’ajoute comme paramètre GET, sous le nom de target (c’est le sens du label interne __param_target)
On indique ensuite que la métrique finale aura un label instance valant la cible (e.g. team.picasoft.net), c’est ce que l’on veut
Enfin, on remplace carrément la cible issue de static_configs par blackbox.picasoft.net, ce qui aura pour effet d’appeler ce dernier à la fin.

C’est un peu tordu, mais c’est la seule manière de faire sans duplication.

Note:

Pour l’évaluation de la santé des serveurs DNS, on suivra le même principe avec un nom de job différent et un paramètre module valant dns_soa, pour reprendre l’exemple de configuration.

Sur Grafana, on pourra importer ce dashboard comme base, qui reprend la plupart des métriques récoltées dans un format lisible.

On peut ajouter &debug=true à n’importe quelle URL de récupération des métriques pour avoir une idée de ce qui ne va pas.

La page d’accueil de Blackbox, blackbox.picasoft.net, permet de visualiser les derniers probes et de visualiser ceux qui ont raté.

Les identifiants sont ceux du pass (Tech/Prometheus/Blackbox).