Um health check típico envia uma requisição para um endpoint, vê uma resposta 200 e marca o serviço como saudável. Em aplicações modernas, isso não é suficiente. A página inicial da aplicação pode responder enquanto a conexão com o banco de dados está lenta, a camada de cache está quebrada, uma dependência downstream caiu ou o fluxo de login parou de funcionar. Se o balanceador de carga não consegue ver essa diferença, continua roteando tráfego para backends que respondem mas não conseguem fazer trabalho real.
Verificações de etapa única ficam ainda mais aquém para protocolos baseados em sessão. Para FTP, LDAP, Oracle ou protocolos TCP personalizados, ter a porta aberta não significa que o serviço está saudável. Um health check real deve fazer login, enviar um comando, receber a resposta esperada, sair se necessário e validar o conteúdo da resposta. Caso contrário, o serviço parece acessível enquanto operações reais de usuário falham.
A validação de conteúdo fica frágil quando limitada a correspondência de texto simples. Uma API pode sempre retornar a palavra "OK" enquanto o estado de dependência, métrica de latência ou regra de negócio dentro do JSON está falhando. Quando um health check não consegue consultar o significado da resposta, degradações no nível de aplicação são detectadas tarde.
A abordagem correta é abordar os health checks com profundidade de protocolo, cenários multi-etapas, consultas de conteúdo e limiares rise/fall configuráveis. As operações de probe devem correr isoladas do fluxo de tráfego principal para que health checks lentos ou travados não atrasem o tráfego do usuário.
O Monitoramento Ativo de Saúde do TR7 entrega esse modelo: monitora 11 protocolos em uma única configuração, executa cenários multi-etapas, valida o significado do conteúdo com JSONata e mantém na rotação apenas alvos genuinamente saudáveis.
O TR7 transforma o health checking de um controle de protocolo único em um sistema de decisão multi-protocolo, baseado em cenário e com validação de conteúdo.
Verificações TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS e Oracle são todas gerenciadas a partir do mesmo objeto de health check. Dependendo do checkType selecionado, apenas os campos relevantes são mostrados, para que os operadores não sejam sobrecarregados com parâmetros irrelevantes.
Para verificações TCP, UDP e Oracle, fluxos de controle ordenados são construídos usando etapas send, expect, regex e wait. Se qualquer etapa falhar, o probe é marcado como falho e o estado de saúde do backend é atualizado de acordo.
Para verificações HTTP e HTTPS, queries JSONata são usadas para ler o estado real dentro de uma resposta JSON. Um backend não é considerado saudável apenas por retornar 200 — campos como status de dependência, pontuação, latência ou estado de negócio também podem ser verificados.
O número de respostas consecutivas com falha necessárias para marcar um backend como não saudável e o número de respostas consecutivas bem-sucedidas necessárias para trazê-lo de volta são configurados independentemente. Isso impede que flutuações transitórias de rede continuamente ciclem backends dentro e fora de rotação.
O Monitoramento Ativo de Saúde torna diversos tipos de serviço definíveis, testáveis e gerenciáveis com limiares operacionais — tudo no mesmo editor.
O TR7 suporta health checks TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS e Oracle. Os operadores não precisam de ferramentas separadas para um banco de dados Oracle, diretório LDAP, servidor DNS, repositório FTPS ou API HTTP. Os campos relevantes aparecem com base no tipo de protocolo selecionado; campos não relacionados são ocultados. Esse modelo torna o health checking em backends heterogêneos padronizado e gerenciável.
Para verificações TCP, as etapas sendText, expectText, expectRegex e wait podem ser executadas em sequência. Banners SMTP, queries de capacidade IMAP, trocas Redis PING/PONG, respostas MQTT e mensagens de protocolo TCP personalizadas são todas testáveis com esse modelo. Em vez de apenas abrir uma conexão, um diálogo de protocolo real é executado. Se qualquer etapa não produzir o resultado esperado, o backend é marcado como não saudável.
Para verificações UDP, as etapas send, wait, expectText e expectRegex estão disponíveis. Os dados a enviar podem ser definidos em formato texto, hex ou base64, fornecendo flexibilidade para probes de protocolo binário. Para serviços UDP como DNS, NTP, RADIUS, SIP e similares, a resposta de protocolo esperada é validada — não apenas se a porta está aberta. Isso torna os serviços UDP ativamente e significativamente monitoráveis.
Health checks HTTP/HTTPS suportam método, URI, lista de headers personalizados, corpo de requisição e host virtual. Um endpoint de API pode ser verificado com um header de Authorization, corpo JSON ou header Host personalizado. Códigos de status aceitáveis não precisam ser um único valor — 200, 204 ou 304 podem todos ser considerados saudáveis. Esse design aproxima o health checking do uso real da aplicação.
Quando contentCheckMode é definido como jsonata, o corpo da resposta é avaliado como JSON e a expressão JSONata é executada. Status do serviço, resultado de dependência, latência de banco de dados ou uma métrica de negócio podem ser verificados dentro de uma única expressão. Se a expressão produz um resultado verdadeiro, o backend está saudável; um resultado falso o marca como falho. Erros JSONata são registrados para que uma expressão errada ou estrutura de resposta inesperada se torne visível.
Para cenários simples que não requerem JSONata, contentQuery realiza uma busca de texto dentro do corpo da resposta. Strings de marcador como "Welcome", "UP" ou "Service Ready" — ou texto específico da aplicação — podem ser verificados rapidamente. Esse modo oferece uma solução de baixa complexidade para endpoints de saúde simples ou aplicações legadas. Os operadores escolhem entre verificação básica e JSONata com base no cenário.
Verificações LDAP/LDAPS podem testar não apenas o acesso à porta, mas a operação de bind real. Um bind realizado com nome de usuário e senha valida o serviço de diretório no nível de autenticação. Mesmo que a porta esteja aberta, um backend pode ser marcado como não saudável se a fila de bind, autorização ou serviço tiver um problema. Isso fornece visibilidade crítica especialmente para fluxos AAM e de acesso empresarial.
Health checks Oracle suportam detalhes de conexão, nome de usuário, senha e etapas de cenário. SQL é executado via executeCmd e o texto esperado ou contagem mínima de linhas é verificado. Em vez de um simples teste de conexão, acesso real a dados e métricas de negócio podem ser consultados. Essa abordagem torna a questão de disponibilidade de banco de dados significativa do ponto de vista da aplicação.
Os health checks operam em conjunto com intervalo, timeout, limiar, composição de cenário, identidade de instância e controles especializados internos do sistema.
testInterval é configurável de 0,5 a 3.600 segundos; o padrão é 1 segundo. timeout é configurável de 0,01 a 3.600 segundos. Timeout agressivo permite failover mais rápido, mas pode aumentar o risco de falso positivo e deve ser ajustado ao comportamento do serviço.
requiredFailure tem padrão 2; requiredSuccess tem padrão 3. Esses limiares determinam com que rapidez um serviço é removido de rotação e com que cautela é retornado. Ambos os lados do limiar são gerenciados independentemente para filtrar flutuações transitórias.
Um único health check pode combinar múltiplas verificações atômicas usando lógica AND/OR. Isso significa que não apenas um único resultado de probe, mas múltiplas dependências ou etapas de protocolo podem ser avaliadas juntas. A saúde de serviços complexos é modelada de forma mais realista.
O mesmo health check mantém estado separado para cada backend. O ID de instância do health check é diferenciado por verificação e alvo. Isso significa que mesmo quando o mesmo perfil de verificação é aplicado a múltiplos alvos, o histórico de saúde de cada alvo é rastreado independentemente.
A configuração negate inverte a lógica normal de sucesso. Esse modo é usado quando se espera que uma URL específica seja inacessível, quando se espera que uma resposta específica não seja retornada, ou quando se espera que um caminho de serviço permaneça inacessível. Uma resposta bem-sucedida é tratada como falha; uma resposta falha é tratada como sucesso.
Health checks internos do sistema como monitores de gateway e verificações de conexão de IP de cluster podem ser gerados automaticamente. Essas verificações são usadas para monitorar não apenas backends de aplicação, mas também a conectividade e acessibilidade upstream em torno do TR7. O modelo pode ser estendido com tipos de verificação adicionais, como verificações de datacenter no lado GTM.
Uma equipe de e-commerce pode usar uma verificação HTTP com JSONata para verificar não apenas que o serviço de carrinho retorna 200, mas também que a latência do banco de dados e as métricas de disponibilidade estão dentro dos limites. Um backend lento ou com degradação de dependência é automaticamente removido de rotação.
Equipes bancárias podem usar verificações Oracle para ir além de abrir uma conexão e realmente executar queries SQL reais. Se a contagem esperada de linhas ou o resultado da query não for atendido, o backend é marcado como não saudável e o tráfego é direcionado para alvos seguros.
Aplicações governamentais podem verificar que um serviço de diretório está funcionando não apenas no nível de porta, mas por meio de uma operação de bind real. Se a porta está aberta mas a autenticação falha, o sistema trata isso como um problema de saúde.
Equipes de telecomunicações podem executar queries reais de registro para um domínio crítico usando uma verificação DNS. Ter a porta DNS aberta não é suficiente — o resolver deve produzir a resposta esperada para ser considerado saudável.
Baseie suas decisões de tráfego em dados de saúde confiáveis em 11 protocolos, cenários multi-etapas e validação de conteúdo JSONata. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.