Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:adminsys:monitoring:metrologie:collect:docker [2021/08/29 21:36] qduchemitechnique:adminsys:monitoring:collect:blackbox [2022/05/24 21:04] (Version actuelle) ppom
Ligne 1: Ligne 1:
 {{indexmenu_n>30}} {{indexmenu_n>30}}
  
-Collecte des métriques HTTP/DNS+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`).
  • technique/adminsys/monitoring/collect/blackbox.1630265810.txt.gz
  • de qduchemi