Como criar alertas no Prometheus para picos de latência TCP
Descubra como construir métricas compostas no Prometheus para identificar retransmissões de pacotes e degradação de conexões na rede antes que causem falhas.
Resumo
- A latência TCP elevada e as retransmissões silenciosas degradam a performance de sistemas distribuídos antes mesmo de causarem quedas totais.
- O uso do utilitário Node Exporter permite expor métricas cruciais do kernel Linux diretamente para a coleta contínua do Prometheus.
- Expressões PromQL compostas combinam o volume de pacotes enviados com retransmissões ativas para gerar alertas altamente precisos.
- O monitoramento preventivo de janelas de congestionamento evita alarmes falsos causados por picos pontuais de tráfego na infraestrutura.
- A correlação entre perda de pacotes e métricas de aplicação isola gargalos de rede com rapidez em ambientes de produção.
Por que monitorar a latência TCP e retransmissões
Quando uma aplicação distribuída começa a responder lentamente, a culpa costuma recair sobre o banco de dados ou sobre o código da API. No entanto, muitas vezes o verdadeiro gargalo está escondido na camada de transporte da rede, especificamente nas conexões TCP que sofrem com micro-cortes, perda de pacotes e retransmissões silenciosas. Na prática, isso significa que pacotes de dados se perdem no meio do caminho devido a congestionamentos em roteadores ou cabos danificados, forçando o sistema operacional a reenviá-los e gerando um atraso acumulado que arruína a experiência do usuário.
Para quem busca estabilidade operacional, confiar apenas em pings básicos ou verificar se a porta HTTP está aberta é insuficiente. Precisamos olhar para dentro do kernel do sistema operacional e extrair métricas de baixo nível que revelam a saúde real do tráfego. Como vimos ao medir perda de pacotes e jitter no Linux com iperf3, entender o comportamento físico e lógico do tráfego evita surpresas desagradables em horários de pico. O Prometheus surge exatamente como a ferramenta ideal para coletar essas variáveis e disparar avisos automáticos.
Extraindo métricas do kernel com o Node Exporter
O Prometheus por si só não adivinha o que está acontecendo na pilha de rede do Linux; ele precisa de um agente coletor instalado nas máquinas monitoradas. O Node Exporter é o padrão da indústria para essa tarefa, expondo centenas de estatísticas do sistema operacional em um formato que o Prometheus consegue ler facilmente através de requisições HTTP periódicas.
Dentro do ecossistema do Node Exporter, as estatísticas relacionadas ao protocolo TCP vêm diretamente do arquivo virtual /proc/net/snmp do Linux. Esse arquivo agrupa contadores acumulativos desde o momento em que a máquina foi ligada. Para monitorar a degradação, precisamos nos concentrar em métricas como TcpOutSegs, que indica o total de segmentos enviados, e TcpRetransSegs, que mostra quantos desses segmentos precisaram ser reenviados porque o destinatário nunca confirmou o recebimento.
Construindo a métrica composta no Prometheus
Monitorar apenas o número absoluto de retransmissões não funciona bem, pois um servidor com muito tráfego natural terá mais retransmissões do que um servidor ocioso, sem que isso represente um problema grave. A engenharia de confiabilidade exige a criação de métricas compostas, calculando a taxa proporcional de retransmissões em relação ao total de pacotes enviados utilizando a função rate() do PromQL.
A expressão matemática divide a taxa de retransmissões pela taxa de segmentos enviados em uma janela de tempo deslizante, como cinco minutos. Se a proporção ultrapassar um limite seguro, digamos de 3%, sabemos que a rede está degradada. Essa abordagem matemática filtra ruídos passageiros e garante que o alerta só dispare quando houver um impacto real na qualidade da comunicação entre os microsserviços.
Escrevendo a regra de alerta no Prometheus
Com a expressão PromQL validada, o próximo passo é estruturar o arquivo de configuração de alertas do Prometheus, conhecido como Alerting Rules. Esse arquivo define o limiar crítico, o tempo de persistência necessário para evitar falsos positivos e os metadados descritivos que ajudam o operador a entender o problema rapidamente durante uma chamada de emergência.
Abaixo apresentamos um exemplo funcional de regra de alerta configurada em formato YAML para detectar picos anômalos de retransmissão TCP:
groups:- name: tcp_alertsrules:
- alert: AltaTaxaRetransmissaoTCPSeveraexpr: (rate(node_netstat_Tcp_RetransSegs[5m]) / rate(node_netstat_Tcp_OutSegs[5m])) > 0.05for: 2minlabels:severity: criticalannotations:summary: