¿Qué puertos puedo monitorizar?

Cualquier puerto TCP del 1 al 65535. Casos habituales: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listeners de bases de datos (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), puertos personalizados de aplicaciones.

¿El monitor comprueba si el servicio está sano o solo disponible?

Solo la disponibilidad: el monitor abre una conexión TCP y comprueba si el demonio la acepta. Sin handshake a nivel de protocolo. Si necesitas comprobaciones específicas de protocolo (por ejemplo, verificación de banner SMTP, respuesta a consulta de base de datos), utiliza una comprobación HTTP (para servicios HTTP) o un agente heartbeat autohospedado.

¿Cuál es el timeout de las comprobaciones de puertos?

Por defecto, 10 segundos. Configurable por monitor. Si la conexión TCP no se establece en la ventana de timeout, la comprobación falla con "connection timeout". Las conexiones long-haul (por ejemplo, comprobando un servidor en Asia desde Europa) pueden requerir timeouts más largos.

¿Puedo monitorizar puertos UDP?

Actualmente no. UDP es sin conexión: no hay equivalente a "connection accepted" para comprobar. Los servicios basados en UDP normalmente requieren probes específicos de protocolo (por ejemplo, consulta DNS en el puerto 53, SNMP get para el 161). Utiliza el monitoreo heartbeat en su lugar.

¿El monitoreo de puertos incluye alertas TLS/SSL?

No: las comprobaciones de puerto son pura disponibilidad TCP. Si necesitas validación de certificado TLS en un puerto, utiliza una comprobación HTTPS incluyendo el puerto en la URL (por ejemplo, https://api.example.com:8443/) que comprueba tanto la disponibilidad como el certificado.

Supervisión de puertos TCP — Bases de datos, correo, servicios

Confirme que los servicios críticos están escuchando, no solo su servidor web. Supervise cualquier puerto TCP en cualquier host.

Más allá de HTTP: monitorizando el resto del stack

La mayoría de los servicios que mantienen el negocio no son servidores web. Las bases de datos escuchan en 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). El correo pasa por los puertos 25, 465, 587, 993, 995. SSH en el 22. Los servidores de juegos en los puertos que elija el editor. Microservicios internos tras el firewall: en lo que configure el equipo de plataforma. Ninguno de ellos habla HTTP. Ninguno lo verás en una herramienta de uptime para webs. Y cada uno, cuando deja de escuchar, arrastra consigo algo crítico.

El monitoreo de puertos tapa este agujero. Añades el host y puerto al monitor, y en cada comprobación se abre una conexión TCP para verificar si el servicio atiende. Si la conexión falla —porque el daemon ha caído, el firewall ha cambiado, el host está caído, o la red entre nosotros y el servicio está dañada— recibes una alerta.

Qué puedes monitorizar

Bases de datos: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Servidores de correo: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Acceso remoto: 22 (SSH), 3389 (RDP), 5900 (VNC).
Transferencia de archivos: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Personalizados o internos: gateways GraphQL, gRPC, colas (RabbitMQ 5672, Kafka 9092), búsqueda (Elasticsearch 9200, Solr 8983), servidores de juegos, dispositivos IoT.

Cómo funciona la comprobación

El monitor abre una conexión TCP en bruto al host:puerto con un timeout de 5 segundos. Si recibe un SYN/ACK, el puerto es accesible y el servicio está escuchando, check activo. Si la conexión es rechazada, hay timeout o no hay ruta, check caído, y se guarda el error de kernel ("connection refused", "operation timed out", "no route to host") — para facilitar el diagnóstico.

El monitor no intenta comunicarse por el protocolo de la aplicación: no envía ninguna petición SQL ni SMTP HELO. Esto mantiene la comprobación rápida y sin efectos secundarios, algo clave cuando monitorizas 100 servicios por minuto. Si necesitas verificación a nivel de aplicación, combina el monitoreo de puertos con heartbeat o un monitor personalizado de API.

Combinando con HTTP y ping

Para cada servicio público, tres monitores aportan una clara escalera de diagnóstico. El ping confirma que el host responde en la red. El monitoreo de puertos indica que el servicio escucha. El monitoreo HTTP / API confirma que el servicio responde correctamente. Cuando algo falla, la capa caída te indica dónde buscar. Si solo falla HTTP, la app se está bloqueando. Si también falla el puerto, es que el daemon ha caído. Si incluso falla el ping, la máquina ha desaparecido o la red está caída.

Configuración

Abre la herramienta, haz clic en "Añadir monitor", selecciona el tipo "Puerto TCP", pega el host (sin protocolo), escribe el número de puerto (1-65535) y fija el intervalo. Guarda. Desde el siguiente ciclo, el monitor abrirá una conexión TCP cada minuto, registrará el round-trip y enviará la alerta al segundo de detectar el cierre de puerto — por Email, Telegram, Slack, Discord o SMS, con las mismas reglas de umbral de confirmación y silencio nocturno.

Preguntas frecuentes

¿Qué puertos puedo monitorizar?
Cualquier puerto TCP del 1 al 65535. Casos habituales: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listeners de bases de datos (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), puertos personalizados de aplicaciones.
¿El monitor comprueba si el servicio está sano o solo disponible?
Solo la disponibilidad: el monitor abre una conexión TCP y comprueba si el demonio la acepta. Sin handshake a nivel de protocolo. Si necesitas comprobaciones específicas de protocolo (por ejemplo, verificación de banner SMTP, respuesta a consulta de base de datos), utiliza una comprobación HTTP (para servicios HTTP) o un agente heartbeat autohospedado.
¿Cuál es el timeout de las comprobaciones de puertos?
Por defecto, 10 segundos. Configurable por monitor. Si la conexión TCP no se establece en la ventana de timeout, la comprobación falla con "connection timeout". Las conexiones long-haul (por ejemplo, comprobando un servidor en Asia desde Europa) pueden requerir timeouts más largos.
¿Puedo monitorizar puertos UDP?
Actualmente no. UDP es sin conexión: no hay equivalente a "connection accepted" para comprobar. Los servicios basados en UDP normalmente requieren probes específicos de protocolo (por ejemplo, consulta DNS en el puerto 53, SNMP get para el 161). Utiliza el monitoreo heartbeat en su lugar.
¿El monitoreo de puertos incluye alertas TLS/SSL?
No: las comprobaciones de puerto son pura disponibilidad TCP. Si necesitas validación de certificado TLS en un puerto, utiliza una comprobación HTTPS incluyendo el puerto en la URL (por ejemplo, https://api.example.com:8443/) que comprueba tanto la disponibilidad como el certificado.

Supervisión de puertos