Do Monitoramento Tradicional ao AIOps: Como Escalar Kubernetes de Forma Inteligente

 

1. Introdução: O Problema dos Muitos Dashboards

Quem trabalha com SRE ou DevOps já passou por isso: um sistema começa a falhar e, mesmo com vários dashboards abertos no Grafana, demora para descobrir a causa real do problema.

O monitoramento tradicional funciona bem em ambientes pequenos, mas em clusters Kubernetes grandes a situação muda rapidamente. Existem milhares de métricas, vários microservices se comunicando ao mesmo tempo e o autoscaling pode gerar comportamentos imprevisíveis.

Nesse cenário, alertas simples como:

  • “CPU acima de 80%”
  • “Memória acima de 90%”

nem sempre significam um problema real.

O resultado costuma ser:

  • excesso de alertas;
  • perda de tempo investigando falsos positivos;
  • equipes cansadas;
  • incidentes demorando mais para serem resolvidos.

É aqui que entra o conceito de AIOps.

AIOps usa inteligência artificial e automação para analisar métricas, identificar padrões e até corrigir problemas automaticamente.

2. O Que é Agentic AIOps?

O Agentic AIOps transforma o monitoramento tradicional em um sistema mais inteligente e automático.

Em vez de apenas mostrar dashboards, os agentes conseguem:

  • entender o comportamento normal da aplicação;
  • detectar anomalias;
  • reduzir alertas repetidos;
  • executar correções automáticas.

Os quatro pilares principais são:

2.1 Detecção de Anomalias (Anomaly Detection)

O sistema aprende como sua aplicação normalmente se comporta.

Depois disso, ele consegue identificar comportamentos fora do padrão, como:

  • aumento inesperado de CPU;
  • crescimento anormal da latência;
  • falhas em serviços específicos.

Algoritmos como:

  • Z-score
  • Isolation Forest

ajudam a separar picos normais de falhas reais.

2.2 Baselining Automático

No monitoramento tradicional, os alertas usam limites fixos.

Exemplo:

“Gerar alerta se CPU passar de 80%”.

O problema é que muitas aplicações possuem horários de pico naturais.

Com o baselining automático, o sistema aprende padrões diários e semanais.

Por exemplo:

  • segunda-feira às 10h pode sempre ter mais tráfego;
  • fim de semana pode ter menos uso.

Assim, o sistema entende que certos aumentos são normais e evita alertas desnecessários.

2.3 Deduplicação de Alertas

Quando um nó do Kubernetes falha, vários alertas aparecem ao mesmo tempo.

Isso é conhecido como alert storm.

O AIOps agrupa alertas relacionados e mostra apenas o problema principal.

Em vez de centenas de notificações, o time recebe apenas o alerta realmente importante.

2.4 Self-Healing (Correção Automática)

O sistema também pode agir sozinho.

Exemplos:

  • reiniciar Pods com CrashLoopBackOff;
  • escalar réplicas automaticamente;
  • drenar nós com problemas;
  • liberar espaço em disco.

Isso reduz o tempo de resposta e evita intervenção manual.

3. Autoscaling Inteligente com MOHA

O autoscaling padrão do Kubernetes normalmente considera apenas CPU ou memória.

O problema é que ele não leva em conta:

  • custo financeiro;
  • tempo de resposta real da aplicação;
  • qualidade da experiência do usuário.

O framework MOHA (Multi-Objective Hybrid Autoscaling) tenta equilibrar tudo isso.

Como o MOHA Funciona?

Ele usa Machine Learning para prever:

  • consumo de CPU;
  • uso de memória;
  • tempo de resposta da aplicação.

No estudo apresentado, foram comparados três modelos:

Modelo Velocidade Precisão Resultado
Linear Regression Muito rápida Média Simples, mas limitada
SVR Mais lenta Alta Melhor equilíbrio
Neural Network Média Média Complexidade desnecessária

O modelo SVR (Support Vector Regression) apresentou o melhor resultado porque:

  • lida melhor com dados fora do padrão;
  • mantém maior estabilidade;
  • reduz custos operacionais.

Resultado Financeiro

Nos testes realizados na Google Cloud, o modelo SVR conseguiu reduzir o custo para aproximadamente:

  • US$ 6,48 por dia

Enquanto modelos menos eficientes chegaram a:

  • US$ 30,72 por dia

Ou seja, prever corretamente o uso de recursos pode economizar bastante dinheiro.

4. O Loop MAPE

O funcionamento do Agentic AIOps normalmente segue o modelo MAPE:

Monitor

Coleta métricas usando ferramentas como:

  • Prometheus
  • Linkerd

Analyze

Os agentes analisam os dados e verificam:

  • anomalias;
  • tendências;
  • riscos futuros.

Plan

O sistema decide o que fazer.

Exemplos:

  • aumentar réplicas;
  • adicionar memória;
  • reduzir consumo;
  • redistribuir carga.

O método TOPSIS pode ajudar a escolher a melhor ação com base em prioridades.

Execute

A ação é aplicada automaticamente via Kubernetes API.

Exemplos:

  • patch de Pods;
  • rolling updates;
  • scaling automático.

Tudo isso mantendo disponibilidade da aplicação.

5. Segurança da Plataforma

Como o sistema recebe métricas e alertas automaticamente, a API de ingestão precisa ser protegida.

Uma prática comum é exigir:

Authorization: Bearer TOKEN

Assim apenas sistemas autorizados conseguem enviar dados.

6. Queries Importantes no Prometheus

Algumas métricas são fundamentais para detectar problemas cedo.

Pods por Namespace

Ajuda a identificar deploys excessivos.

count(kube_pod_info) by (namespace)

Containers sem CPU Limits

Detecta containers sem limites definidos.

count(kube_pod_container_info)
-
count(kube_pod_container_resource_limits{resource="cpu"})

Taxa de Reinício de Containers

Importante para detectar CrashLoopBackOff.

kube_pod_container_status_restarts_total

Overcommit de CPU e Memória

Verifica se os Pods estão consumindo mais recursos do que os nós suportam.

Nodes Instáveis (Flapping)

Detecta nós alternando entre Ready e NotReady.

Isso pode gerar problemas de agendamento no cluster.

7. Conclusão: O Futuro é Mais Automatizado

O futuro do Kubernetes está caminhando para operações mais automáticas e inteligentes.

Em vez de equipes analisando dashboards manualmente o tempo todo, sistemas AIOps conseguem:

  • detectar problemas mais rápido;
  • reduzir alertas inúteis;
  • executar correções automáticas;
  • diminuir custos de infraestrutura.

Os benefícios incluem:

  • redução do MTTD (tempo para detectar falhas);
  • redução do MTTR (tempo para resolver problemas);
  • menos desgaste da equipe;
  • melhor estabilidade da plataforma.

A ideia principal é simples:

o cluster deve trabalhar para o time, e não o contrário.

 

Compartilhe esse conteúdo

Posts Relacionados