O erro mais comum em GTM é gerenciar a saúde do data-centre com uma única flag up/down. Na realidade, um data-centre pode estar alcançável enquanto a aplicação está fora; a aplicação pode responder enquanto o banco de dados não funciona; o link WAN pode estar aberto enquanto o acesso pelo lado da LAN falhou. Um modelo de saúde de flag única não consegue capturar essas distinções.
Em muitas organizações, o vínculo entre health checks e respostas DNS é manual ou fragmentado. Um sistema de monitoramento dispara um alerta, uma equipe de operações roda um script, um registro DNS é atualizado à mão ou uma automação separada assume. Essa cadeia reage lentamente e fica vulnerável a erro humano em momentos críticos.
Cenários complexos são ainda mais difíceis. Condições como "ative o DC1 se ele tem acesso à internet e não está em manutenção; caso contrário, retorne um registro de backup se a saúde da aplicação do DC2 ou o acesso do DC3 forem positivos" geralmente são gerenciadas por meio de arquivos YAML, scripts e dependências manuais. Isso transforma uma decisão de GTM em um labirinto operacional difícil de entender ou auditar.
O flapping é um risco real. Quando um health check falha momentaneamente e o DNS muda imediatamente, o tráfego do usuário é movido para outra região desnecessariamente. Da mesma forma, um sucesso breve pode trazer o tráfego de volta antes que o problema esteja totalmente resolvido. Limiares de sucesso e falha consecutivos mais lógica de preservação de estado são, portanto, essenciais.
Os cenários de health check do TR7 combinam checks de data-centre, aplicação, banco de dados, modo de manutenção e checks customizados em uma única camada de decisão booleana, vinculando as respostas DNS diretamente à saúde real do serviço.
O TR7 avalia decisões de saúde do GTM combinando checks automáticos de data-centre, health checks manuais e lógica de cenário em um modelo unificado.
Checks automáticos por data-centre, checks HTTP/HTTPS/Oracle definidos pelo usuário e resultados de saúde do ADC podem todos ser usados dentro da mesma estrutura de decisão. Isso amarra a saúde de infraestrutura e aplicação a uma única decisão de GTM.
Os cenários são construídos com grupos AND e OR. Anexar `!` a um identificador de health-check nega a condição, de modo que estados como modo de manutenção podem ser usados como condições negativas na mesma decisão.
As relações entre health check, cenário e registro DNS são rastreadas por meio de mapas em estilo de grafo. Quando um estado de saúde muda, apenas os cenários e registros impactados são reavaliados.
Os health checks HTTP e HTTPS podem verificar códigos de status e conteúdo de resposta, não apenas se uma porta está aberta. Expressões JSONata ou content checks simples confirmam que a aplicação está, de fato, retornando uma resposta saudável.
Os Cenários de Health Check do TR7 cobrem uma gama de necessidades de GTM — de checks simples de acesso a decisões multi-camada de aplicação e data-centre.
O TR7 suporta parâmetros como método, URI, corpo, cabeçalhos, códigos de status esperados, verificação de certificado e timeout para checks HTTP e HTTPS. O check, portanto, não mede apenas se uma conexão pode ser estabelecida — também verifica que a aplicação está retornando a resposta correta a partir do endpoint correto, aproximando a decisão GTM do comportamento real da aplicação.
Para endpoints de saúde que retornam JSON, campos específicos podem ser avaliados usando uma expressão JSONata. Uma expressão como `status = "ok"` confirma não apenas que a aplicação responde, mas que ela retorna o estado de saúde esperado. O corpo da resposta é parseado na estrutura apropriada e a expressão é avaliada contra ele. Isso fornece medição de saúde mais confiável para aplicações modernas baseadas em APIs JSON.
Para cenários mais diretos, o corpo da resposta pode ser verificado quanto à presença de uma string específica. Essa abordagem é suficiente para health checks simples de aplicação que não exigem uma expressão JSONata completa. As equipes de operação podem amarrar a decisão de DNS à confirmação de que uma palavra conhecida ou estado fixo aparece na resposta da aplicação, tornando os checks rápidos e fáceis de entender.
Os checks Oracle são configurados por meio de um cenário que inclui passos para estabelecer uma conexão, esperar e executar um comando. Os resultados são avaliados com base em uma contagem esperada de linhas ou em um texto esperado. Isso permite vincular as respostas DNS não apenas à camada de aplicação, mas também à alcançabilidade do banco, reduzindo o ponto cego de "aplicação está up, mas o banco não está funcionando" em aplicações de negócio críticas.
O TR7 pode usar checks `wanAccess`, `lanAccess`, `access`, `internet` e `maintenanceMode` por data-centre. Esses checks representam diferentes estados de acesso e operação de cada data-centre de forma independente. Estados como modo de manutenção podem ser tratados como condições negativas em um cenário, em vez de sinais positivos de saúde, dando às decisões de DNS um casamento mais próximo da realidade operacional.
Os cenários são construídos com estruturas de grupos de condição; condições dentro de um grupo seguem lógica AND, enquanto relações entre grupos podem ser OR ou AND. Anexar `!` a um identificador de health-check inverte a condição, permitindo construções como `dcAccess AND NOT maintenanceMode`. Decisões complexas de GTM podem ser desenhadas sem escrever scripts.
Valores `requiredSuccess` e `requiredFailure` podem ser configurados para health checks. A abordagem padrão conta sucessos ou falhas consecutivos antes de aceitar uma transição de estado. Isso impede que perda momentânea de pacotes, picos breves de latência ou flutuações transitórias de serviço mudem imediatamente a resposta DNS, tornando o comportamento do GTM mais estável.
Os estados de health check podem ser persistidos em um arquivo local e restaurados quando o sistema reinicia. Isso significa que todos os estados de saúde não precisam ser reaprendidos do zero após cada reinicialização. Essa continuidade é especialmente importante em ambientes GTM maiores com muitos cenários e registros, dando às equipes de operação um comportamento mais previsível após uma reinicialização.
Health checks TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS e Oracle estão disponíveis no ecossistema TR7. Coordenar os resultados de saúde do GTM e do ADC permite que as decisões de DNS reflitam o estado real da camada de serviço. Esse amplo suporte de tipos torna possível construir um modelo de saúde não apenas para aplicações web, mas para serviços empresariais multiprotocolo. Cenários TCP send-receive em estilo script também estão disponíveis para necessidades de check customizadas.
Para que os cenários de health check funcionem de forma confiável, formato de identificador, persistência de estado, sequência de gatilhos, controle do nó master e propagação de mudanças devem todos ser claramente gerenciados.
O motor de cenário pode avaliar tipos de health check incluindo static, dcCheck, http, https e oracle. Combinados com a família mais ampla de health check do GTM e do ADC, estados de serviço multiprotocolo podem ser trazidos para a estrutura de decisão — importante para arquiteturas de serviço que não estão limitadas a um único tipo de check HTTP.
Health checks automáticos por data-centre são identificados usando o formato `auto|
Health checks definidos pelo usuário são criados com identificadores únicos. Esses identificadores podem ser referenciados diretamente em condições de cenário, o que significa que o mesmo check HTTP, HTTPS ou Oracle pode ser avaliado em múltiplos cenários GTM.
Quando um estado de saúde muda, o estado de health check relevante é atualizado primeiro. Os cenários vinculados são, então, reavaliados e, se necessário, a configuração dinâmica é regenerada. Esse fluxo garante que as mudanças se propaguem para as respostas DNS de maneira controlada.
Cenários embutidos como `ALWAYS` e `NEVER` estão disponíveis para produzir decisões fixas. Com `ALWAYS`, um registro é sempre considerado elegível; com `NEVER`, obtém-se um comportamento desabilitado. Isso é útil para testes, takedowns temporários ou roteamento incondicional.
Ações de gatilho são executadas apenas no nó master do GTM. Isso impede que a mesma ação seja executada repetidamente por múltiplos nós em um cluster. Para ações como disparo de DR, webhooks ou notificações, esse controle fornece segurança operacional.
Organizações multi-site podem não querer que um data-centre seja considerado up com base em um único caminho de acesso. O TR7 combina diferentes rotas de acesso na mesma decisão DNS usando cenários como `wanAccess OR lanAccess`.
Para aplicações de negócio críticas, a alcançabilidade do data-centre sozinha não basta. O TR7 usa cenários como `dcAccess AND appHC AND dbHC` para incluir o IP relevante na resposta DNS apenas quando tanto a aplicação quanto o banco de dados Oracle estão saudáveis.
Uma equipe de operações pode não querer que um data-centre receba tráfego durante a manutenção, mesmo que esteja tecnicamente alcançável. O TR7 pode remover uma localização em manutenção da resposta DNS usando um cenário como `dcAccess AND NOT maintenanceMode`.
Aplicações modernas podem publicar seu estado de saúde por meio de um endpoint JSON. O TR7 vincula as respostas DNS à saúde real da aplicação combinando um health check HTTPS com uma expressão JSONata como `status = "ok"`.
Combine checks HTTP, HTTPS, Oracle e de data-centre em cenários booleanos. Vamos percorrer uma configuração ao vivo no seu próprio ambiente.