« C’est lent. » Deux mots, aucune adresse de serveur et tout un trajet possible. Le ping confirme qu’une interface réseau répond. Il ne confirme ni que la page s’ouvre, ni que la requête SQL termine, ni que l’utilisateur obtient le bon résultat.

Je séparerais la supervision en trois couches. La disponibilité vérifie les composants. La performance mesure leurs compteurs. Le service exécute un geste représentatif de bout en bout.

test HTTP -> serveur Web -> service applicatif -> SQL Server
    |             |                |                 |
temps total    CPU/mémoire      file/erreurs      verrous/disque

SNMP peut interroger les routeurs et commutateurs pour obtenir octets, erreurs et état des interfaces. WMI et les compteurs de performance Windows donnent CPU, mémoire, files disque et processus. Les journaux d’événements et syslog expliquent les changements. Un test synthétique demande périodiquement une page, vérifie son contenu et chronomètre la réponse.

Construire un budget de latence

Supposons que la page cible doive répondre en moins de deux secondes :

réseau aller-retour       150 ms
serveur Web               100 ms
service applicatif        250 ms
requête SQL               500 ms
rendu et marge          1 000 ms
budget total            2 000 ms

Si le test mesure 4 secondes, ce budget donne des points de comparaison. Une moyenne de 500 ms peut aussi cacher des pointes à 10 secondes; je garderais la distribution et le 95e percentile, pas seulement la moyenne.

Les seuils statiques demandent du contexte. Un CPU à 90 % pendant trente secondes peut être un traitement normal. Une file de disque qui monte pendant vingt minutes et un temps SQL qui double annoncent davantage un problème. L’alerte devrait combiner durée, impact et capacité d’action. Sinon, cent messages apprennent à l’équipe à tout ignorer.

La synchronisation des horloges est essentielle. Si le serveur Web est décalé de trois minutes par rapport à SQL Server, reconstituer la chaîne dans les logs devient presque impossible. Je propagerais aussi un identifiant de corrélation dans les appels afin de suivre une transaction précise sans deviner à partir de l’heure.

La supervision peut elle-même tomber. Un agent arrêté ou un lien coupé ne devrait pas afficher un beau vert basé sur la dernière mesure. Une donnée trop vieille devient Inconnu, et le système de surveillance doit être observé depuis un autre point. Les tests synthétiques utilisent un compte limité et des données sans conséquence; on ne veut pas créer une vraie commande toutes les cinq minutes.

Une dépendance réseau mérite deux points de mesure. Un test lancé dans la salle serveur peut confirmer l’application pendant que le lien du bureau est saturé. Un second test depuis le réseau utilisateur sépare cette panne de chemin d’une panne du service. Les compteurs d’interface indiquent ensuite pertes, erreurs et utilisation; un traceroute ponctuel ne remplace pas l’historique.

Je prévoirais enfin une fenêtre de maintenance déclarée. Elle suspend l’escalade attendue sans effacer les données, puis déclenche un contrôle au retour. Sinon, chaque correction planifiée entraîne une avalanche qui masque la première vraie erreur après le redémarrage.

Après un incident, je garderais les mesures assez longtemps pour comparer avant, pendant et après. On ajuste ensuite le seuil ou corrige le service, avec un propriétaire et une procédure liée à l’alerte.

Mon premier tableau de bord tiendrait en une page : succès et délai du trajet utilisateur, saturation des trois dépendances principales et âge des dernières données. Si l’appel d’un utilisateur reste notre première détection, les voyants mesurent encore les machines plutôt que le service.