Le défi
Ce que nous avons réalisé
Une supervision qu’il a fallu apprendre à vivre sans root
Nous avons construit ce tableau de bord pour voir notre propre serveur : charge, disque, réseau, disponibilité des sites, erreurs dans les journaux et factures des services cloud. Puis des clients l’ont demandé — et il est devenu un produit.
La difficulté n’était pas dans les graphiques. Elle est que la moitié des clients sont sur de l’hébergement mutualisé, où il n’y a ni root, ni accès aux compteurs système, ni SSH pour pousser une mise à jour.
La rangée du haut répond à « tout va bien ? » en une seconde. Le reste répond à « quoi exactement ».
Deux moitiés d’un même outil
Le collecteur et l’interface web sont séparés volontairement. Le collecteur tourne une fois par minute en root — sinon il ne voit ni les compteurs système, ni les journaux du serveur web, ni les configurations de domaines. L’interface tourne en utilisateur ordinaire et n’a accès à rien d’autre qu’une seule base.
Entre les deux, SQLite. Les métriques vivent trente-cinq jours, les erreurs sept. Ce n’est pas une archive, c’est une fenêtre qui montre ce qui a changé au cours du dernier mois.
Une charge visible d’un seul tenant
Processeur, mémoire, swap, disque, entrées-sorties, IOPS, réseau, nombre de processus et de workers PHP — le tout sur un écran, avec une période de trente minutes à trente jours. Là où il existe un plafond dur, un pointillé le montre : non pas « beaucoup ou peu », mais ce qu’il reste avant la limite.
Les sites sont interrogés en contournant le DNS
Chaque domaine est vérifié une fois par minute — mais la requête part directement vers l’IP du serveur, pas via le DNS public. Un détail aux grandes conséquences : si un site répond par IP mais pas par son nom, le problème n’est pas le site mais l’enregistrement DNS. L’outil fait la différence et le dit franchement.
Ce qui ne change pas d’une minute à l’autre est vérifié à part et moins souvent : le DNS tous les quarts d’heure, les certificats toutes les six heures. Le tableau montre le code de réponse, le temps de réponse, la disponibilité sur vingt-quatre heures, l’échéance du certificat et le nombre d’erreurs.
Des erreurs sans le bruit
Le journal du serveur web est lu en continu : l’outil retient où il s’est arrêté et ne relit pas le fichier après une rotation. Mais l’essentiel est dans le filtre.
Les domaines fermés volontairement écrivent « accès refusé » dans le journal toutes les minutes — c’est la protection qui fonctionne, pas une panne. Les entrées produites par notre propre supervision ne sont pas des erreurs non plus. Avertissements et notices ne comptent pas comme des incidents. Sans ce nettoyage, la liste d’erreurs devient un flux que plus personne ne regarde.
L’argent à côté des métriques
Un serveur ne tombe pas seulement sous la charge — parfois sous la facture. L’outil affiche donc le trafic mensuel en part du quota, la dépense de stockage avec une projection à la fin du mois, et la dépense d’API ventilée par modèle. La projection se calcule sur le rythme réel, pas sur la moyenne du mois.
Une page publique séparée de l’outil
Ce que voit le propriétaire et ce que l’on peut montrer aux clients sont deux choses différentes. L’outil est derrière un mot de passe, et à côté se trouve une page de statut publique : quatre-vingt-dix jours de barres de disponibilité, le temps de réponse moyen et une phrase en haut — ça marche ou non.
Des mises à jour sans accès au serveur d’autrui
Nous n’avons pas de SSH sur les serveurs des clients, et nous ne devons pas en avoir. La liaison va donc dans l’autre sens : une fois par jour, l’installation appelle notre panneau, confirme sa licence et récupère la mise à jour s’il y en a une.
La licence est signée et vérifiée hors ligne à chaque requête, sans nous interroger — si notre serveur tombe, les tableaux de bord clients continuent de fonctionner. Pour une panne longue, une réserve de deux semaines est prévue : notre incident ne doit pas éteindre l’installation d’autrui.
Les petites mises à jour s’installent seules, les grandes sur un bouton. Depuis notre panneau, une version peut être déployée de force, mais uniquement vers les installations dont le code contient déjà le récepteur de cet ordre. C’est une limite honnête de l’architecture, et elle est visible dans l’interface.
Déroulé du projet
Sous le capot
Collecteur
PHP planifié tournant en root, lecture des compteurs système, interrogation des domaines directement sur l’IP, lecture incrémentale des journaux avec position mémorisée. Stockage SQLite : métriques 35 jours, erreurs 7.
Tableau de bord
Aucune bibliothèque externe : les graphiques sont dessinés en SVG côté serveur. Rôles administrateur et observateur, page de statut publique en couche séparée.
Produit
Licences signées Ed25519, vérification hors ligne à chaque requête, contrôle quotidien, réserve de deux semaines. C’est l’installation qui tire la mise à jour — aucun SSH chez le client n’est nécessaire.
Le résultat
L’outil que nous avions écrit pour nous tourne aujourd’hui sur huit installations, dont cinq sur des domaines clients. Il se comporte de la même façon sur un VPS avec accès complet et sur un hébergement mutualisé où la moitié des métriques est hors de portée : dans le second cas, il n’affiche simplement pas ce qu’il ne peut pas savoir, au lieu de tracer des zéros.
Et la décision d’architecture principale s’est révélée juste : en tout ce temps, aucune mise à jour n’a exigé de se connecter au serveur de quelqu’un d’autre.
Un projet similaire ?
Discutons de vos objectifs et voyons comment nous pouvons vous aider.
Demander un devis gratuit →
