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.