200 OK geralmente mostra que um serviço respondeu — não que está saudável.
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.
Nossa abordagem
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.
Um único modelo de configuração cobre 11 tipos de protocolo
Verificações TCP, TCPS, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS, SMTP, SMTPS 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.
Cenários multi-etapas simulam comportamento real de protocolo
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.
JSONata valida o corpo de resposta no nível semântico
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.
Limiares rise e fall filtram comportamento de flapping
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.
Capacidades
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.
11 tipos de protocolo gerenciados em uma única tela de health check
O TR7 suporta health checks TCP, TCPS, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS, SMTP, SMTPS 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.
Histórico de saúde — «porque é que aquele servidor caiu na terça às 03:40?»
O estado de saúde não é apenas mantido em memória: é conservado, por isso as transições de estado de cada backend podem ser lidas mais tarde, com aquilo que a sonda realmente recebeu na altura. Uma plataforma que guarda a saúde só em memória não consegue responder a essa pergunta — a evidência foi sobrescrita pela verificação bem-sucedida seguinte. E a verificação TCP é uma verificação a sério: uma cadeia enviar/esperar/repetir com cargas em hex e Base64, por isso uma porta que responde mas já não fala o protocolo é encontrada antes dos seus utilizadores.
A linguagem de cenário TCP suporta verificações de banner, comando e regex
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.
Cenários UDP funcionam com payloads de texto, hex e base64
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.
Verificações HTTP e HTTPS são configuradas como requisições reais de cliente
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.
Queries JSONata validam o significado real de uma resposta de serviç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.
A verificação básica de conteúdo fornece validação de marcador rápida e simples
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.
Testes de bind LDAP e LDAPS medem a saúde da autenticação
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.
Verificações Oracle validam comandos SQL e contagens esperadas de linhas
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.
SMTP EHLO com STARTTLS — o caminho de correio é verificado como é realmente usado
A verificação SMTP fala EHLO e negoceia STARTTLS, pelo que um relay de correio que responde na porta 25 mas falha a atualização para TLS é marcado como indisponível em vez de ser reportado como saudável. Uma ligação TCP simples não vê essa falha; esta verificação vê.
Profundidade operacional
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.
Configuração de intervalo e timeout
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.
Limiares rise e fall
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.
Composição de condição multi-estágio
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.
Estado de instância por alvo
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.
Modo de expectativa negativa
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.
Verificações especializadas internas do sistema
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.
Quando usar
Medindo a saúde real de um serviço de carrinho de e-commerce
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.
Verificações funcionais em um cluster Oracle bancário
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.
Validação de bind LDAPS em um portal governamental
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.
Queries reais de registro em uma fazenda DNS de telecomunicações
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.
Perguntas frequentes
Quais protocolos são cobertos pelo monitoramento ativo de saúde?
Como a validação de conteúdo JSONata funciona?
Como os health checks afetam o fluxo de tráfego principal?
O que os limiares rise e fall fazem?
Uma verificação LDAP testa apenas o acesso à porta?
Quando o modo de expectativa negativa é usado?
Verifique se seus backends estão genuinamente saudáveis
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.