Quels ports puis-je surveiller ?

Tous les ports TCP de 1 à 65535. Cas courants : SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listeners de bases de données (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), ports d’applications sur mesure.

Le moniteur vérifie-t-il la santé du service ou seulement sa disponibilité ?

Uniquement la disponibilité — le moniteur ouvre une connexion TCP et vérifie si le démon l’accepte. Pas de handshake côté protocole. Si vous avez besoin de vérifications protocolaires (ex : vérification de la bannière SMTP, réponse à une requête de base de données), utilisez une vérification HTTP (pour les services HTTP) ou un agent heartbeat auto-hébergé.

Quel est le délai d’attente (timeout) pour les vérifications de port ?

Par défaut : 10 secondes. Paramétrable par moniteur. Si la connexion TCP ne s’établit pas dans la fenêtre timeout, la vérification échoue avec « connection timeout ». Les connexions distantes (ex : serveurs en Asie depuis l’Europe) peuvent nécessiter des délais plus longs.

Puis-je surveiller les ports UDP ?

Non, pas pour le moment. UDP est sans connexion — il n’a pas d’équivalent à « connection accepted » à vérifier. Les services sur UDP nécessitent souvent des sondes spécifiques au protocole (ex : requête DNS sur 53, SNMP get sur 161). Utilisez le monitoring heartbeat à la place.

La surveillance de port détecte-t-elle les alertes TLS/SSL ?

Non — les vérifications de ports mesurent uniquement la disponibilité TCP. Si vous souhaitez valider un certificat TLS sur un port, utilisez une vérification HTTPS avec le port dans l’URL (par exemple https://api.example.com:8443/) qui vérifie à la fois la disponibilité et le certificat.

Surveillance des ports TCP — bases de données, messagerie, services

Vérifiez que les services critiques sont à l’écoute — pas seulement votre serveur web. Surveillez n’importe quel port TCP sur n’importe quel hôte.

Au-delà du HTTP : monitoring du reste de la stack

La plupart des services qui font tourner un business ne sont pas des serveurs web. Les bases écoutent sur 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). Les emails passent par les ports 25, 465, 587, 993, 995. SSH sur 22. Les serveurs de jeux utilisent les ports choisis par l’éditeur. Les microservices internes derrière un firewall – sur ce que l’équipe de la plateforme a configuré. Aucun ne parle HTTP. Aucun ne sera visible dans un outil de surveillance de disponibilité de sites web. Et chacun, quand il arrête d’écouter, emporte avec lui quelque chose de visible.

Le monitoring de ports comble cette lacune. Donnez au moniteur un hôte et un port : à chaque vérification, une connexion TCP est ouverte pour vérifier si le service écoute. Si la connexion échoue – parce que le démon est tombé, le firewall a changé, l’hôte est down ou le réseau entre vous et le service est endommagé – vous recevez une alerte.

Ce que vous pouvez surveiller

Bases de données : 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Serveurs de messagerie : 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Accès à distance : 22 (SSH), 3389 (RDP), 5900 (VNC).
Transfert de fichiers : 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Personnalisés ou internes : passerelles GraphQL, gRPC, files d’attente (RabbitMQ 5672, Kafka 9092), moteurs de recherche (Elasticsearch 9200, Solr 8983), serveurs de jeux, appareils IoT.

Comment fonctionne la vérification

Le moniteur ouvre une connexion TCP brute vers host:port avec un timeout de 5 secondes. Si SYN/ACK est reçu – le port est accessible et le service écoute, check up. Si connection refused, timeout ou no route – check down, et l’erreur du noyau est enregistrée ("connection refused", "operation timed out", "no route to host") – diagnostic facilité.

Le moniteur ne tente pas de dialoguer via le protocole applicatif – il n’envoie pas de requête SQL ni de SMTP HELO. Cela garde la vérification rapide et sans effets secondaires, ce qui importe si vous vérifiez 100 services chaque minute. Si vous avez besoin d’une vérification applicative, combinez le monitoring de port avec un heartbeat ou votre propre moniteur d’API.

Combinaison avec HTTP et ping

Pour chaque service public, trois moniteurs offrent une chaîne de diagnostic claire. Le ping confirme que l’hôte répond sur le réseau. Monitor de port : le service écoute. Monitor HTTP / API : le service répond correctement. En cas de panne, la couche défaillante indique instantanément où chercher. HTTP seul tombe – l’application crash. Le port tombe aussi – le démon est KO. Le ping aussi – la machine a disparu ou le réseau est hors service.

Configuration

Ouvrez l’outil, cliquez sur « Ajouter un moniteur », choisissez le type « Port TCP », copiez l’hôte (sans protocole), saisissez le numéro de port (1-65535) et définissez l’intervalle. Enregistrez. Dès le prochain cycle, la vérification TCP s’effectue chaque minute, mesure le temps de round-trip, et alerte dès la fermeture du port : par Email, Telegram, Slack, Discord ou SMS, selon les mêmes règles de seuil de confirmation et de silence nocturne.

Foire aux questions

Quels ports puis-je surveiller ?
Tous les ports TCP de 1 à 65535. Cas courants : SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listeners de bases de données (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), ports d’applications sur mesure.
Le moniteur vérifie-t-il la santé du service ou seulement sa disponibilité ?
Uniquement la disponibilité — le moniteur ouvre une connexion TCP et vérifie si le démon l’accepte. Pas de handshake côté protocole. Si vous avez besoin de vérifications protocolaires (ex : vérification de la bannière SMTP, réponse à une requête de base de données), utilisez une vérification HTTP (pour les services HTTP) ou un agent heartbeat auto-hébergé.
Quel est le délai d’attente (timeout) pour les vérifications de port ?
Par défaut : 10 secondes. Paramétrable par moniteur. Si la connexion TCP ne s’établit pas dans la fenêtre timeout, la vérification échoue avec « connection timeout ». Les connexions distantes (ex : serveurs en Asie depuis l’Europe) peuvent nécessiter des délais plus longs.
Puis-je surveiller les ports UDP ?
Non, pas pour le moment. UDP est sans connexion — il n’a pas d’équivalent à « connection accepted » à vérifier. Les services sur UDP nécessitent souvent des sondes spécifiques au protocole (ex : requête DNS sur 53, SNMP get sur 161). Utilisez le monitoring heartbeat à la place.
La surveillance de port détecte-t-elle les alertes TLS/SSL ?
Non — les vérifications de ports mesurent uniquement la disponibilité TCP. Si vous souhaitez valider un certificat TLS sur un port, utilisez une vérification HTTPS avec le port dans l’URL (par exemple https://api.example.com:8443/) qui vérifie à la fois la disponibilité et le certificat.

Surveillance des ports