Análise por IA
Um agente de IA investiga a causa raiz de um alerta e grava no próprio alerta um relatório de recomendação: resumo, causa raiz, evidências, solução e o comando sugerido para um operador avaliar. Nada é executado: a IA só lê e só recomenda.
Onde está disponível
| Origem | Quem lê os dados | Onde pedir |
|---|---|---|
| Alertas Kubernetes | O servidor do Argus, pela API do cluster, com permissão só de leitura | Painel do alerta → Analisar com IA |
Eventos Warning do cluster Kubernetes | Idem | Página do cluster → Eventos do cluster → clique no evento → Analisar com IA |
| Alertas de containers e do Docker Swarm | O agente do próprio host, no socket do Docker | Painel do alerta (em Alertas, no detalhe do host ou na página do cluster) |
A funcionalidade é opcional e ligada pelo time do Argus. Pedir uma análise exige papel operator e fica no
registro de auditoria. Alertas críticos podem ser analisados automaticamente, uma vez por incidente e com teto por hora.
Como funciona
get, describe, logs). Docker/Swarm: o agente do host coleta as evidências e devolve ao servidor.Uma análise em que nenhuma leitura funcionou termina como falha, com o erro, em vez de um relatório adivinhado a partir do texto do alerta. Cada análise tem limite de tempo e de chamadas ao modelo.
Kubernetes: o que a IA pode ler
- Uma ServiceAccount própria, só com
get/listem workloads, pods, logs de pod, eventos, nós, serviços, ingress e volumes. - Sem acesso a
secrets,configmaps,exec,attachou proxy de nó, e sem nenhum verbo de escrita. - Além do RBAC, o servidor só entrega ao modelo as ferramentas de leitura (
get,describe,logs).
Docker e Swarm: o que sai do host
O agente só faz uma lista fixa de consultas GET no socket do Docker: informações do Swarm, nós, inspect e
tasks do serviço, inspect do container e as últimas linhas de log. O servidor manda só nomes, validados no agente.
- Valores de variáveis de ambiente nunca saem do host, só os nomes.
- Labels com
pass,secret,token,auth,keyoucredentialsão mascaradas. - Logs e healthcheck passam pelo mesmo mascaramento de segredos da coleta de logs.
- Até 60 linhas de log por serviço/container (configurável até 200) e no máximo 120 KB por coleta.
- Num manager, todas as leituras funcionam; num worker, só as de container.
ai_investigation:
enabled: true # false desliga a coleta neste host
log_tail_lines: 60 # máximo 200Se o agente não entregar a coleta em 5 minutos (host offline, versão antiga do agente ou coleta desligada), a análise termina como falha com essa explicação.
Episódios de pressão
Com a análise de episódios ligada, cada episódio de pressão recebe no máximo uma análise automática, dentro de um limite por projeto por hora. Aqui o modelo não consulta nada: o servidor monta um resumo do episódio (séries, linha do tempo, workloads e lacunas de dados), retira tokens e senhas e separa os textos vindos do cluster como dados não confiáveis.
- A resposta é validada: toda evidência cita um item do resumo, e confiança alta exige duas evidências e impacto confirmado.
- O resultado aparece como hipótese, nunca como causa comprovada; clicar numa evidência destaca o item na linha do tempo.
- Quando a análise termina, uma mensagem curta segue o alerta no Slack/WhatsApp, sem evidências nem textos de eventos.
- Se o modelo falhar ou responder fora do formato, a análise fica indisponível e o alerta continua igual.
Privacidade
O alerta (título, recurso, mensagem e evidências resumidas) e o que foi lido do cluster ou do Docker são enviados ao provedor do modelo de linguagem. Logs de aplicação podem conter dados sensíveis, mesmo com o mascaramento. O relatório é exibido no painel com HTML escapado e só links http(s).