Toutes les métriques internes d’un service peuvent être vertes pendant qu’un utilisateur, à l’extérieur, ne parvient tout simplement pas à joindre le site. Un load balancer mal configuré, un certificat TLS expiré, une règle de pare-feu trop stricte : rien de tout cela ne remonte dans les métriques applicatives, parce que ces problèmes se situent précisément entre l’utilisateur et l’endroit où ces métriques sont générées. Le blackbox monitoring existe pour combler exactement cet angle mort : sonder le système depuis l’extérieur, comme le ferait un utilisateur réel, sans rien connaître de son fonctionnement interne.

Ce que les métriques internes ne peuvent pas voir

Un exporter applicatif mesure ce qui se passe une fois qu’une requête est arrivée jusqu’au processus : latence de traitement, taux d’erreur applicatif, utilisation des ressources. Il ne peut rien dire sur ce qui empêche la requête d’arriver en premier lieu. Un DNS qui pointe vers une IP obsolète, un reverse proxy qui répond mais renvoie la mauvaise page, un certificat qui a expiré à minuit : tous ces problèmes rendent un service injoignable sans qu’aucune métrique applicative n’en soit jamais informée, puisque, de son point de vue, aucune requête n’est arrivée du tout.

blackbox_exporter : un sondeur, pas un collecteur de métriques applicatives

blackbox_exporter est le composant officiel de l’écosystème Prometheus conçu pour ce rôle : il ne collecte rien à l’intérieur de l’application, il exécute des sondes HTTP, TCP, DNS ou ICMP depuis un point d’observation externe et expose le résultat sous forme de métriques Prometheus standard.

# blackbox.yml — module de sonde HTTP avec vérification TLS
modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_status_codes: [200]
      fail_if_ssl: false
      fail_if_not_ssl: true
# prometheus.yml — cible sondée via le module ci-dessus
- job_name: 'blackbox-http'
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
    - targets:
        - https://jm-dev.it
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: blackbox-exporter:9115

Le résultat le plus important n’est pas seulement probe_success (0 ou 1), mais probe_ssl_earliest_cert_expiry, qui donne la date d’expiration du certificat TLS vu depuis l’extérieur, en secondes Unix. C’est cette métrique précise qui permet d’alerter des jours à l’avance plutôt que de découvrir l’expiration au moment où les utilisateurs commencent déjà à voir des avertissements de sécurité dans leur navigateur.

Le piège du faux positif réseau

La sonde externe introduit son propre point de défaillance : si le nœud qui héberge blackbox_exporter perd sa connectivité réseau, ou si un pare-feu bloque spécifiquement son IP sortante, toutes les sondes échouent en même temps, ce qui ressemble exactement à une panne généralisée de tous les services surveillés. Distinguer une vraie panne d’un problème du sondeur lui-même demande soit plusieurs points de sonde dans des zones réseau distinctes, soit une métrique de santé du sondeur lui-même (sa propre capacité à joindre un point de contrôle connu et stable) vérifiée avant de faire confiance au reste de ses résultats.

Une règle d’alerte qui sépare vraiment panne et expiration

Le certificat TLS et la disponibilité HTTP méritent des alertes distinctes, avec des urgences différentes : une expiration de certificat dans sept jours n’est pas une urgence de nuit, une indisponibilité HTTP l’est.

groups:
  - name: blackbox
    rules:
      - alert: ProbeFailing
        expr: probe_success == 0
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "{{ $labels.instance }} injoignable depuis l'extérieur"

      - alert: CertificateExpiringSoon
        expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 14
        labels:
          severity: ticket
        annotations:
          summary: "Certificat de {{ $labels.instance }} expire dans moins de 14 jours"

Où ça se range

Le blackbox monitoring ne remplace ni les golden signals applicatifs ni un dashboard structuré : il ajoute la seule perspective qu’aucun des deux ne peut avoir, celle de l’extérieur du système. C’est la couche la plus proche de ce qu’un utilisateur vit réellement, et souvent la première qui aurait détecté un incident avant que quiconque en interne ne le remarque. Mettre en place cette couche de supervision externe fait partie de ce qui se traite dans une mission de fiabilité et observabilité.

À retenir

Les métriques internes ne voient jamais ce qui empêche une requête d’arriver ; le blackbox monitoring sonde depuis l’extérieur comme le ferait un utilisateur réel. blackbox_exporter expose probe_success pour la disponibilité et probe_ssl_earliest_cert_expiry pour anticiper une expiration de certificat, mais le sondeur lui-même est un point de défaillance à surveiller séparément pour éviter les faux positifs de panne généralisée.