Monitor TCP / Porta
O monitor TCP verifica se um host está aceitando conexões em uma porta específica. É ideal para monitorar serviços que não expõem uma interface HTTP, como bancos de dados, filas de mensagens e servidores de email.
Como funciona
O worker realiza uma conexão TCP pura ao host e porta configurados:
- Tenta abrir uma conexão TCP (TCP handshake)
- Se a conexão for estabelecida com sucesso → UP
- Se a conexão for recusada (connection refused) → DOWN
- Se o timeout for atingido sem resposta → DOWN
O monitor TCP não envia nenhum dado após estabelecer a conexão. Ele apenas verifica se a porta está aberta e aceitando conexões. Não é possível verificar o conteúdo do protocolo (ex: autenticar no banco de dados).
Configuração
Host
O endereço do servidor a ser monitorado. Pode ser:
- Hostname:
db.suaempresa.com.br - IP público:
203.0.113.10
IPs privados (192.168.x.x, 10.x.x.x, 172.16.x.x) não são acessíveis pelo worker do TheAlert, que opera a partir de servidores externos. Para serviços internos, use o monitor Heartbeat.
Porta
O número da porta TCP a ser verificada (1–65535).
Timeout
Tempo máximo aguardando a conexão ser estabelecida. Padrão: 10 segundos.
Estados e mensagens de erro
| Estado | Mensagem | Causa |
|---|---|---|
| UP | — | Conexão estabelecida com sucesso |
| DOWN | Connection refused | Porta fechada ou serviço não escutando |
| DOWN | Connection timeout | Host não respondeu no tempo configurado |
| DOWN | Host not found | DNS não resolve o hostname |
| DOWN | Network unreachable | Erro de rota de rede |
Portas comuns para monitorar
| Serviço | Porta padrão |
|---|---|
| PostgreSQL | 5432 |
| MySQL / MariaDB | 3306 |
| MongoDB | 27017 |
| Redis | 6379 |
| Memcached | 11211 |
| SMTP | 25 / 587 / 465 |
| IMAP | 143 / 993 |
| POP3 | 110 / 995 |
| SSH | 22 |
| FTP | 21 |
| RDP | 3389 |
| Elasticsearch | 9200 |
| RabbitMQ | 5672 |
| Kafka | 9092 |
Exemplos de uso
Monitorar PostgreSQL
| Campo | Valor |
|---|---|
| Nome | Banco de Dados — Produção |
| Host | db.suaempresa.com.br |
| Porta | 5432 |
| Intervalo | 60 segundos |
Monitorar Redis
| Campo | Valor |
|---|---|
| Nome | Redis Cache |
| Host | cache.suaempresa.com.br |
| Porta | 6379 |
| Intervalo | 30 segundos |
Monitorar servidor de email SMTP
| Campo | Valor |
|---|---|
| Nome | SMTP — Porta 587 |
| Host | mail.suaempresa.com.br |
| Porta | 587 |
| Intervalo | 5 minutos |
Diferença entre TCP e HTTP
| Aspecto | TCP | HTTP |
|---|---|---|
| O que verifica | Porta aberta | Resposta HTTP válida |
| Protocolo | TCP puro | HTTP sobre TCP |
| Verifica aplicação | Não | Sim |
| Funciona com qualquer serviço | Sim | Somente HTTP |
Use TCP quando:
- O serviço não tem interface HTTP (banco de dados, cache, etc.)
- Você quer verificar conectividade de rede independente da aplicação
- O serviço HTTP está atrás de um load balancer e você quer monitorar os nós individuais
Use HTTP quando:
- Você quer verificar que a aplicação em si está respondendo
- Precisa validar o conteúdo da resposta
- Quer verificar o status code específico
Boas práticas
Monitore a porta do serviço, não apenas SSH É comum monitorar apenas a porta 22 (SSH) para saber se o servidor está "vivo". Mas um servidor pode estar acessível via SSH e com o PostgreSQL parado. Monitore a porta do serviço real.
Combine TCP com HTTP Para aplicações críticas, use monitores em paralelo:
- TCP na porta do banco de dados
- HTTP no endpoint de health check da aplicação
Isso permite distinguir se o problema é na infraestrutura (banco caiu) ou na aplicação (banco ok, app com bug).
Atenção a firewalls Se o check TCP falhar inesperadamente, verifique se o firewall do servidor permite conexões da internet na porta monitorada. Muitos DBs são intencionalmente bloqueados externamente — nesse caso, use Heartbeat.