Marcio Cunha

Como criar alertas preditivos no Prometheus usando PromQL

Aprenda a antecipar quedas de infraestrutura criando regras de alerta preditivas no Prometheus baseadas em taxas de variação e na função predict_linear do PromQL.

Marcio Cunha•7 min
Também disponível em:EnglishEspañol
Resumo
  • A função predict_linear do PromQL estima o valor futuro de uma métrica extrapolando tendências passadas com base em regressão linear simples.
  • O uso do operador deriv calcula a taxa de variação por segundo de um contador ou medidor, ajudando a identificar acelerações bruscas no consumo de recursos.
  • Alertas reativos tradicionais avisam apenas quando o problema já aconteceu, enquanto o monitoramento preditivo garante tempo de resposta operacional.
  • A escolha correta da janela de tempo nos seletores de intervalo evita falsos positivos causados por ruídos de curto prazo e flutuações normais.
  • Combinar métricas de esgotamento de disco com sistemas como alertas preditivos de falhas em disco com SMART protege o ambiente contra indisponibilidades.

Por que o monitoramento tradicional de infraestrutura falha antes de um incidente?

Na engenharia de confiabilidade de sistemas, costumamos depender de alertas reativos. Isso significa que recebemos uma mensagem irritante no celular apenas quando o disco rígido atinge 90% de ocupação ou quando a memória RAM está prestes a estourar. Na prática, essa abordagem cria uma corrida contra o tempo, exigindo que o operador atue sob forte pressão para evitar uma indisponibilidade total dos serviços. O grande problema desse modelo é que ele ignora a velocidade com que o recurso está sendo consumido, tratando um servidor que enche lentamente da mesma forma que um servidor prestes a travar em poucos minutos.

Para resolver essa lacuna operacional, precisamos mudar a nossa mentalidade de monitoramento para o modelo preditivo. Em vez de perguntar se o sistema está cheio agora, passamos a calcular quando ele vai ficar cheio. Se um sistema operacional consome 1% de espaço em disco por dia, atingir o limite crítico é um cenário distante e administrável. No entanto, se esse mesmo consumo passa a ser de 5% por hora, o colapso é iminente. O Prometheus, ferramenta padrão da indústria para coleta de métricas, possui um ecossistema poderoso de funções matemáticas conhecido como PromQL que nos permite enxergar o futuro com base em tendências históricas.

Quando combinamos essa capacidade de previsão com ferramentas complementares, como a centralização de alertas de rede com Syslog e Prometheus, criamos uma torre de observação unificada. O segredo técnico por trás dessa mágica reside no entendimento de como o Prometheus armazena séries temporais e como podemos aplicar fórmulas estatísticas leves diretamente no motor de banco de dados do sistema de monitoramento sem sobrecarregar a infraestrutura.

Como a função predict_linear antecipa o esgotamento de recursos

A principal arma do PromQL para a criação de alertas preditivos é a função predict_linear. Na prática, o que essa função faz é aplicar uma regressão linear simples sobre uma janela de tempo específica para prever qual será o valor de uma métrica em um determinado momento no futuro. Ela olha para o comportamento passado dos dados — por exemplo, nas últimas duas horas — calcula a inclinação da curva de crescimento e projeta essa reta para frente, dizendo exatamente onde o sistema estará daqui a uma hora.

Para estruturar uma regra de alerta baseada nessa predição, precisamos definir duas variáveis principais: o horizonte de tempo que queremos olhar para trás e o tempo futuro que desejamos prever. Se quisermos saber se o espaço em disco de uma partição vai se esgotar nas próximas quatro horas, escrevemos uma consulta que avalia a tendência das últimas seis horas. Essa assimetria temporal é importante para dar estabilidade ao cálculo, suavizando picos de uso pontuais que poderiam disparar alarmes falsos.

Além disso, o uso adequado de funções auxiliares garante que a infraestrutura continue estável e que os engenheiros recebam apenas notificações acionáveis. Para garantir que o ambiente opere de forma saudável, é recomendável monitorar também variáveis físicas complementares, como discutido ao analisar como ler a temperatura de VRMs no Linux usando Python e I2C, prevenindo danos térmicos antes mesmo que afetem o software.

Escrevendo o primeiro alerta baseado em taxas de variação com PromQL

Vamos colocar a mão na massa construindo um arquivo de regras de alerta real para o Prometheus. Imagine que queremos disparar um alarme crítico sempre que o espaço livre de uma partição de disco for totalmente consumido nas próximas quatro horas. O código abaixo demonstra exatamente como estruturar essa consulta utilizando o PromQL avançado com a função predict_linear.

O arquivo YAML abaixo deve ser interpretado pelo servidor Prometheus dentro da sua infraestrutura de monitoramento. Preste atenção especial na forma como os operadores matemáticos filtram os discos de sistema para evitar alarmes ruidosos em volumes temporários ou partições de leitura exclusiva.

groups:
- name: disk_capacity_predictions
  rules:
  - alert: DiskSpaceExhaustionPredicted
    expr: predict_linear(node_filesystem_free_bytes{fstype=~"ext4|xfs"}[6h], 4 * 3600) < 0
    for: 15m
    labels:
      severity: critical
    annotations:
      summary: "Esgotamento de disco previsto para {{ $labels.instance }}"
      description: "O volume {{ $labels.mountpoint }} vai ficar sem espaço livre em menos de 4 horas com base na tendência atual."

Neste exemplo prático, a expressão do Prometheus seleciona o espaço livre em bytes para sistemas de arquivos dos tipos ext4 e xfs. A função predict_linear analisa as últimas seis horas de dados ([6h]) e calcula a projeção para quatro horas no futuro (4 * 3600 segundos). Se o resultado predito for menor do que zero (< 0), significa que o volume vai cruzar a linha de espaço zero dentro do horizonte estipulado. O parâmetro for: 15m garante que a condição precisa se manter verdadeira por pelo menos quinze minutos antes de enviar a notificação real para o time de plantão.

Identificando acelerações de consumo com a função deriv

Outra técnica avançada muito útil no arsenal de um engenheiro de confiabilidade é o uso da função deriv. Enquanto o predict_linear olha para o valor final projetado, o deriv calcula a taxa de variação por segundo de uma série temporal baseada em contadores ou medidores. Na prática, isso nos permite medir a aceleração do consumo de recursos, identificando vazamentos de memória ou picos repentinos de gravação em disco antes mesmo que o limite de capacidade seja sequer cogitado.

Imagine um cenário onde um aplicativo em container sofre de um vazamento severo de memória. No monitoramento tradicional, o uso de memória sobe de forma linear ou exponencial, mas o alerta só dispara quando o sistema operacional aciona o mecanismo de proteção contra falta de memória, travando processos importantes. Com a função deriv, podemos criar um gatilho que observa a velocidade com que a taxa de alocação de memória está crescendo, avisando a equipe de desenvolvimento sobre o vazamento de software minutos após o deploy da aplicação com falha.

Essa abordagem granular transforma o monitoramento de uma ferramenta passiva em um sistema ativo de detecção de anomalias. Ao entender a derivada da curva de uso de CPU, disco ou rede, conseguimos correlacionar eventos de infraestrutura com deploys de software, facilitando a identificação rápida da raiz de qualquer problema de desempenho no ambiente de produção.

Boas práticas e ajustes para evitar falsos positivos

Configurar alertas preditivos sem o devido cuidado pode transformar a rotina do time de engenharia em um caos de alarmes falsos. O primeiro cuidado fundamental é entender a sazonalidade do seu negócio. Se o seu e-commerce recebe um volume massivo de acessos todas as sextas-feiras à noite, o aumento repentino no uso de CPU e conexões de banco de dados é um comportamento esperado, e não um sinal de falha iminente. Para mitigar isso, as janelas de avaliação no PromQL devem ser largas o suficiente para absorver picos de tráfego de curta duração sem disparar falsos alarmes.

Outro ponto crítico é ajustar o parâmetro de duração do alerta usando a diretiva for. Nunca dispare um alerta preditivo com base em uma única coleta de dados que durou poucos segundos. O ideal é exigir que a tendência de esgotamento permaneça consistente por um período de dez a trinta minutos. Isso dá tempo para que processos automáticos de limpeza de logs ou rotação de arquivos entrem em ação e resolvam o problema sozinhos, poupando o sono da equipe de plantão.

Finalmente, documente sempre o significado de cada métrica preditiva e inclua links diretos para runbooks nos rótulos de anotações do Prometheus. Quando um alerta tocar no meio da noite, o engenheiro de plantão precisa saber exatamente quais comandos executar para mitigar o problema. A automação preditiva só entrega valor real se vier acompanhada de clareza operacional e procedimentos de remediação bem definidos.

Considerações finais sobre resiliência operacional baseada em dados

A implementação de alertas preditivos no Prometheus representa um salto evolutivo na maturidade operacional de qualquer equipe de engenharia. Abandonar o modelo puramente reativo e abraçar previsões baseadas em tendências matemáticas permite que os times atuem de forma proativa, blindando sistemas contra indisponibilidades antes que os usuários finais sequer percebam qualquer degradação. Com o uso adequado do PromQL, funções de regressão e boas práticas de ajuste de janelas temporais, a infraestrutura ganha uma camada inteligente de previsibilidade.

Investir tempo na construção desses mecanismos reduz o estresse das equipes de plantão, elimina incidentes evitáveis e garante que a operação tecnológica cresça de maneira sustentável e previsível. O monitoramento moderno deixou de ser apenas um painel bonito na parede para se tornar o sistema nervoso central que antecipa o futuro e protege o negócio contra surpresas indesejadas.