Monitoramento de load balancer: métricas e alertas

Para a maioria das aplicações corporativas modernas, o load balancer é a primeira parada do tráfego. Ele também é o primeiro ponto onde uma degradação pode se esconder por dias sem que ninguém perceba.

Por ser visto como infraestrutura que simplesmente funciona, costuma ficar fora do radar do time de operações até o momento em que backends saudáveis deixam de receber requisições sem explicação aparente.

Um monitoramento bem desenhado trata o balanceador de carga como um semáforo da experiência do usuário. Latência crescente no handshake SSL, aumento repentino de respostas 5xx ou queda silenciosa na contagem de backends saudáveis são sinais que aparecem no load balancer antes de qualquer reclamação de cliente. Basta saber onde olhar.

Este guia mostra como estruturar um monitoramento de load balancer completo: quais métricas priorizar, como configurar health checks, de onde extrair os dados em cada tipo de balanceador e como correlacionar tudo com a saúde real do serviço.

O que é monitoramento de load balancer

Monitoramento de load balancer é a prática de coletar, analisar e alertar sobre métricas que descrevem como um balanceador de carga distribui tráfego, valida a saúde dos backends e responde às requisições dos clientes. Não se trata apenas de saber se o equipamento está ativo. É entender se ele cumpre sua função de distribuir carga com previsibilidade.

Load balancers atuam em dois níveis bem distintos. Essa diferença muda o tipo de sinal que você consegue extrair.

Layer 4 (transporte): decidem o roteamento com base em IP e porta, sem inspecionar o conteúdo da requisição. AWS NLB, Azure Load Balancer padrão e F5 em modo TCP são exemplos. Métricas típicas envolvem conexões ativas, bytes processados e SNAT.

Layer 7 (aplicação): entendem HTTP/HTTPS, analisam headers e caminhos de URL e podem aplicar regras baseadas em conteúdo. AWS ALB, Azure Application Gateway, NGINX, HAProxy e F5 em modo HTTP se encaixam aqui. Métricas relevantes incluem latência de target, códigos de resposta e erros 5xx.

A diferença importa na hora do diagnóstico. Um load balancer L4 nunca vai reportar um spike de 503, porque simplesmente não sabe o que é 503. Já um L7 pode esconder um gargalo de conexão se você olhar apenas para latência sem correlacionar com taxa de erro.

Por que monitorar o balanceador é crítico para a disponibilidade

Um balanceador funcionando parcialmente é pior do que um balanceador totalmente fora do ar. Quando ele falha por completo, o alerta é imediato e o plano de contingência entra em ação.

Quando falha de forma silenciosa, roteando para backends degradados, descartando conexões em cascata ou demorando para abrir novas conexões, o impacto vira ruído na operação. O NOC acumula tickets sem causa raiz clara e a equipe desgasta.

A maior parte das aplicações corporativas depende do balanceador para garantir alta disponibilidade entre múltiplas instâncias. Se ele começa a classificar backends saudáveis como unhealthy por causa de um health check mal configurado, metade da capacidade da aplicação some sem motivo aparente.

É no balanceador que costumam aparecer os primeiros sinais de problemas downstream. Picos de latência de target indicam banco de dados lento. Crescimento de 5xx aponta deploy quebrado. Queda de RPS sem motivo pode ser perda de pacotes na rede. Monitorar o LB é, na prática, monitorar o pulso da aplicação.

Métricas essenciais para monitoramento de load balancer

As métricas abaixo formam a base de qualquer operação séria. Elas se aplicam, com variações de nomenclatura, a praticamente todos os balanceadores, cloud ou on-premise.

Boas práticas de análise: compare sempre com baseline histórico. Uma aplicação que normalmente roda com P95 de 300 ms vai gerar alertas falsos se o threshold for 100 ms. Um aumento silencioso para 450 ms vai passar batido se o threshold for 1.000 ms. Ferramentas que suportam baseline dinâmico ou anomaly detection reduzem muito o ruído.

Health checks e o comportamento do tráfego

Health check é o mecanismo pelo qual o balanceador decide se um backend pode receber tráfego. Se esse mecanismo estiver mal configurado, todo o resto do monitoramento vira teatro.

A maioria dos balanceadores aceita health checks em dois níveis: TCP (abre e fecha uma conexão na porta) e HTTP/HTTPS (envia um request e valida o código de resposta). TCP é mais leve, porém não detecta aplicação travada. HTTP é mais caro, mas revela problemas internos do backend.

Pontos que costumam quebrar de forma silenciosa:

Timeout curto demais. Um backend lento por 4 segundos vira unhealthy com timeout de 2 segundos, mesmo respondendo corretamente depois. Resultado: o balanceador começa a remover instâncias saudáveis da rotação sob carga.

Path ou status inesperado. Muitos times configuram health check para /. Quando o deploy muda o redirecionamento da raiz, o balanceador passa a receber 301 ou 302, interpreta como falha e tira todo mundo da rotação.

Health check sem dependência real. Um endpoint /health que só retorna “ok” sem checar banco de dados ou cache esconde problemas reais. O backend diz que está saudável enquanto queries falham em produção.

Threshold de transição. Passar de healthy para unhealthy deve exigir mais falhas do que o caminho inverso. Evita flapping durante manutenção ou blip de rede.

Fontes de coleta por plataforma

Cada tipo de balanceador expõe suas métricas de forma diferente. Centralizar tudo em uma única plataforma de monitoramento, em vez de conviver com dashboards isolados, é o que torna o diagnóstico rápido. A arquitetura típica aproveita a monitoração de redes já existente e adiciona as fontes específicas de cada balanceador.

Cloud: AWS, Azure e GCP

AWS ALB e NLB publicam métricas no CloudWatch (RequestCount, TargetResponseTime, HTTPCode_Target_5XX_Count, HealthyHostCount). Access logs opcionais vão para S3 e permitem análises mais profundas. Para quem já tem operação na nuvem, a integração é imediata via monitoramento AWS com coleta direta do CloudWatch.

Azure Load Balancer entrega métricas via Azure Monitor, incluindo DipAvailability (probe de backend), SnatConnectionCount e ByteCount. Logs de fluxo de VNet complementam o cenário. O padrão segue o mesmo do monitoramento Azure usado para os demais recursos.

GCP Cloud Load Balancing expõe métricas via Cloud Monitoring (https/backend_latencies, request_count, backend_request_count), com logs detalhados no Cloud Logging.

On-premise: F5, NGINX e HAProxy

F5 BIG-IP suporta SNMP com MIBs específicas e expõe uma API iControl REST que fornece estatísticas granulares de pool, virtual server e nó. A coleta via SNMP é suficiente para a maioria dos cenários operacionais.

NGINX publica métricas via módulo oficial stub_status (conexões ativas, aceitas e handled). Na versão Plus ou usando nginx-prometheus-exporter, expõe métricas por upstream. Para cenários com múltiplos backends, o exporter Prometheus é o caminho mais direto.

HAProxy oferece stats socket e endpoint HTTP de estatísticas com métricas por frontend, backend e servidor, além de exporter Prometheus nativo na versão 2.0 ou superior. A documentação oficial do HAProxy descreve cada campo.

Alertas e thresholds recomendados

Um alerta útil avisa cedo o suficiente para a equipe agir antes do usuário reclamar. Não pode virar ruído a ponto de ser ignorado. Os thresholds abaixo são pontos de partida. Ajuste ao baseline real da sua operação.

Severidade alta (acionamento imediato):

– Disponibilidade do balanceador abaixo de 100% por mais de 1 minuto
– Backends saudáveis abaixo de N/2 (metade do pool) por mais de 2 minutos
– Taxa de 5xx acima de 1% do tráfego por 3 minutos
– SNAT exhaustion detectada (qualquer ocorrência em ambiente Azure)

Severidade média (abrir ticket, não acordar ninguém):

– Latência P95 acima de 2x o baseline por 5 minutos
– Taxa de 4xx acima do dobro do normal por 10 minutos
– SSL handshake time acima de 500 ms de forma sustentada

Severidade informacional (acompanhar tendência):

– Queda de throughput sem explicação sazonal
– Conexões concorrentes próximas de limites configurados (80% da capacidade)

Alertas cruzados aumentam a precisão. Latência alta combinada com queda de backends saudáveis indica problema real. Latência alta sozinha pode ser apenas deploy pesado.

Integração com observabilidade e a experiência do usuário

O maior ganho do monitoramento de load balancer vem quando ele deixa de viver em silo. Correlacionar métricas do balanceador com traces distribuídos, logs de aplicação e métricas de backend transforma um dashboard isolado em causa raiz objetiva.

Três correlações que valem ouro na rotina de NOC:

Latência de target crescendo com traces mostrando SQL lento: gargalo é de banco de dados, não de rede. A análise de latência ponta a ponta economiza horas de war room.

Queda de RPS no balanceador combinada com verificação externa falhando: clientes reais não estão chegando até o LB. Problema está em DNS, ISP ou WAF. Checagens sintéticas a partir de pontos externos validam o caminho completo do cliente.

Todos os backends healthy e 5xx subindo: problema está no próprio balanceador (SSL, regras de rewrite, limite de conexão). Sinal claro para olhar configuração e não infraestrutura.

Esse tipo de correlação é a espinha dorsal do monitoramento de TI moderno, que trata disponibilidade como resultado de sinais interligados e não como checklist isolado de “tudo verde”.

Checklist operacional e erros comuns

Use esta lista como revisão rápida antes de declarar o monitoramento como implementado:

Checklist mínimo:

– Métricas essenciais (backends saudáveis, latência, 5xx, conexões) coletadas em intervalos de 1 minuto
– Health checks validam dependências reais (DB, cache, serviços externos)
– Access logs ou equivalente armazenados por no mínimo 30 dias
– Alertas com threshold baseado em baseline histórico e não em valores fixos arbitrários
– Dashboards comparam janelas (agora vs. mesma hora ontem vs. mesma hora na semana passada)
– Runbook documentado para cada tipo de alerta do balanceador
– Revisão mensal dos thresholds e do ruído gerado

Erros mais comuns:

– Confiar apenas no “está healthy” do LB sem validar resposta real do endpoint crítico
– Esquecer de monitorar o próprio balanceador (quem monitora o monitor)
– Configurar health check agressivo em backends com startup lento
– Não testar o failover (ele só funciona quando você valida antes)
– Ignorar SSL handshake time, que é o primeiro a degradar em ataque ou saturação de CPU

Referências externas valem a leitura. O capítulo publicado pela equipe de SRE do Google descreve padrões que inspiraram várias arquiteturas corporativas atuais.

Conclusão

O load balancer é simultaneamente um dos componentes mais estratégicos e mais invisíveis da infraestrutura moderna. Sem um monitoramento pensado para expor seus sinais (métricas de backend, health checks significativos, alertas correlacionados com observabilidade), ele se transforma numa caixa preta que só aparece quando o usuário já está reclamando.

A boa notícia é que não há mágica. Basta tratar o balanceador como qualquer outra peça crítica da aplicação, coletar as métricas certas, calibrar thresholds com base em histórico e integrar os dados ao resto da operação de monitoramento. O resultado é uma operação mais previsível, um NOC menos ruidoso e uma experiência do usuário que degrada menos e se recupera mais rápido.

Se sua operação precisa de visibilidade sobre balanceadores de carga em cloud, on-premise ou ambientes híbridos, fale com um especialista OpServices para entender como integrar essa camada ao seu monitoramento existente.