Como configurar uma verificação de Porta TCP (guia completo)

Url / Domínio / IP

Digite o alvo como host:porta, por exemplo example.com:22 para SSH ou example.com:465 para SMTPS - a porta faz parte do endereço, não é um campo separado. Você também pode dar ao monitor um nome curto, que é o que aparece em alertas, relatórios e quaisquer widgets de status.

Configurações Principais

Não há captura de tela dessa seção especificamente para o tipo de verificação Port, mas ela usa o mesmo grupo de Configurações Principais que todo outro tipo de verificação, então todo controle abaixo é exatamente o que você vai ver no formulário:

• Monitoramento ativado: pausa ou retoma a verificação sem apagá-la.
• Agenda por intervalo / Agenda cron: rode em um intervalo fixo (o controle deslizante vai de 1 minuto até 24 horas) ou em uma expressão cron para um padrão que a escala de intervalo não consegue expressar.
• Tags: rótulos separados por vírgula para filtrar e buscar na sua lista de monitores. Só organizacional - não afetam a própria verificação.
• Log Completo: salva todo resultado individual de verificação em vez de agrupar resultados idênticos repetidos.
• Estatísticas Abertas: torna a página de estatísticas e log desse monitor compartilhável com pessoas que não estão logadas na sua conta.
• Monitores anexados - DNSBL: roda uma verificação de blacklist de DNS contra o mesmo domínio na própria agenda de 12 horas, independente do intervalo da verificação de porta. Um estado ruim detectado notifica de acordo com as inscrições de Fora do Ar/Repetir em Inscrições de Alerta.
• Monitores anexados - Web Risk: roda uma verificação de malware/phishing Google Web Risk contra o domínio, também na própria agenda. Restrito por pacote.

Configuração da Requisição

• Conectar via TLS/SSL: desligado por padrão, o que significa que a verificação disca um socket TCP simples. Ative para envolver a conexão em um handshake TLS antes de ler a resposta - a escolha certa para serviços no estilo HTTPS, SMTPS, ou um listener de banco de dados que exige TLS. Ativar isso também revela um subgrupo de Handshake TLS em Validação de Resposta (abaixo) com políticas de validação de certificado. A nota na tela para essa chave menciona "um serviço TCP (ou UDP) simples", mas não há nenhum seletor de protocolo em lugar nenhum desse formulário: toda verificação de Porta disca TCP. Se você precisa monitorar um serviço UDP, esse tipo de verificação atualmente não expõe essa opção.
• Seleção de Servidor DNS: o mesmo menu suspenso usado em outros tipos de verificação. Servidores DNS padrão nas localidades resolve o host por meio dos próprios servidores DNS públicos de cada localidade de monitoramento, seguindo as regulamentações locais. DNS Público resolve por meio de um pool de DNS público, com uma lista opcional de resolvedores excluídos. Personalizado permite fornecer os seus próprios IPs de servidor DNS, um por linha. Na conta de onde veio essa captura de tela, Público e Personalizado estão os dois trancados atrás de um banner de upgrade, o que é um limite de pacote, não um recurso ausente.

Validação de Resposta

Por padrão, uma verificação tem sucesso quando a conexão se completa - e, quando o TLS/SSL está ativado, quando o handshake também se completa. Os controles aqui permitem exigir mais do que isso:

• Padrão de Resposta: uma expressão regular opcional que a resposta precisa combinar. Quando definido, a verificação lê até 1 MB da resposta TCP (ou TLS, quando ativado) e falha quando o padrão não combina; deixe vazio para julgar só a conexão. (Documentações mais antigas chamavam isso de "padrão de busca de resposta TCP"; a interface atual rotula como Padrão de Resposta.) Como só o primeiro 1 MB é lido, coloque o texto que você está combinando perto do início do que o serviço envia - um banner ou linha de saudação funciona bem; conteúdo que o serviço envia mais tarde em uma resposta longa não vai ser visto.
• Handshake TLS (só visível quando Conectar via TLS/SSL está ativado): quatro chaves independentes julgando o próprio handshake. Exigir cadeia de certificado SSL válida falha a verificação em um certificado vencido, autoassinado, com nome incompatível, ou mal encadeado. Exigir protocolo TLS forte (1.2 ou superior) falha um servidor que só oferece TLS 1.0/1.1 ou SSL. Bloquear cifras fracas (128 bits ou menos) falha a verificação quando a suíte de cifra negociada é de 128 bits ou mais fraca. Verificar revogação de certificado SSL faz uma consulta online de CRL/OCSP durante o handshake e falha em um certificado revogado; é um direito de pacote separado dos outros três.
• Validação de IPs Esperados: ative isso para exigir adicionalmente que o DNS resolva o seu host para um entre uma lista de endereços IP que você especifica, um por linha. Se o host começar a resolver para outro lugar - sequestro de DNS, um registro desatualizado, uma migração que você esqueceu de atualizar aqui - a verificação falha mesmo que o novo endereço ainda responda.

Inscrições de Alerta

• Inscrever todos os contatos nos eventos No Ar/Fora do Ar: inscreve todo contato da sua conta tanto em alertas de No Ar quanto de Fora do Ar de uma vez.
• Chips Fora do Ar / No Ar / Repetir por contato: Fora do Ar dispara em uma transição para um estado de falha, No Ar dispara na recuperação, e Repetir reenvia a notificação de Fora do Ar em uma agenda enquanto o monitor continuar fora do ar.
• Buscar contatos: filtra a lista por nome ou endereço.

Inscrições de Relatório

• Inscrever todos os contatos nos relatórios Semanal/Mensal: inscreve todo contato nas duas cadências de uma vez.
• Chips Diário / Semanal / Mensal por contato: escolha qual e-mail recorrente de resumo de uptime cada contato recebe, separado dos alertas em tempo real acima.

Localidades de Monitoramento

• Árvore de localidades: escolha quais localidades de monitoramento rodam essa verificação, por continente, país ou todo o mundo; "Copiar localidades de outra tarefa" clona o conjunto de um monitor existente.
• Estratégia de reverificação: como uma mudança de estado é confirmada. O padrão é uma votação por maioria entre as localidades de reverificação; as alternativas são um número específico confirmando Fora do Ar (controle deslizante de 1 a 7, correspondendo ao tamanho do pool de reverificação), nenhuma reverificação, concordância total entre todas as localidades de reverificação, ou concordância total para Fora do Ar enquanto No Ar só precisa de maioria.
• Se as localidades selecionadas estiverem indisponíveis: "Somente localidades selecionadas" (padrão) espera que uma localidade escolhida volte; "Localidades mais próximas" roda de novo a partir das disponíveis mais próximas; "Qualquer localidade" recorre a qualquer lugar disponível no mundo todo.

Exemplo prático

Monitorando um relay de e-mail SMTPS na porta 465: defina Url / Domínio / IP para mail.example.com:465, ative Conectar via TLS/SSL, e ative Exigir cadeia de certificado SSL válida mais Exigir protocolo TLS forte em Handshake TLS, para que um certificado vencendo ou rebaixado alerte você antes dos clientes perceberem e-mails devolvidos. Deixe o Padrão de Resposta vazio a menos que o serviço envie um banner reconhecível que você queira confirmar. Escolha três ou quatro Localidades de Monitoramento espalhadas por regiões, mantenha a Estratégia de reverificação padrão de votação por maioria, inscreva o seu contato de operações em Fora do Ar e No Ar com Repetir ativado, e adicione uma inscrição de relatório Semanal para um resumo recorrente de uptime.

Solução de problemas

• Nenhuma opção de UDP: apesar de a dica da chave Conectar via TLS/SSL mencionar UDP, esse formulário sempre abre uma conexão TCP. Se o seu serviço alvo é só UDP, uma verificação de Porta não é a ferramenta certa para ele hoje.
• Porta acessível mas a verificação ainda falha com TLS ativado: verifique as chaves de Handshake TLS uma de cada vez. Um certificado que é tecnicamente válido mas autoassinado, ou um servidor ainda oferecendo TLS 1.0/1.1, vai falhar em Exigir cadeia de certificado SSL válida ou Exigir protocolo TLS forte respectivamente, mesmo que uma conexão simples tivesse sucesso.
• O Padrão de Resposta nunca combina: lembre que só o primeiro 1 MB da resposta é lido. Um padrão que só aparece bem no fundo de uma resposta longa, ou um serviço que envia uma carga grande antes do texto que você está combinando, nunca vai combinar - mantenha o padrão em algo que o serviço envia cedo.
• Porta bloqueada no firewall, não no serviço: uma verificação que falha mesmo com o serviço funcionando bem localmente costuma ser uma regra de grupo de segurança ou firewall bloqueando aquela porta específica das localidades de monitoramento da HostTracker, não um problema do serviço - confirme que a porta está aberta para tráfego externo, não só que o processo está rodando.
• IPs Esperados fica desatualizado depois de uma migração: se você está usando a Validação de IPs Esperados e depois move o serviço para um novo host ou IP, atualize a lista - senão você vai ter Fora do Ar falsos mesmo com o serviço acessível no novo endereço.

Relacionados

• Monitoramento de Disponibilidade Distribuído - a página de produto cobrindo verificações de Porta TCP.
• Verificação de Porta Gratuita - teste um par host:porta uma vez, instantaneamente, sem criar um monitor.
• Verificação de Ping: Guia Completo de Configuração - a verificação de acessibilidade mais simples quando você não precisa testar uma porta ou serviço específico.
• Modo de Asserções: Referência Completa de Validação de Resposta - a linguagem de regras de validação de resposta usada em outros tipos de verificação.
• Como verificar se uma porta está aberta - a versão avulsa dessa verificação, mais os comandos nc e nmap por trás dela.
• Todos os guias de monitoramento - o guia de configuração para todo outro tipo de verificação.