blog.bressure.net

La mise en place du node exporter pour apache me permet de surveiller mon reverse proxy. Je peux ainsi m’assurer que mon infra est bien accesssible.

Cela ne m’assure pas que les services qui sont derrière le reverse proxy sont bien accessibles.

Définition de l’accessibilité

Que le reverse proxy fonctionne est une condition nécessaire, que le processus du service backend fonctionne est une nécessité également mais si par exemple le DNS ne fonctionne pas, le service n’est plus accessible. Plus généralement un service est accessible si il l’est pour son utilisateur. La métriques doit donc utiliser une sonde qui se place comme un utilisateur.

Diagnostique de non accessibilité

Cela consistera pour moi à vérifier que les url des services sont bien accessibles au travers la brique la plus externe de mon architecture. Cela revient à passer par l’IP publique de ma box soit l’url publique de mes services. Pour cela un blackbox sur l’hôte permettra de verifier les url publiques des services. De manière générale, un blackbox sera installé sur chaque neoud de l’infrastructure: l’hôte principal et les 2 VM à conteneurs.

En cas d’échec la cause du problème restera encore à chercher. Elle peut provenir de n’importe quelle brique des couches sous-jacentes: box, reverse proxy, VM, service, base de données ?

Un blackbox par hôte

Le rapidite du diagnostique de la non accessibilité demande des métriques sur les briques profondes. La box ne peut pas vraiment être testée car toute l’architecture est derrière celle-ci. Le reverse proxy est déjà testé par l’exporter apache. Pour les VM on pourra utiliser le ping de blackbox depuis la machine hôte. Un test via la blackbox de l’hôte vers l’url local des services (comme utilisé dans le reverse proxy) pourra vérifier la liaison entre le reverse proxy et les services. Enfin les blackbox sur les VM pourra vérifier l’ accessibilité des services en local. Pour ce qui est du diagnostique des bases de données, comme celles-ci ne sont pas exposées vers l’exterieur, je ne peux pas les tester depuis les blackbox de l’hôte.

Mise en place des blackbox

L’opération est des plus simples. Il suffit d’ajouter le service prom/blackbox-exporter dans mon application prom-node qui regroupe tous les services distanciés sur chacun de mes noeuds.

version: "3.7"
services:
  blackbox_exporter:
    image: 'prom/blackbox-exporter'
    restart: always
    ports:
      - '9115:9115'
    volumes:
      - blackbox_conf:/etc/blackbox_exporter
....
volumes:
  blackbox_conf: {}

Je mets en volume le repertoire de configuration du conteneur blackbox-exporter car cdans mon cas j’ai dû forcer l’ipv4. Oui v4 !

Forcage IPv4

En faisant un test depuis l’hôte et en passant l’argument debug=true je voyais une erreur remontée par un composant Go qui n’arrivait pas à acceder aux urls de mes services car il prenait systématiquement l’IPv6 associé. Malheureusement cela ne marche pas même après avoir activé l’IPv6 dans le démon docker. Pour faire simple j’ai choisi de forcer l’IPv4. Comme j’ai monté la configuration en volume il suffit d’aller modifier sur l’hôte le fichier /var/lib/docker/volumes/prom-node_blackbox_conf/_data/config.yml

modules:
  http_2xx:
    prober: http
    http:
       preferred_ip_protocol: ip4

Configuration de prometheus

Pour configurer prometheus il suffit de suivre à lettre la documentation de blackbox. Remarquons la subtilité qui consiste à changer le point d’appel par l’adresse du blackbox et passer le point d’appel en paramètre car au final c’est le blackbox qui interroge le point d’appel.

- job_name: 'services depuis internet'
  metrics_path: /probe
  params:
     module: [http_2xx] # Look for a HTTP 200 response.
  static_configs:
  - targets:
    # - http://prometheus.io # Target to probe with http.
    # - https://prometheus.io # Target to probe with https.
    # - http://example.com:8080 # Target to probe with http on port 8080.
     - https://blog.bressure.net
     - https://kitejust4fun.bressure.net
     - https://mattermost.bressure.net
     - https://www.kitejust4fun.fr
     - https://owncloud.bressure.net
     - https://bikejust4fun.bressure.net
     - https://www.cramayailes.fr
     - https://matomo.bressure.net
     - https://gitlab.bressure.net
     - https://registry.bressure.net
     - https://prometheus.bressure.net
     - https://grafana.bressure.net
  relabel_configs:
     - source_labels: [__address__]
       target_label: __param_target
     - source_labels: [__param_target]
       target_label: instance
     - target_label: __address__
       replacement: 192.168.0.12:9115

Lorsque je veux vérifier que la liaison avec les backend est fonctionnelle, j’utilise directement les adresses IP dans un autre job et cela donne:

- job_name: 'services depuis infra'
  metrics_path: /probe
  params:
     module: [http_2xx] # Look for a HTTP 200 response.
  static_configs:
  - targets:
    # - http://prometheus.io # Target to probe with http.
    # - https://prometheus.io # Target to probe with https.
    # - http://example.com:8080 # Target to probe with http on port 8080.
    # blackbox infra
     - http://192.168.0.12:9115
    # blackbox production
     - http://192.168.122.30:9115
    # blog pro
     - http://192.168.122.30:8081
    # bikejust4fun
     - http://192.168.122.30:8082
    # kitejust4fun blog
     - http://192.168.122.30:8083
    # kitejust4fun asso
     - http://192.168.122.30:8084
    # matomo
     - http://192.168.122.30:8085
    # cramayailes
     - http://192.168.122.30:8086
    # owncloud
     - http://192.168.122.30:8087
    # mattermost
     - http://192.168.122.30:8088
    # gitlab, registry
     - http://192.168.0.12:8080
    # prometheus
     - http://192.168.0.12:9090
    # grafana
     - http://192.168.0.12:3000


  relabel_configs:
     - source_labels: [__address__]
       target_label: __param_target
     - source_labels: [__param_target]
       target_label: instance
     - target_label: __address__
       replacement: 192.168.0.12:9115

Comme les instances qui sont relatives au même service, par exemple ce blo sont référencées par des url différentes https://blog.bressure.net ou http://192.168.122.30:8081, il faudra faire une gymnastique dans la tableau de bord. Pour simplifier l’utilisation des métriques, je préfère ajouter un label spéciale que j’appelle service et qui me permettra de regrouper les métriques d’un même service. Pour cela j’utilise la fonction de modification des label déjà vu pour l’astuce du blackbox. Ainsi pour que mon blog j’ajoute le label service=blog par la configuration:

relabel_configs:
     - source_labels: [__address__]
       target_label: __param_target
     - source_labels: [__param_target]
       target_label: instance
     - target_label: __address__
       replacement: 192.168.0.12:9115 # The blackbox ex
     - source_labels: [instance]
       regex: 'http\:\/\/192\.168\.122\.30\:8081'
       replacement: 'blog'
       target_label: service

Test de connectivité

Le test HTTP est parfois non pertinent quand on veux juste vérifier que quelques chose répond. Il est alors suffisant de tester qu’une connexion TCP est possible. Je fais alors un job dans Prométheus:

 job_name: 'connection depuis infra'
  metrics_path: /probe
  params:
     module: [tcp_connect]
  static_configs:
  - targets:
    # - http://prometheus.io # Target to probe with http.
    # - https://prometheus.io # Target to probe with https.
    # - http://example.com:8080 # Target to probe with http on port 8080.
    # blackbox infra
     - 192.168.0.12:9115
    # blackbox production
     - 192.168.122.30:9115
    # blog pro
     - 192.168.122.30:8081
    # bikejust4fun
     - 192.168.122.30:8082
    # kitejust4fun blog
     - 192.168.122.30:8083

La prochaine étape sera de mettre en place des alertes quand les services ne sont plus disponibles.