Quali porte posso monitorare?

Qualsiasi porta TCP da 1 a 65535. Casi comuni: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listener dei database (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), porte applicative personalizzate.

Il monitor controlla se il servizio è sano o solo disponibile?

Solo la disponibilità — il monitor apre una connessione TCP e verifica se il demone la accetta. Senza handshake a livello di protocollo. Se hai bisogno di check consapevoli del protocollo (es. verifica banner SMTP, risposta a query di database), usa un check HTTP (per servizi HTTP) oppure un agent heartbeat self-hosted.

Qual è il timeout per i check delle porte?

Di default 10 secondi. Configurabile per ogni monitor. Se la connessione TCP non viene stabilita entro la finestra, il check fallisce con "connection timeout". Le connessioni long-haul (ad esempio controllando un server in Asia dall’Europa) possono richiedere time-out più lunghi.

Posso monitorare porte UDP?

Attualmente no. UDP è connectionless — non esiste un equivalente di "connection accepted" da verificare. I servizi basati su UDP di solito richiedono probe specifici per protocollo (es. query DNS sulla porta 53, SNMP get per 161). Usa il monitoraggio heartbeat invece.

Il monitoraggio delle porte rileva le segnalazioni TLS/SSL?

No — i check della porta verificano solo la disponibilità TCP. Se vuoi la validazione del certificato TLS sulla porta, usa un check HTTPS con la porta nell’URL (es. https://api.example.com:8443/) che controlla sia la disponibilità che il certificato.

Monitoraggio delle porte TCP — Database, posta, servizi

Verifica che i servizi critici siano attivi in ascolto, non solo il tuo server web. Controlla qualsiasi porta TCP su qualsiasi host.

Oltre HTTP: monitoraggio del restante stack

La maggior parte dei servizi che mantengono in vita un business non sono web server. I database ascoltano su 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). La posta viaggia su 25, 465, 587, 993, 995. SSH sulla porta 22. I server di giochi sulle porte scelte dall’editore. I microservizi interni dietro il firewall - su qualsiasi cosa abbia configurato il platform team. Nessuno di questi parla HTTP. Nessuno li vedrai in uno strumento di monitoraggio dell’uptime dei siti web. E ciascuno, quando smette di ascoltare, porta con sé qualcosa di visibile.

Il monitoraggio delle porte colma questa lacuna. Fornisci al monitor un host e una porta, e ad ogni verifica viene aperta una connessione TCP che controlla se il servizio sta ascoltando. Se la connessione fallisce - perché il demone è crashato, il firewall è stato cambiato, l’host è giù, la rete tra noi e il servizio è danneggiata - ricevi un avviso.

Cosa puoi monitorare

Database: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Server di posta: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Accesso remoto: 22 (SSH), 3389 (RDP), 5900 (VNC).
Trasferimento file: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Personalizzati o interni: gateway GraphQL, gRPC, code (RabbitMQ 5672, Kafka 9092), search (Elasticsearch 9200, Solr 8983), server di giochi, dispositivi IoT.

Come funziona il check

Il monitor apre una connessione TCP grezza verso host:porta con un timeout di 5 secondi. Se riceve SYN/ACK - la porta è raggiungibile e il servizio sta ascoltando, check up. Se la connessione viene rifiutata, timeout o nessun percorso - check down, e il risultato salva l’errore del kernel ("connection refused", "operation timed out", "no route to host") - più facile da diagnosticare.

Il monitor non prova a parlare con il protocollo applicativo - non invia query SQL né SMTP HELO. Ciò mantiene il check veloce e senza effetti collaterali, fondamentale quando controlli 100 servizi al minuto. Se hai bisogno di una verifica a livello applicativo, combina il monitoraggio delle porte con heartbeat o un monitor API personalizzato.

Combinare con HTTP e ping

Per ogni servizio pubblico, tre monitor offrono una scala diagnostica chiara. Il ping conferma che l’host è raggiungibile in rete. Il monitor delle porte - il servizio sta ascoltando. Il monitor HTTP / API - il servizio risponde correttamente. Quando qualcosa va giù, lo strato che cade dice subito dove cercare. Solo HTTP è giù - l'applicazione va in crash. Cade anche la porta - è crashato il demone. Va giù anche il ping - la macchina è sparita o la rete è morta.

Configurazione

Apri lo strumento, clicca su "Aggiungi monitor", scegli il tipo "Porta TCP", incolla l’host (senza protocollo), inserisci il numero di porta (1-65535) e imposta l’intervallo. Salva. Dal ciclo successivo il monitor, ogni minuto, apre una connessione TCP, registra il round-trip e invia un allarme nel secondo in cui la porta si chiude - via Email, Telegram, Slack, Discord o SMS, con le stesse regole sui livelli di conferma e sulla silenziosità notturna.

Domande frequenti

Quali porte posso monitorare?
Qualsiasi porta TCP da 1 a 65535. Casi comuni: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listener dei database (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), porte applicative personalizzate.
Il monitor controlla se il servizio è sano o solo disponibile?
Solo la disponibilità — il monitor apre una connessione TCP e verifica se il demone la accetta. Senza handshake a livello di protocollo. Se hai bisogno di check consapevoli del protocollo (es. verifica banner SMTP, risposta a query di database), usa un check HTTP (per servizi HTTP) oppure un agent heartbeat self-hosted.
Qual è il timeout per i check delle porte?
Di default 10 secondi. Configurabile per ogni monitor. Se la connessione TCP non viene stabilita entro la finestra, il check fallisce con "connection timeout". Le connessioni long-haul (ad esempio controllando un server in Asia dall’Europa) possono richiedere time-out più lunghi.
Posso monitorare porte UDP?
Attualmente no. UDP è connectionless — non esiste un equivalente di "connection accepted" da verificare. I servizi basati su UDP di solito richiedono probe specifici per protocollo (es. query DNS sulla porta 53, SNMP get per 161). Usa il monitoraggio heartbeat invece.
Il monitoraggio delle porte rileva le segnalazioni TLS/SSL?
No — i check della porta verificano solo la disponibilità TCP. Se vuoi la validazione del certificato TLS sulla porta, usa un check HTTPS con la porta nell’URL (es. https://api.example.com:8443/) che controlla sia la disponibilità che il certificato.

Monitoraggio porte