Note technique · Infra widal

Gatus mérite-t-il une place dans notre stack de supervision ?

Étude d'opportunité sur l'outil Gatus, mise en regard de l'existant (Grafana, Uptime Kuma, Centreon, Kibana) déjà en place sur l'environnement. Objectif : identifier ce qu'il apporterait réellement, et non redondance.

Rédigé le 29 septembre 2026 Type : outil de health-check / status page Licence : MIT, open source Recommandation : oui, en complément ciblé

1Qu'est-ce que Gatus ?

Gatus est un outil de health-check et de status page, développé par TwiN, pensé pour les équipes qui préfèrent décrire leur supervision en configuration plutôt qu'en cliquant dans une UI. Il se présente comme un unique binaire Go, livré dans une image Docker "scratch" de moins de 20 Mo.

<50 Mo
RAM en usage courant
12
protocoles de check supportés
YAML
configuration déclarative, versionnable en Git

Protocoles de health-check supportés

HTTP(S) TCP ICMP DNS gRPC WebSocket SSH UDP SCTP STARTTLS TLS Certificat X.509 (expiration)

2Fonctionnalités clés

Ce qui distingue Gatus d'un simple "ping toutes les 30 secondes".

🔎 Conditions avancées

Pas seulement "200 OK" : expressions JSONPath sur le corps de la réponse, seuil de temps de réponse, jours avant expiration d'un certificat TLS, valeur d'un enregistrement DNS, plage d'IP attendue.

🔗 Parcours multi-étapes

Un même endpoint peut enchaîner plusieurs requêtes avec un contexte partagé : login → récupération d'un token → appel API authentifié → vérification du contenu. Utile pour tester un vrai parcours utilisateur, pas juste "le serveur répond".

📊 Dashboard intégré + export Prometheus

Une page web native montre l'état courant, l'historique de disponibilité et les temps de réponse. Un endpoint /metrics expose aussi ces données au format Prometheus, avec des labels par groupe d'endpoints — donc scrapable directement par le Prometheus déjà déployé sur widal-srv2.

🔔 Alerting multi-canal

Slack, Discord, Telegram, PagerDuty, e-mail, webhooks génériques... déclenché nativement sans passer par un Alertmanager séparé.

3Face à l'existant de l'environnement

Aucun de ces outils ne joue exactement le même rôle — le tableau ci-dessous positionne chacun pour éviter tout doublon avant d'envisager Gatus.

Outil Rôle principal Mode de configuration Point fort
Grafana Visualisation de métriques time-series (dashboards) UI + provisioning JSON Corrélation de métriques riches (ex. wsrep_* Galera), alerting sur seuils complexes
Uptime Kuma Monitoring d'uptime avec UI conviviale 100% interface web, base SQLite interne Prise en main immédiate, aucune compétence YAML/Git requise
Centreon Supervision d'infrastructure complète (NMS) UI + plugins Nagios-compatibles Couverture exhaustive (matériel, réseau, agents), gestion d'escalade mature
Kibana Exploration et visualisation de logs (ELK) UI sur données Elasticsearch Recherche full-text et analyse de logs bruts, pas de check actif
Gatus Health-check déclaratif + status page Fichier YAML versionné en Git Ultra-léger, conditions fines (JSONPath, TLS, DNS), parcours multi-étapes

4Ce que Gatus apporterait concrètement

Quatre manques réels que ni Grafana, ni Centreon, ni Kibana ne couvrent bien aujourd'hui.

01

Une status page publique, lisible sans compte ni formation

Grafana et Centreon sont des outils internes : montrer leur état à un client ou à une équipe non technique suppose soit un accès dédié, soit un export manuel. Gatus génère nativement une page publique simple ("tout est vert / il y a un incident"), sans exposer de métriques internes sensibles.

vs. Grafana/Centreon : dashboards internes, pas conçus pour un public externe
02

Des checks "synthétiques" multi-étapes légers

Tester un vrai parcours (login → appel API → vérification de contenu) est possible dans Centreon via un plugin Nagios sur mesure — plus lourd à écrire et à maintenir qu'un bloc YAML de 15 lignes dans Gatus.

vs. Centreon : nécessite un plugin custom par parcours testé
03

De la supervision "as code", versionnée avec le service qu'elle surveille

Un fichier gatus.yaml peut vivre dans le même dépôt Git que l'application supervisée : le check évolue avec le code, revu en pull request. Ni Grafana, ni Uptime Kuma (config en base de données via UI) n'offrent ce couplage nativement.

vs. Uptime Kuma : configuration exclusivement en UI, non versionnable
04

Une empreinte quasi nulle sur un hôte déjà contraint

<50 Mo de RAM contre 100-150 Mo pour Uptime Kuma (runtime Node.js) et bien plus pour un serveur Centreon complet. Pertinent vu que widal-srv2 héberge déjà un nœud Galera + Prometheus + Grafana avec une RAM serrée (voir CLAUDE.md du projet dakou-srv).

vs. Uptime Kuma / Centreon : empreinte mémoire nettement supérieure

5Cas d'usage concrets pour l'environnement widal

Quatre scénarios réalistes, à partir des services déjà en place.

Scénario A — Status page publique pour les domaines widal-*

Un client ou un collègue non technique veut savoir si widal-prom ou widal-graf sont disponibles, sans accès Grafana. Gatus interroge ces URLs en HTTPS toutes les 30s (code 200 attendu, temps de réponse < 2s) et affiche un statut vert/rouge public, sans exposer aucune métrique interne. Zéro compte à créer, zéro formation.

Scénario B — Surveillance des certificats Let's Encrypt

Plus d'une soixantaine de vhosts *.dev01.ovh.smile.ci existent déjà sur dev01, chacun avec son certificat renouvelé automatiquement par certbot. Un renouvellement qui échoue silencieusement casse un domaine du jour au lendemain. Une condition Gatus certificate_expiration > 168h sur chaque domaine public donne une alerte indépendante de certbot, avant l'expiration réelle.

Scénario C — Parcours applicatif de bout en bout

Pour un futur service exposé (API interne, portail), un endpoint Gatus multi-étapes peut : appeler /login, extraire un token de la réponse JSON, rappeler /api/health avec ce token, puis vérifier un champ précis du corps de réponse. Ce test valide que la chaîne complète fonctionne, pas seulement que le serveur HTTP répond.

Scénario D — Sentinelle légère pour les clusters Galera

En complément du dashboard "Galera Health" déjà bâti sur Prometheus/Grafana (métriques wsrep_* détaillées), un check TCP Gatus simple sur le port 3306 des 6 nœuds widal-srv1-6 donne un signal binaire "joignable/pas joignable" ultra basique, utile comme filet de sécurité si jamais mysqld_exporter lui-même tombait en panne (auquel cas Prometheus seul ne verrait qu'un "no data", pas un "down" explicite).

6Architecture proposée

Gatus s'insère à côté de la stack existante sans la dupliquer : il consomme les mêmes cibles publiques, et pousse ses métriques vers le Prometheus déjà en place sur widal-srv2.

INTERNET (HTTPS) dev01 — Apache reverse proxy + Let's Encrypt Gatus nouvelle VM légère status page + /metrics widal-srv2 Prometheus (existant) + Grafana (existant) Services supervisés widal-prom / widal-graf nœuds widal-srv1-6 (TCP 3306) futurs endpoints publics widal-status.dev01.ovh.smile.ci existant : widal-prom / widal-graf checks actifs HTTP / TCP / TLS export /metrics Nouveau (proposé) Existant, inchangé Gatus vérifie les mêmes endpoints publics que dev01 expose déjà, et vient s'ajouter au Prometheus existant plutôt que de créer un second silo de métriques.

7Avantages / Inconvénients

✓ Avantages

  • Empreinte minimaleBinaire Go statique, image Docker <20 Mo, déploiement en quelques secondes.
  • Conditions de check très finesJSONPath, seuils numériques, expiration de certificat, valeur DNS — au-delà du simple "contient une chaîne".
  • Intégration Prometheus nativeVient s'agréger directement dans le Grafana déjà en place, sans nouvel outil de visualisation.
  • GitOps par natureConfiguration YAML versionnable, revue en pull request, reproductible.
  • Status page prête à l'emploiIdéal pour une communication externe simple sans construire un outil dédié.

✕ Inconvénients

  • Instance uniquePas de check multi-régions natif : ne distingue pas "le service est down" de "le lien réseau vers Gatus est down".
  • Verrou global d'évaluationUn endpoint lent ou en timeout (10s par défaut) retarde l'évaluation des autres pendant ce laps de temps.
  • Pas de gestion d'incidentAucune création manuelle d'incident, pas de fenêtres de maintenance planifiées, pas de notifications aux abonnés finaux.
  • Communauté plus restreinte~11 600 ⭐ GitHub contre ~89 500 pour Uptime Kuma — moins de ressources tierces, moins de contributeurs.
  • Pas d'authentification native sur la status pageNécessite un reverse-proxy avec Basic Auth si l'accès doit être restreint.

8Recommandation

Verdict : intégration ciblée, pas un remplacement

Gatus ne doit pas remplacer Grafana (analyse de métriques), Centreon (supervision d'infrastructure) ni Kibana (logs) — ce sont des outils à portée différente. Sa valeur ajoutée réelle ici est double : une status page publique légère et des health-checks synthétiques déclaratifs pour les services exposés publiquement (comme les domaines *.dev01.ovh.smile.ci déjà en place).

Candidat concret et à faible risque pour un premier déploiement pilote : superviser les endpoints publics déjà exposés (widal-prom, widal-graf, et les futurs services widal-*) avec des checks HTTP + certificat TLS, et exporter ces métriques vers le Prometheus existant sur widal-srv2.

  1. Déployer Gatus en conteneur/binaire unique sur une VM peu chargée du groupe widal (pas widal-srv2, déjà contraint en RAM).
  2. Écrire un gatus.yaml minimal : 3-4 endpoints HTTP publics + un check d'expiration de certificat Let's Encrypt.
  3. Activer l'export /metrics et ajouter la cible au prometheus.yml déjà en place, dans un job dédié.
  4. Exposer la status page via apache-reverse-add, avec Basic Auth si l'accès doit rester interne pour cette phase pilote.
  5. Réévaluer après 2-3 semaines : si la valeur perçue est confirmée, étendre aux endpoints internes critiques (health-checks HAProxy, par exemple).