La surveillance des ports détecte les pannes silencieuses en vérifiant directement les services situés derrière votre site : bases de données, caches, files de messages, relais de messagerie et points de transfert de fichiers. Les checks HTTP ne voient que ce que renvoie le front-end, et un front-end peut continuer à servir des pages en cache ou un endpoint de santé superficiel bien après la défaillance d'une dépendance. Surveiller les ports TCP et UDP, ainsi que les temps de connexion, révèle ces pannes des minutes, voire des heures, avant que les utilisateurs ou les moniteurs HTTP ne s'en aperçoivent.
Pourquoi les checks HTTP restent au vert pendant de vraies pannes
Un moniteur HTTP pose une seule question : cette URL a-t-elle renvoyé la réponse attendue dans les délais ? La réponse peut être « oui » alors que le système est déjà défaillant :
- Réponses en cache. Un CDN ou un reverse proxy sert des pages obsolètes pendant que le port PostgreSQL ou Redis derrière l'origine refuse les connexions.
- Endpoints de santé superficiels. Une route
/healthqui renvoie 200 sans interroger la base de données prouve seulement que le processus web est vivant. - Services sans interface HTTP. Workers en arrière-plan, brokers de messages, relais SMTP et serveurs SFTP peuvent tomber complètement sans modifier la moindre réponse web.
- Nœuds redondants. Un réplica ou un nœud de basculement peut tomber pendant que le primaire continue de servir le trafic, ce qui supprime discrètement votre marge de sécurité.
Dans chaque cas, la couche visible par l'utilisateur semble normale : personne n'est alerté avant l'expiration du cache ou la chute du primaire sans secours.
Les signaux que la surveillance des ports capte plus tôt
Des ports de dépendances qui s'éteignent
Un check TCP sur les ports 5432, 6379, 5672 ou 25 confirme que le service accepte les connexions, indépendamment de la couche web. Lorsqu'une base de données ou un broker cesse d'écouter, le check de port échoue à l'exécution suivante, généralement dans un intervalle de 30 à 60 secondes.
Un temps de connexion TCP qui augmente
Lorsque le backlog d'acceptation ou la file SYN d'un serveur se remplit, la poignée de main TCP ralentit avant d'échouer. Un temps de connexion qui passe d'une référence de 5 ms à 200 ms ou plus précède souvent les timeouts HTTP de plusieurs minutes. Alerter sur un écart durable, par exemple trois checks consécutifs au-dessus de trois fois la référence, permet de repérer la saturation tant qu'il reste du temps pour monter en charge ou délester le trafic.
Dérive de configuration et de pare-feu
Une modification d'un security group ou d'une règle de pare-feu peut fermer un port non HTTP dont dépendent des partenaires ou des systèmes internes. Comparer l'état des ports à une référence connue signale la fermeture immédiatement, et révèle aussi les services inattendus apparaissant sur des ports censés être fermés.
Chronologie réaliste d'une panne silencieuse
Prenons une stack e-commerce avec un CDN en frontal, une couche applicative, PostgreSQL et une file de tâches basée sur Redis.
| Heure | Événement | Moniteur HTTP | Moniteur de ports |
|---|---|---|---|
| 09:00 | Redis commence à saturer en mémoire | 200 OK | Le temps de connexion passe de 4 ms à 90 ms |
| 09:12 | Redis n'accepte plus de connexions | 200 OK (pages en cache) | Échec du port 6379, alerte envoyée |
| 09:15 | Les tâches de confirmation de commande s'accumulent | 200 OK | Toujours en échec |
| 09:40 | Expiration du TTL du cache, erreurs au paiement | Erreurs 502 | Déjà en cours d'investigation |
Le moniteur de ports a offert à l'équipe environ 28 minutes d'avance et a pointé directement vers Redis.
Ce que les checks de ports ne disent pas
Un port ouvert signifie que le service accepte les connexions ; cela ne garantit pas que les requêtes renvoient des données correctes, que les connexions utilisateur fonctionnent ou que le paiement aboutit. Une base de données peut accepter des connexions TCP alors que chaque requête expire sur un verrou. La validation spécifique au protocole et l'identification des services réduisent cet écart, sans remplacer les checks au niveau applicatif.
L'approche pragmatique consiste à superposer les couches :
- Checks de ports sur chaque dépendance critique, y compris les réplicas et les services non HTTP.
- Checks HTTP et API avec validation du contenu ou du statut pour les parcours utilisateurs.
- Endpoints de santé approfondis qui sollicitent réellement les connexions à la base de données et au cache.
- Références de temps de connexion avec des alertes sur les dérives durables, pas sur les pics isolés.
Pour approfondir le fonctionnement des checks, consultez notre guide sur le fonctionnement de la surveillance des ports.
Une mise en place sans bruit d'alertes
La surveillance des ports UpScanX exécute des checks TCP et UDP depuis plus de 15 emplacements dans le monde, suit le temps de connexion et la latence de réponse, identifie les services avec détection de version et signale les changements d'état par rapport à vos références de configuration. Les alertes sont envoyées par e-mail, Slack, Telegram, Microsoft Teams ou webhook.
Pour que les alertes restent fiables, faites confirmer une panne depuis au moins deux emplacements avant d'alerter, et distinguez les ports publics des ports internes qui ne doivent être accessibles qu'au sein de votre réseau.
Points clés à retenir
- Les checks HTTP voient le front-end ; les checks de ports voient les dépendances qui tombent en premier, en silence.
- Un temps de connexion TCP en hausse est un signe avant-coureur de saturation du backlog.
- Surveillez les ports des réplicas, des workers, de la messagerie et du SFTP, pas seulement le service web principal.
- Les checks de ports confirment la disponibilité, pas l'exactitude : combinez-les avec des checks HTTP et des checks de santé approfondis.