{{indexmenu_n>30}}

# Santé des services

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](https://github.com/prometheus/blackbox_exporter), un projet développé par l'équipe derrière Prometheus.

## Configuration

<bootnote>
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 [[technique:adminsys:monitoring:collect:service_metrics|exporters des services]]. Seules les cibles `vmagent` changent, voir plus bas.
</bootnote>

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

```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](https://fr.wikipedia.org/wiki/SOA_Resource_Record) de la zone `picasoft.net`

<bootnote>
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 :

```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](https://gitlab.utc.fr/picasoft/projets/services/monitoring/-/blob/master/blackbox.yml) est fonctionnel.
</bootnote>

## Utilisation

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.

<bootnote critical>
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.
</bootnote>

## Récupération des métriques

Comme pour les [[technique:adminsys:monitoring:collect:service_metrics#configuration_vmagent|exporters des services]], il suffirait de créer autant de jobs que de services, du style :

```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](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config) pour n'utiliser qu'un seul job.

<bootnote>
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.
</bootnote>

Voici l'astuce :

```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.
```

<bootnote>Voir [cet excellent article](https://prometheus.io/docs/guides/multi-target-exporter/) pour l'ensemble des explications.</bootnote>

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.

<bootnote>
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.
</bootnote>

## Visualisation

Sur [[technique:adminsys:monitoring:metrologie:grafana|Grafana]], on pourra importer [ce dashboard](https://grafana.com/grafana/dashboards/13659) comme base, qui reprend la plupart des métriques récoltées dans un format lisible.

## Debug

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`).