Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente | |||
technique:adminsys:monitoring:collect:blackbox [2022/04/29 15:45] – ↷ Liens modifiés en raison d'un déplacement. qduchemi | technique:adminsys:monitoring:collect:blackbox [2022/05/24 21:04] (Version actuelle) – ppom | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | {{indexmenu_n> | ||
+ | # Santé des services | ||
+ | |||
+ | Si les métriques exposées par les services permettent de rendre compte du nombre d' | ||
+ | |||
+ | L' | ||
+ | |||
+ | C'est exactement ce que fait [Blackbox exporter](https:// | ||
+ | |||
+ | ## Configuration | ||
+ | |||
+ | < | ||
+ | Blackbox est avant tout un *exporter*, c' | ||
+ | |||
+ | 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: | ||
+ | </ | ||
+ | |||
+ | 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: | ||
+ | headers: | ||
+ | Origin: blackbox.picasoft.net | ||
+ | # Docker often blocks v6 without further configuration, | ||
+ | # prevent false failures using v4 by default | ||
+ | preferred_ip_protocol: | ||
+ | # All our services must be HTTPS | ||
+ | fail_if_not_ssl: | ||
+ | |||
+ | 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' | ||
+ | |||
+ | * `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:// | ||
+ | |||
+ | < | ||
+ | On peut imaginer des modules plus compliqués. `tcp`, par exemple, permet d' | ||
+ | |||
+ | ```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:// | ||
+ | </ | ||
+ | |||
+ | ## Utilisation | ||
+ | |||
+ | En supposant que Blackbox est déployé avec la configuration précédente sur `blackbox.picasoft.net`, | ||
+ | |||
+ | * `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:// | ||
+ | ``` | ||
+ | |||
+ | 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' | ||
+ | |||
+ | < | ||
+ | Et c'est tout! Blackbox ne fait qu' | ||
+ | </ | ||
+ | |||
+ | ## Récupération des métriques | ||
+ | |||
+ | Comme pour les [[technique: | ||
+ | |||
+ | ```yaml | ||
+ | - job_name: blackbox-mattermost | ||
+ | scheme: " | ||
+ | basic_auth: | ||
+ | username: " | ||
+ | password: " | ||
+ | # Blackbox servers metrics under /probe | ||
+ | metrics_path: | ||
+ | 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' | ||
+ | |||
+ | < | ||
+ | Chaque métrique est attachée à un ou plusieurs labels. Par exemple, `probe_http_duration_seconds{phase=" | ||
+ | |||
+ | Par exemple, `vmagent` ajoute automatiquement un label `instance` valant `adresse: | ||
+ | </ | ||
+ | |||
+ | Voici l' | ||
+ | |||
+ | ```yaml | ||
+ | - job_name: blackbox-http | ||
+ | scheme: " | ||
+ | basic_auth: | ||
+ | username: " | ||
+ | password: " | ||
+ | metrics_path: | ||
+ | params: | ||
+ | module: [http_2xx] | ||
+ | static_configs: | ||
+ | - targets: | ||
+ | - team.picasoft.net | ||
+ | - pad.picasoft.net | ||
+ | - wiki.picasoft.net | ||
+ | - [...] | ||
+ | relabel_configs: | ||
+ | - source_labels: | ||
+ | target_label: | ||
+ | - source_labels: | ||
+ | target_label: | ||
+ | - target_label: | ||
+ | replacement: | ||
+ | ``` | ||
+ | |||
+ | < | ||
+ | |||
+ | Ici, sans relabeling, on appellerait les URL `team.picasoft.net/ | ||
+ | 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' | ||
+ | * On indique ensuite que la métrique finale aura un label `instance` valant la cible (*e.g.* `team.picasoft.net`), | ||
+ | * Enfin, on remplace carrément la cible issue de `static_configs` par `blackbox.picasoft.net`, | ||
+ | |||
+ | C'est un peu tordu, mais c'est la seule manière de faire sans duplication. | ||
+ | |||
+ | < | ||
+ | Pour l' | ||
+ | </ | ||
+ | |||
+ | ## Visualisation | ||
+ | |||
+ | Sur [[technique: | ||
+ | |||
+ | ## Debug | ||
+ | |||
+ | On peut ajouter `& | ||
+ | |||
+ | La page d' | ||
+ | |||
+ | Les identifiants sont ceux du pass (`Tech/ |