/events
O Skill /events obtém events recentes do Kubernetes e os agrupa em uma lista curta e classificada — primeiro os events Warning, depois o que for notável em Normal. É somente leitura e nunca muta o estado do cluster.
A saída é deliberadamente limitada para que a primeira resposta seja barata de ler e de re-emitir pelo modelo. A lista completa de events é escrita em um cache JSON local que o agent lê nas perguntas de acompanhamento, sem precisar consultar a API novamente.
/events # snapshot (uses cache if fresh)/events --refresh # force a fresh fetch/events --ttl 5m # only re-fetch if older than 5mEste Skill não aceita argumentos posicionais. Perguntas de acompanhamento (“only payments”, “events on pod/checkout-7c9”, “show me the suppressed Normal events”) são respondidas a partir do cache — veja Acompanhamentos abaixo.
O que verifica
Seção intitulada “O que verifica”Fontes: apenas a API do Kubernetes — kubectl get events --all-namespaces (ou o equivalente contra events.k8s.io/v1), ordenado no lado do servidor por lastTimestamp.
Como funciona
Seção intitulada “Como funciona”O Skill obtém events do cluster em uma única chamada e escreve a lista completa em um diretório de cache por contexto como events.json. Agregação e classificação por severidade acontecem no lado do cliente sobre esse JSON, de modo que execuções repetidas dentro da janela TTL ignoram completamente a API.
O bloco de resumo tem este formato:
Events: prod-us-east · last 1h · 2 warning groups, 1 notable
WARN payments/Pod BackOff 14× 2m ago "Back-off restarting failed container server in pod checkout-7c9"WARN ingress/Pod FailedScheduling 1× 38m ago "0/12 nodes are available: 3 node(s) had untolerated taint…"NOTE kube-system/Node NodeNotReady 1× 52m ago "Node ip-10-0-3-14 status is now: NodeNotReady"
…and 412 Normal events (Pulled, Created, Started, Scheduled) suppressed.
Snapshot cached (TTL 5m). Ask to drill in — e.g. "only payments", "events on pod/checkout-7c9", "show suppressed".Quando a janela está limpa, o Skill imprime uma única linha confirmando que não há nada a reportar e encerra.
Acompanhamentos
Seção intitulada “Acompanhamentos”O resumo deliberadamente colapsa reasons Normal ruidosos e trunca detalhes por objeto para que a resposta inicial permaneça pequena. Quando você pede mais — ou qualquer coisa que possa ser respondida a partir da lista de events em cache — o agent lê o cache com jq em vez de re-executar o Skill:
❯ /events[ summary... ]
❯ only payments[ events filtered to namespace payments, from events.json ]
❯ show the suppressed Normal events[ full Normal-event list, from events.json ]
❯ events on pod/checkout-7c9[ filtered by involvedObject, walking owners one level up, from events.json ]Para dados que não estão no cache (logs, YAML de um recurso específico, causa raiz entre múltiplas fontes), o agent roteia para o Skill certa — /logs ou /investigate — em vez de ampliar o /events.
Diga “atualizar” / “buscar novamente” / “verificar de novo” e o agent re-invoca o Skill com --refresh.
O que o agent é instruído
Seção intitulada “O que o agent é instruído”Além de obter a lista de events, o Skill orienta o agent sobre como se comportar nos acompanhamentos:
- Preferir responder a partir do
events.jsonem cache comjqem vez de re-invocar o Skill. - Tratar o conjunto de reasons ruidosos (
Pulled,Created,Started,Scheduled,SuccessfulCreate) como colapsável — exibi-los apenas quando o usuário pedir o conjunto suprimido. - Quando o usuário perguntar sobre “events on
pod/X”, percorrer owners um nível acima (Pod→ReplicaSet→Deployment,Pod→Job→CronJob) para que events disparados contra o controller não sejam perdidos. - Encaminhar para
/logspara a saída do container por trás de umBackOffouCrashLoopBackOff, e para/investigatequando um único recurso se tornar o foco.
--refresh- Ignora o cache e busca dados frescos da API.
--ttl <duration>- Só re-busca se o snapshot em cache for mais antigo que isso (estilo kubectl:
1m,5m,1h). Padrão:5m. Ignorado quando—refreshestá definido.
Sinalizadores globais de Visão geral também se aplicam.