Como Configurar um Verificador de Queda para Serviços Atrás do Firewall
A maioria dos verificadores de site fora do ar testa seus serviços a partir de data centers na internet pública. Isso funciona para um site institucional, mas falha assim que o serviço fica atrás de um firewall, em uma VLAN privada ou dentro de um cluster Kubernetes sem IP externo: a sonda nunca chega, e o verificador acusa uma falsa queda ou simplesmente não consegue monitorar o alvo.
A solução não é mexer no firewall — é mudar o verificador de lugar. Este guia explica como um agente local leve elimina esse ponto cego e como configurar sua primeira verificação interna no DownWarning.
Por que verificadores em nuvem ficam cegos para serviços privados
Um serviço com IP privado, dentro de uma VPC sem endpoint público ou exposto apenas como ClusterIP no Kubernetes não tem rota de volta para uma sonda externa. Cada API interna, banco de dados e endpoint entre serviços vira um ponto cego — e esse ponto cego cresce junto com a sua infraestrutura.
O contorno de sempre — abrir uma porta de entrada, atribuir um IP público ou criar um proxy reverso só para o monitoramento — troca um problema de visibilidade por um problema de segurança. Um serviço interno é interno por um motivo. A arquitetura de monitoramento deve se adaptar ao desenho da sua rede, e não o contrário.
Como um agente só de saída muda o jogo
Um verificador baseado em agente inverte a conexão. Um binário pequeno roda dentro da sua rede, verifica os alvos internos localmente e envia os resultados ao DownWarning por uma conexão HTTPS de saída comum. Sem portas de entrada, sem regras de firewall para alterar, sem IP público — para o firewall, é só mais uma requisição HTTPS de saída.
O agente do DownWarning roda em Linux, macOS e Windows (inclusive como serviço do Windows), ou como um pod dentro de um cluster Kubernetes. Ele se autentica com uma chave de API do agente gerada no painel, recebe os monitores atribuídos a ele e se atualiza sozinho quando sai uma nova versão. Se o agente parar de reportar, o painel o marca como offline, então um agente silencioso nunca é confundido com serviços saudáveis.
O que o agente consegue verificar
Um verificador de queda tem uma tarefa bem definida: testar um alvo em intervalos, confirmar que ele responde corretamente e alertar quando não responde. Para alvos internos, o agente suporta três tipos de verificação:
HTTP(S)
Verificações completas de requisição e resposta em APIs e aplicações internas: método HTTP, cabeçalhos personalizados, autenticação, códigos de status esperados e uma palavra-chave que deve (ou não deve) aparecer no corpo da resposta.
Ping
Alcance ICMP para hosts e dispositivos de rede. Útil para infraestrutura, mas um ping bem-sucedido não prova que a aplicação está funcionando — combine com uma verificação HTTP ou de Porta.
Porta
Conectividade TCP para serviços não HTTP, como bancos de dados, Redis, brokers de mensagens e SSH, em que a pergunta certa é "a porta está aceitando conexões?".
Verificações de DNS e o acompanhamento de expiração de certificados SSL rodam a partir das sondas externas do DownWarning, então valem para endpoints acessíveis publicamente, e não para monitores atribuídos a um agente. Se um serviço tiver um endpoint público e um interno, monitore o público externamente para DNS e SSL, e o interno pelo agente.
Configurando sua primeira verificação interna
1. Instale o agente
Crie um agente no painel do DownWarning para obter a chave de API e execute o binário em uma máquina (ou como pod) dentro da rede privada, passando a chave com --api-key, com a variável de ambiente MONITOR_API_KEY ou em um arquivo config.yaml. Um único agente normalmente cobre um segmento de rede inteiro.
2. Crie um monitor para o agente
Escolha HTTP, Ping ou Porta, informe o alvo interno — um IP privado, um hostname interno ou um endereço do cluster como orders.default.svc.cluster.local — e atribua o monitor ao seu agente em vez das sondas externas. Monitores de agente rodam em intervalos de 60 segundos ou mais.
3. Conecte os alertas e valide
Vincule um ou mais contatos de alerta ao monitor e acompanhe os primeiros resultados no painel. Um erro logo na primeira execução geralmente indica problema de DNS ou de roteamento entre o agente e o alvo; o motivo da falha no resultado da verificação mostra qual camada falhou.
Em clusters Kubernetes que aplicam NetworkPolicies, adicione uma política restrita que permita ao namespace do agente alcançar os namespaces das aplicações nas portas monitoradas. Siga o princípio do menor privilégio e teste fora de produção primeiro.
Configurando alertas que as pessoas realmente atendem
Um alerta que chega no lugar errado, na prática, não é alerta. O DownWarning notifica por e-mail, Slack, Microsoft Teams, Telegram, Discord, Google Chat e webhooks — que você pode encaminhar para PagerDuty, Opsgenie ou sua própria automação. Atribua contatos diferentes por monitor, para que o alerta do banco de dados chegue ao time de DBA e o da API interna chegue aos seus responsáveis.
Cada alerta inclui o nome do monitor, o motivo da falha e um link para o incidente, e uma notificação de recuperação é enviada pelos mesmos canais quando o serviço volta. Os alertas disparam na primeira verificação com falha, então escolha o intervalo de acordo com a rapidez com que você precisa saber: um minuto para serviços internos críticos, intervalos maiores para o resto.
Coloque o verificador onde seus serviços estão
Um verificador de queda só funciona se conseguir alcançar o serviço. Para tudo o que está atrás de um firewall, o modelo de sonda externa falha por definição, e expor serviços só para agradar o verificador é a correção errada. Um agente só de saída oferece cobertura HTTP, Ping e Porta para serviços privados e no Kubernetes sem tocar em nenhuma regra de entrada.
Perguntas Frequentes
Um verificador de queda em nuvem consegue monitorar serviços atrás de um firewall?
Não sem expô-los. Sondas externas precisam de uma rota até o alvo, então IPs privados, serviços restritos à VPC e serviços ClusterIP do Kubernetes aparecem como permanentemente fora do ar. Um agente local dentro da rede resolve isso verificando localmente e reportando por conexões de saída.
Preciso abrir alguma porta de entrada no firewall para o agente?
Não. O agente faz apenas conexões HTTPS de saída para o DownWarning. Suas regras de entrada no firewall continuam exatamente como estão.
Quais tipos de verificação funcionam pelo agente?
Verificações HTTP(S), Ping e de Porta. Verificações de DNS e o acompanhamento de expiração de certificados SSL rodam a partir das sondas externas do DownWarning, em endpoints acessíveis publicamente.
O agente local está disponível no plano gratuito?
Sim. O plano gratuito Starter inclui um agente local, então você pode monitorar uma rede privada ou um cluster Kubernetes sem custo. Faça upgrade para Pro ou Scale quando precisar de mais agentes para cobrir outras redes.