Pular para o conteúdo principal
Nesta receita, você vai configurar o ChatCLI para monitorar um deployment Kubernetes e usar IA para diagnosticar problemas em tempo real.

​
Cenário

Aplicação em Produção

Aplicação “myapp” rodando em produção no Kubernetes

Diagnóstico Rápido

Equipe precisa diagnosticar problemas rapidamente

Análise com IA

Usar IA para analisar logs, eventos e métricas

Contexto Automático

Contexto K8s automático em todas as perguntas

​
Opção 1: Monitoramento Local

Use esta opção quando você tem acesso direto ao cluster via kubectl.
1

Verificar Acesso ao Cluster

# Verificar conectividade
kubectl get pods -n production

# Verificar permissoes
kubectl auth can-i get pods -n production
kubectl auth can-i get pods/log -n production
kubectl auth can-i list events -n production
2

Iniciar o Watcher

chatcli watch --deployment myapp --namespace production
Você verá:
K8s Watcher starting...
  Deployment: myapp
  Namespace:  production
  Interval:   30s
  Window:     2h

Collecting initial data...
Initial data collected. Starting interactive mode.
[watch] chatcli>
3

Fazer Perguntas

[watch] chatcli> O deployment esta saudavel?

Com base nos dados coletados do Kubernetes:
- O deployment myapp tem 3/3 replicas disponiveis
- Todos os pods estao no estado Running e Ready
- Nao ha alertas ativos
- CPU media em 35%, memoria em 120Mi
O deployment esta saudavel e operando normalmente.

[watch] chatcli> /watch status

K8s Watcher Active
  Deployment:  myapp
  Namespace:   production
  Snapshots:   5
  Pods:        3
  Alerts:      0
4

Diagnosticar Problemas

Quando algo da errado:
[watch] chatcli> Por que o pod myapp-abc12 esta reiniciando?

Analisando os dados do pod myapp-abc12:
- O pod teve 5 restarts na ultima hora
- Motivo do ultimo restart: OOMKilled
- Container estava usando 490Mi de 512Mi de limite
- Logs mostram: "java.lang.OutOfMemoryError: Java heap space"

Diagnostico: O container esta excedendo o limite de memoria.
Recomendacoes:
1. Aumente resources.limits.memory para 1Gi
2. Ajuste a JVM: -Xmx384m para caber no limite
3. Investigue possivel memory leak nos logs anteriores

​
Opção 2: Servidor com Watcher (Equipe)

Use esta opção para que toda a equipe tenha acesso ao monitoramento via servidor centralizado.
1

Deploy no Kubernetes

helm install chatcli deploy/helm/chatcli \
  --namespace monitoring --create-namespace \
  --set llm.provider=CLAUDEAI \
  --set secrets.anthropicApiKey=sk-ant-xxx \
  --set server.token=equipe-token \
  --set watcher.enabled=true \
  --set watcher.deployment=myapp \
  --set watcher.namespace=production \
  --set watcher.interval=15s
2

Equipe Conecta

# Cada dev configura
export CHATCLI_REMOTE_ADDR=chatcli.monitoring.svc:50051
export CHATCLI_REMOTE_TOKEN=equipe-token

# Via port-forward (desenvolvimento)
kubectl port-forward -n monitoring svc/chatcli 50051:50051
chatcli connect localhost:50051 --token equipe-token
3

Contexto Automático

Qualquer pergunta feita por qualquer dev ja inclui automaticamente o contexto K8s:
> O que esta acontecendo com o deployment?

[O servidor injeta automaticamente os dados do K8s Watcher]

​
Fluxo de Trabalho: Incidente em Produção

1

Alerta Disparado

Você recebe um alerta do Grafana/PagerDuty/Slack sobre problemas no deployment.
2

Conectar ao ChatCLI

chatcli connect prod-chatcli:50051 --token ops-token
3

Obter Visão Geral

> Resuma o estado atual do deployment para um post-mortem
4

Investigar Causa Raiz

> Quais eventos de Warning ocorreram nos ultimos 30 minutos?
> Mostre os logs de erro mais recentes
> O que mudou desde o ultimo deploy?
5

Receber Recomendações

> Baseado nos dados, qual a causa raiz mais provavel e o que
  devo fazer para resolver?
6

Validar Resolução

> Apos aplicar o fix, os pods estao voltando ao normal?
> Compare o estado atual com 10 minutos atras

​
Ajuste Fino dos Parametros

​
Intervalo de Coleta

CenárioIntervalo Recomendado
Produção estável30s (padrão)
Investigação ativa10s
Desenvolvimento60s
CI/CD monitoring15s
chatcli watch --deployment myapp --interval 10s

​
Janela de Observação

CenárioJanela Recomendada
Debugging rápido30m
Análise normal2h (padrão)
Post-mortem6h
Analise histórica24h
chatcli watch --deployment myapp --window 6h

​
Linhas de Log

CenárioLinhas Recomendadas
Apps verbosas50
Normal100 (padrão)
Debugging profundo500
chatcli watch --deployment myapp --max-log-lines 500

​
One-Shot para Scripts e Alertas

Integre o ChatCLI com seu sistema de alertas: 
#!/bin/bash
# alert-handler.sh - Chamado quando um alerta dispara

DEPLOYMENT=$1
NAMESPACE=$2

# Gerar análise automática
ANALYSIS=$(chatcli watch \
  --deployment "$DEPLOYMENT" \
  --namespace "$NAMESPACE" \
  -p "Analise o estado atual do deployment e identifique a causa raiz do problema. Formato: markdown.")

# Enviar para Slack
curl -X POST "$SLACK_WEBHOOK" \
  -H 'Content-type: application/json' \
  -d "{\"text\": \"*ChatCLI K8s Analysis*\n\n$ANALYSIS\"}"
Ou via servidor remoto: 
chatcli connect prod-server:50051 --token ops-token \
  -p "O deployment myapp está com problemas. Analise e sugira solução." --raw

​
Dicas Avançadas

Salve documentação do projeto como contexto e anexe ao usar com o watcher:
# Salvar documentação do projeto como contexto
/context create myapp-docs ./docs --mode full --tags "k8s,ops"

# Anexar ao usar com o watcher
/context attach myapp-docs

# Agora a IA tem contexto do K8s + documentação do projeto
> Com base na documentação e no estado do cluster, o que pode estar errado?
Use o modo multi-target para monitorar tudo em uma unica instancia:
# targets.yaml
interval: "15s"
window: "2h"
maxContextChars: 32000
targets:
  - deployment: frontend
    namespace: production
    metricsPort: 3000
    metricsFilter: ["next_*", "http_*"]
  - deployment: backend
    namespace: production
    metricsPort: 9090
    metricsFilter: ["http_requests_*", "db_*", "cache_*"]
  - deployment: database
    namespace: production

# Local
chatcli watch --config targets.yaml

# Ou via servidor (toda a equipe tem acesso)
chatcli server --watch-config targets.yaml
A IA recebe contexto detalhado dos targets com problemas e resumos compactos dos saudáveis, respeitando o budget de maxContextChars.
Quando metricsPort está configurado, o watcher scrapa automaticamente o endpoint /metrics dos pods e inclui as métricas na analise. Use metricsFilter com glob patterns para selecionar apenas métricas relevantes:
metricsFilter:
  - "http_requests_total"        # Métrica exata
  - "http_request_duration_*"    # Todas de duração HTTP
  - "process_*"                  # Métricas de processo
  - "*_errors_total"             # Qualquer contador de erros

​
Opção 3: AIOps Autônomo (Operator)

Use esta opção para remediação automática de problemas sem intervenção humana.
1

Instalar o Operator

# Instalar CRDs
kubectl apply -f operator/config/crd/bases/

# Instalar RBAC e Manager
kubectl apply -f operator/config/rbac/role.yaml
kubectl apply -f operator/config/manager/manager.yaml
2

Criar Instance com Watcher

apiVersion: platform.chatcli.io/v1alpha1
kind: Instance
metadata:
  name: chatcli-aiops
  namespace: monitoring
spec:
  provider: CLAUDEAI
  apiKeys:
    name: chatcli-api-keys
  server:
    port: 50051
  watcher:
    enabled: true
    interval: "15s"
    targets:
      - deployment: api-gateway
        namespace: production
        metricsPort: 9090
      - deployment: backend
        namespace: production
        metricsPort: 9090
      - deployment: worker
        namespace: batch
3

Monitorar o Pipeline

# Verificar anomalias detectadas
kubectl get anomalies -A --watch

# Verificar issues criados
kubectl get issues -A --watch

# Verificar análises da IA
kubectl get aiinsights -A

# Verificar remediações
kubectl get remediationplans -A

# Verificar runbooks (manuais e auto-gerados)
kubectl get runbooks -A

# Verificar post-mortems (gerados após resolução agêntica)
kubectl get postmortems -A
4

Fluxo Autônomo em Ação

Quando um pod comeca a crashar:
1. WatcherBridge detecta HighRestartCount -> cria Anomaly
2. AnomalyReconciler correlaciona -> cria Issue (risk: 20, severity: Low, signalType: pod_restart)
3. Se OOMKilled tambem -> Issue atualizado (risk: 50, severity: Medium)
4. IssueReconciler cria AIInsight
5. AIInsightReconciler coleta contexto K8s (pods, eventos, revisoes)
   -> chama LLM com contexto enriquecido -> retorna: "restart + scale to 4"
6. IssueReconciler busca Runbook manual (tiered matching)
   -> se nao encontra, gera Runbook auto da IA (reutilizavel)
   -> se nenhum Runbook e nenhuma acao IA -> modo Agential
   -> cria RemediationPlan com acoes
7. RemediationReconciler executa:
   -> Modo normal: executa acoes do plano (restart, scale, etc.)
   -> Modo agential: loop observe-decide-act (IA decide cada passo)
     - Cada reconcile = 1 step (max 10 steps, timeout 10min)
     - IA observa estado K8s -> decide acao -> executa -> proximo step
     - Acoes: Scale, Restart, Rollback, PatchConfig, AdjustResources, DeletePod
8. Issue -> Resolved (dedup invalidado para deteccao de recorrencia)
   -> Se modo agential: PostMortem CR auto-gerado (timeline, root cause, licoes)
   -> Runbook gerado automaticamente dos steps agentiais bem-sucedidos
   Se falhar -> re-analise com contexto de falha -> estrategia diferente
Tudo acontece automaticamente sem intervenção humana. Runbooks auto-gerados são reutilizados para futuras ocorrências do mesmo tipo. No modo agêntico, a IA atua como agente autônomo com “skills” K8s, e ao resolver o problema gera um PostMortem CR com timeline completa e um Runbook reutilizável para futuras ocorrências.
5

(Opcional) Adicionar Runbooks

Para cenários específicos onde você quer controlar exatamente o que fazer:
apiVersion: platform.chatcli.io/v1alpha1
kind: Runbook
metadata:
  name: oom-standard-procedure
  namespace: production
spec:
  description: "Standard OOMKill recovery for production"
  trigger:
    signalType: oom_kill
    severity: critical
    resourceKind: Deployment
  steps:
    - name: Restart pods
      action: RestartDeployment
      description: "Restart to reclaim leaked memory"
    - name: Scale up
      action: ScaleDeployment
      description: "Add replicas for redundancy"
      params:
        replicas: "5"
  maxAttempts: 2
Prioridade de remediação: Runbook manual > Runbook auto-gerado > Remediação agêntica > Escalação. Quando não há Runbook manual, a IA gera automaticamente um Runbook CR reutilizável. Se nem Runbook nem ações de IA estão disponíveis, o operator entra em modo agêntico: a IA atua como agente autônomo num loop observe-decide-act, e ao resolver gera um PostMortem CR e um Runbook reutilizável.

​
Checklist de Implantacao

  • Verificar acesso ao cluster (kubectl get pods)
  • Verificar permissoes RBAC para pods, logs, eventos
  • Escolher modo: local (chatcli watch) ou servidor (chatcli server)
  • Definir targets: single (--deployment) ou multi (--config targets.yaml)
  • (Opcional) Configurar metricsPort para Prometheus scraping
  • Configurar intervalo e janela adequados ao cenário
  • Ajustar maxContextChars se necessario (padrão: 32000)
  • Testar com pergunta simples: “O deployment está saudável?”
  • (Opcional) Integrar com alertas para análise automática
  • (Opcional) Distribuir acesso para a equipe via token