Solução · Plantão e SRE
O alerta toca às 3h. A resposta está nos eventos, e eles somem em uma hora.
O Kubepier mostra os eventos com os avisos primeiro, o consumo sem abrir o Grafana e as filas do pod, e o diagnóstico por IA explica o erro em português a partir dos eventos e do log. Para o que vem antes do alerta, o nosso time monta a observabilidade.
Por que o jeito de hoje não basta
Os eventos não esperam
Por padrão, o Kubernetes guarda eventos por uma hora. Quem chega depois do incidente encontra o pod reiniciado e a pista apagada.
O motivo não está onde se procura
Um OOMKilled não gera evento próprio: o motivo fica no Last State do container. Quem filtra os eventos por "OOM" não acha nada.
Um nó que cai leva uns seis minutos
Medimos: 48 s até o nó virar NotReady e mais 300 s até os pods saírem. Serviço com uma réplica fica fora do ar esse tempo todo.
Como começa
sem prazo nem preço antes de entender o seu caso- 1
Os clusters no Kubepier
Desktop ou web, com os clusters de produção no catálogo, por projeto.
- 2
O pod que caiu, explicado
Eventos com os avisos primeiro, filtro por namespace e motivo, e o diagnóstico por IA com a sua chave da Anthropic ou da OpenAI.
- 3
O que vem antes do alerta
Se faltam métricas, logs e traces ligados entre si, o serviço de observabilidade monta Prometheus, Loki, Tempo e OpenTelemetry.
Hoje x com a gente
Hoje
- Terminal, contexto certo, describe, logs --previous, events
- Eventos perdidos depois de uma hora
- Grafana aberto numa aba, kubectl na outra
- Log e eventos em inglês, às 3h
- Fila crescendo sem ninguém ver
Com o Kubepier e o IA4CODE
- O pod com erro, os eventos e o log na mesma tela
- Avisos primeiro, filtro por namespace e motivo
- Consumo de CPU e memória no dashboard, sem abrir o Grafana
- Causa provável, evidência e correção sugerida em português
- Filas do pod em RabbitMQ e Azure Service Bus com o tamanho atual
Os números
cada um com a fontede retenção padrão dos eventos no Kubernetes
fonte: documentação do kube-apiserver (--event-ttl)
entre um nó cair e os pods dele serem substituídos, medido num cluster de teste
fonte: página Node NotReady do IA4CODE
eventos chamados OOMKilled: o motivo fica só no Last State
fonte: página OOMKilled do IA4CODE
Convive com o que você já usa
O Kubepier não substitui o Prometheus, o Grafana nem o seu alertmanager: é onde você abre o cluster quando o alerta chega. O metrics-server, se faltar, tem instalador que mostra o que vai mudar antes.
O que entra
A IDE de Kubernetes: catálogo por projeto, diagnóstico por IA, eventos e filas. Free grátis para sempre; Pro R$ 49 e Team R$ 199 por mês, por organização.
conhecer o Kubepier →Serviço
Observabilidade
Métricas, logs e traces de ponta a ponta com Prometheus, Loki, Tempo e OpenTelemetry.
onde já fizemos: Prometheus, Loki, Tempo e OpenTelemetry numa plataforma de dados B2B própria.
Perguntas antes de começar
O Kubepier manda alerta?
Não. Ele é onde você investiga depois que o alerta chega. Alertas continuam no seu sistema de monitoramento.
Qual modelo de IA ele usa?
O da chave que você informar: Anthropic ou OpenAI. A chave é sua, e o custo de cada diagnóstico sai da sua conta no provedor.
Serve para cluster sem metrics-server?
Sim. Sem ele, o consumo não aparece; o instalador do Kubepier mostra o que vai mudar antes de instalar.
Para ler antes da conversa
Saber por que o pod caiu antes de acordar mais alguém.
Conte o problema em três linhas. Respondemos com perguntas, não com proposta.