Que portas posso monitorizar?

Qualquer porta TCP de 1 a 65535. Casos comuns: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listeners de base de dados (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), portas de aplicações personalizadas.

O monitor verifica se o serviço está saudável ou apenas disponível?

Apenas disponibilidade — o monitor abre uma ligação TCP e verifica se é aceite pelo daemon. Sem handshake ao nível do protocolo. Se precisares de verificações conscientes do protocolo (por exemplo, verificação do banner SMTP, resposta a uma query de base de dados), usa um check HTTP (para serviços HTTP) ou um agente heartbeat alojado por ti.

Qual é o timeout das verificações de porta?

Por defeito 10 segundos. Configurável por monitor. Se a ligação TCP não for estabelecida no tempo de timeout, a verificação falha com "connection timeout". Ligações long-haul (por exemplo, verificar um servidor na Ásia a partir da Europa) podem exigir timeouts maiores.

Posso monitorizar portas UDP?

De momento não. UDP não é baseado em ligação — não há equivalente a "connection accepted" para verificar. Serviços baseados em UDP tipicamente requerem probes específicas do protocolo (por exemplo, consulta DNS para a porta 53, SNMP get para 161). Usa a monitorização heartbeat em alternativa.

A monitorização de portas verifica avisos TLS/SSL?

Não — as verificações de porta são puro TCP availability. Se pretendes validação de certificado TLS na porta, usa uma verificação HTTPS com a porta no URL (por ex. https://api.example.com:8443/) que faz tanto a disponibilidade como a verificação do certificado.

Monitoramento de portas TCP — bancos de dados, e-mail, serviços

Confirme que serviços críticos estão ativos — não apenas seu servidor web. Monitore qualquer porta TCP em qualquer host.

Para além do HTTP: monitorização do resto da stack

A maioria dos serviços que mantêm o negócio não são servidores web. As bases de dados escutam em 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis). O correio passa por 25, 465, 587, 993, 995. SSH no 22. Servidores de jogos nas portas escolhidas pelo editor. Microserviços internos atrás do firewall — em tudo o que a equipa de plataforma configurou. Nenhum destes fala HTTP. Nenhum vais ver numa ferramenta de uptime de websites. E cada um, quando deixa de ouvir, leva consigo algo visível.

A monitorização de portas tapa essa lacuna. Dás ao monitor o host e a porta, e a cada verificação é aberta uma ligação TCP para verificar se o serviço está a escutar. Se a ligação falhar — porque o daemon caiu, o firewall mudou, o host está em baixo, ou a rede entre nós e o serviço está avariada — recebes um alerta.

O que podes monitorizar

Bases de dados: 5432 (Postgres), 3306 (MySQL/MariaDB), 1433 (SQL Server), 27017 (MongoDB), 6379 (Redis), 9042 (Cassandra), 11211 (Memcached).
Servidores de email: 25 (SMTP), 465 (SMTPS), 587 (submission), 110 (POP3), 143 (IMAP), 993 (IMAPS), 995 (POP3S).
Acesso remoto: 22 (SSH), 3389 (RDP), 5900 (VNC).
Transferência de ficheiros: 21 (FTP), 990 (FTPS), 445 (SMB), 2049 (NFS).
Customizados ou internos: gateways GraphQL, gRPC, filas (RabbitMQ 5672, Kafka 9092), pesquisa (Elasticsearch 9200, Solr 8983), servidores de jogos, dispositivos IoT.

Como funciona a verificação

O monitor abre uma ligação TCP bruta para host:porta com um timeout de 5 segundos. Se receber um SYN/ACK de volta — a porta está acessível e o serviço está a escutar, check up. Se retornar connection refused, timeout ou no route — check down, e no resultado é gravado o erro do kernel ("connection refused", "operation timed out", "no route to host") — o que torna o diagnóstico mais fácil.

O monitor não tenta falar através do protocolo da aplicação — não envia pedidos SQL nem SMTP HELO. Isto mantém a verificação rápida e sem efeitos colaterais, o que conta quando verificas 100 serviços por minuto. Se precisares de verificação ao nível da aplicação, combina a monitorização da porta com heartbeat ou o teu próprio monitor API.

Combinação com HTTP e ping

Para cada serviço público, três monitores dão uma escada de diagnóstico limpa. O ping confirma que o host está vivo na rede. A monitorização da porta — o serviço está a escutar. A monitorização HTTP / API — o serviço responde corretamente. Quando algo falha, a camada que falha indica logo onde procurar. Se só o HTTP falhar — a aplicação crashou. Se a porta também cair — o daemon caiu. Se o ping falhar — a máquina desapareceu ou a rede caiu.

Configuração

Abre a ferramenta, clica em "Adicionar monitor", escolhe o tipo "TCP port", cola o host (sem protocolo), introduz o número da porta (1-65535) e define o intervalo. Guarda. A partir do próximo ciclo o monitor abre uma ligação TCP por minuto, regista o round-trip, e alerta no segundo do encerramento da porta — por Email, Telegram, Slack, Discord ou SMS, com as mesmas regras de confirmação e silêncio noturno.

Perguntas frequentes

Que portas posso monitorizar?
Qualquer porta TCP de 1 a 65535. Casos comuns: SMTP (25/587/465), POP3 (110/995), IMAP (143/993), listeners de base de dados (PostgreSQL 5432, MySQL 3306, Redis 6379, MongoDB 27017), SSH (22), FTP (21), portas de aplicações personalizadas.
O monitor verifica se o serviço está saudável ou apenas disponível?
Apenas disponibilidade — o monitor abre uma ligação TCP e verifica se é aceite pelo daemon. Sem handshake ao nível do protocolo. Se precisares de verificações conscientes do protocolo (por exemplo, verificação do banner SMTP, resposta a uma query de base de dados), usa um check HTTP (para serviços HTTP) ou um agente heartbeat alojado por ti.
Qual é o timeout das verificações de porta?
Por defeito 10 segundos. Configurável por monitor. Se a ligação TCP não for estabelecida no tempo de timeout, a verificação falha com "connection timeout". Ligações long-haul (por exemplo, verificar um servidor na Ásia a partir da Europa) podem exigir timeouts maiores.
Posso monitorizar portas UDP?
De momento não. UDP não é baseado em ligação — não há equivalente a "connection accepted" para verificar. Serviços baseados em UDP tipicamente requerem probes específicas do protocolo (por exemplo, consulta DNS para a porta 53, SNMP get para 161). Usa a monitorização heartbeat em alternativa.
A monitorização de portas verifica avisos TLS/SSL?
Não — as verificações de porta são puro TCP availability. Se pretendes validação de certificado TLS na porta, usa uma verificação HTTPS com a porta no URL (por ex. https://api.example.com:8443/) que faz tanto a disponibilidade como a verificação do certificado.

Monitoramento de portas