A saúde do backend é sempre monitorada pela camada de protocolo no mundo do load balancing clássico. O ADC envia uma requisição HTTP ao servidor, recebe 200 OK e adiciona o servidor ao pool. Ou faz um probe TCP e, se a porta estiver aberta, considera-o saudável. Ou talvez faça verificação de conteúdo: 'a resposta contém esta palavra?'
Essa abordagem olha de fora da casca; não olha por dentro. Não enxerga que a ocupação de disco do servidor chegou a 98%, que a RAM caiu para swap e o desempenho desabou, que o ciclo de GC se alongou, que o limite de conexões de banco de dados foi esgotado. O servidor ainda retorna HTTP 200 — mas o usuário experimenta uma espera de segundos para sua requisição.
Pior ainda: o probe de protocolo é considerado externo, não reporta o próprio estado do servidor. O ADC vê apenas o que o probe vê. A pressão de recursos acumulada no servidor ou o ciclo de reinício de um processo crítico não influenciam a decisão de routing.
A ETM Telemetria de Servidor fecha essa lacuna. O agente no servidor transmite continuamente seu próprio estado interno ao ADC. A decisão de routing é tomada não pelo probe de protocolo externo, mas pelos dados ao vivo vindos de dentro.
O TR7 ETM modela a saúde do servidor como entrada viva da camada de routing do ADC. Essa abordagem une a segurança do cliente e a observability do servidor na mesma plataforma.
O agente no servidor mede em tempo real a carga de CPU, o uso de memória, a pressão de swap, a saturação de IO de disco e o throughput das interfaces de rede. Os dados são transmitidos ao ADC em intervalos periódicos — na ordem de segundos; a decisão de routing alimenta-se desses dados atualizados.
São monitorados a saúde dos processos críticos da aplicação, os ciclos de reinício, o tempo de garbage collection, o número de descritores de arquivo abertos, o estado do pool de threads e métricas específicas da aplicação (ex.: limite de conexões de banco de dados). Se a aplicação não está saudável, o tráfego não vai para aquele servidor.
O algoritmo de load balancing do ADC pode funcionar conforme a pontuação de saúde proveniente da telemetria do ETM. Um servidor com CPU alta recebe menos tráfego, um servidor com saturação de IO é retirado de novas conexões, um servidor que caiu para swap é limpo automaticamente do pool.
O mesmo agente ETM usado para a segurança do cliente roda também nos servidores. A equipe de operações usa um único agente, uma única camada de gestão e um único modelo de telemetria. Não é necessário implantar uma ferramenta separada para a observability do backend.
A telemetria de servidor não é apenas observability; é a fonte de dados ao vivo da decisão de routing do ADC.
Número de CPUs, média de carga contínua, percentual de uso instantâneo e estado térmico são medidos em tempo real. Anomalia na carga por núcleo ou queda de desempenho por throttle térmico refletem-se na decisão de routing.
Memória total e disponível, uso de swap, taxa de page fault e atividade do OOM killer são monitorados. Um servidor que caiu para swap pode ser automaticamente colocado em pool de baixa prioridade; um servidor com risco de OOM evidente pode ser retirado do tráfego.
Taxa de ocupação de disco, tempo de espera de IO, número de IOPS, número de requisições em fila e contagem de erros SMART são monitorados. Quando o limiar de ocupação de disco é ultrapassado ou a saturação de IO está alta, o servidor é retirado do tráfego.
São monitorados se os processos críticos definidos estão ou não em execução, o momento do último reinício e o número de ciclos de restart. Uma aplicação que reinicia continuamente é retirada do tráfego; o pool é marcado para intervenção do operador.
Métricas específicas da aplicação no servidor — métrica de runtime da aplicação (tempo de GC, latência do event loop), saturação do limite de conexões de banco de dados, profundidade de fila — podem ser extraídas pelo agente. O ADC pode incluir essas métricas na decisão de routing.
O throughput das interfaces de rede do servidor, a taxa de perda de pacotes, o número de retransmissões e o número de conexões TCP ativas são monitorados. Um servidor com saturação de rede é automaticamente marcado com peso baixo.
São monitorados o período de validade dos certificados TLS no servidor, a integridade de hash dos arquivos de configuração críticos e as mudanças nos repositórios de certificados. Um certificado próximo do vencimento emite alerta ao operador e pode ser incluído na política de routing.
O desvio em relação ao baseline de configuração do servidor é capturado instantaneamente. Alteração de configuração não autorizada, conta de usuário inesperada ou início de novo serviço chegam ao ETM como evento. Esse sinal reflete-se tanto nas decisões de segurança quanto nas de operação.
A telemetria do ETM pode ser convertida em uma pontuação de saúde de 0 a 100 por servidor. O algoritmo de load balancing do ADC (round-robin, least-conn, weighted least-conn) pode usar essa pontuação como peso. Um servidor com pontuação em queda recebe menos tráfego; um servidor que cai abaixo do limiar sai do pool.
Sinais como a velocidade de aumento da ocupação de disco, a tendência de consumo de memória e a frequência de reinício podem ser interpretados de forma preditiva. Quando o servidor ainda não falhou, mas a probabilidade de falhar em breve aumenta, o tráfego é retirado suavemente desse servidor.
A telemetria de servidor é a fonte de dados ao vivo da inteligência de routing do ADC — incluindo integração, escalabilidade e auditoria.
A telemetria flui periodicamente ao control plane do ADC. O algoritmo de load balancing pode funcionar conforme a pontuação do ETM; decisões de routing especiais podem ser acionadas por eventos do ETM. O operador pode vincular as métricas do ETM à linguagem de política sem escrever nenhum custom script.
O health probe ativo baseado em protocolo (HTTP, TCP, Oracle) continua funcionando; a telemetria do ETM adiciona uma camada de 'visão interna' ao lado desse probe. A decisão de routing avalia as duas fontes em conjunto: 'está respondendo?' (probe de protocolo) + 'está saudável?' (ETM).
Quais métricas serão coletadas em qual período pode ser configurado conforme a função do servidor. Para um servidor web, CPU/RAM/IO; para um servidor de banco de dados, o limite de conexões e a query latency; para um servidor de aplicação, GC e pool de threads podem ser prioritários.
O agente no servidor é projetado para uso mínimo de recursos. Funciona também em backends de alto throughput sem causar perda de desempenho. A intensidade de coleta de métricas é configurável.
A telemetria pode ser exportada para plataformas corporativas de monitoramento e observability. Quando se deseja usar o stack de observability padrão da organização em vez da própria interface de gestão do ETM, é fornecido o fluxo de dados.
A telemetria de milhares de servidores pode ser coletada a partir de um único cluster TR7. Em estruturas multi-região, com o Central Management, os inventários de servidores de diferentes regiões são visualizados a partir de um único console.
Quando a saturação do limite de conexões de banco de dados de um servidor de aplicação se aproxima, o ETM transmite isso ao ADC. O ADC reduz gradualmente o peso daquele servidor; novas conexões são redirecionadas a outros servidores. O usuário não vê timeout; o backend respira gradualmente.
Quando a ocupação de disco de um servidor ultrapassa 95% por causa de backup ou acúmulo de log, o ETM gera um evento. O servidor é retirado automaticamente do pool; o operador é sinalizado para intervir. Evita-se que o disco encha por completo e o serviço caia.
Um servidor cujo uso de memória cresce continuamente e que tem alto risco de OOM pode ser colocado em peso baixo pelo ETM antes mesmo de cair. O tráfego é deslocado suavemente a outros servidores; o problema é resolvido antes de virar incident.
Uma validade inferior a 30 dias do certificado TLS no servidor é comunicada ao ETM. Um alerta vai ao operador; até o certificado ser renovado, o servidor pode não receber tráfego crítico ou o alarme pode ser elevado. O risco de erro de certificado surpresa desaparece.
Vamos ver a ETM Telemetria de Servidor ao vivo no seu próprio backend — vamos planejar uma sessão de implantação sobre um grupo piloto de servidores.