Solução de Problemas Avançada: Um Mergulho Profundo em Logs, Eventos e Métricas do Kubernetes

A solução de problemas no Kubernetes fica mais fácil quando você separa três perguntas: o que o contêiner disse, o que o plano de controle fez e o que as métricas mostram? Logs, eventos e métricas respondem a diferentes partes do mesmo incidente.

Os exemplos abaixo mostram como usar todos os três juntos quando um pod falha, uma imagem não é puxada, uma carga de trabalho não pode ser agendada ou um serviço parece saudável, mas responde lentamente.

Logs do Kubernetes: A Base da Depuração

Logs são os registros detalhados do que um aplicativo ou processo do sistema está fazendo. No Kubernetes, os logs são gerados pelos contêineres em execução dentro dos seus pods. Eles são frequentemente o primeiro lugar para verificar quando um aplicativo não está se comportando como esperado.

Acessando Logs de Contêineres

O comando kubectl logs é sua ferramenta principal para recuperar logs de pods. Ele é versátil e oferece várias opções úteis.

Obter logs de um único contêiner em um pod:
```
kubectl logs <nome-do-pod>
```
Se um pod tiver apenas um contêiner, este comando funciona diretamente.
Obter logs de um contêiner específico em um pod com múltiplos contêineres:
```
kubectl logs <nome-do-pod> -c <nome-do-contêiner>
```
Visualizar logs de uma instância anterior de um contêiner que falhou: Se um contêiner foi reiniciado devido a um erro, você pode visualizar seus logs antes da reinicialização usando a flag --previous:
```
kubectl logs <nome-do-pod> --previous
```
Seguir logs em tempo real: Semelhante ao tail -f, a flag -f (ou --follow) permite que você transmita novas entradas de log à medida que são geradas, o que é inestimável para depurar problemas ao vivo.
```
kubectl logs -f <nome-do-pod> -c <nome-do-contêiner>
```
Filtrar logs por tempo: Você pode especificar quantas linhas do final recuperar (--tail) ou logs de uma duração específica (--since).
```
kubectl logs <nome-do-pod> --tail=100 # Últimas 100 linhas
kubectl logs <nome-do-pod> --since=1h # Logs da última hora
```

Soluções de Log Centralizado

Embora kubectl logs seja excelente para depuração imediata, não é prático para gerenciamento de logs em larga escala e longo prazo. Para ambientes de produção, soluções de log centralizado são essenciais. Essas soluções geralmente envolvem:

Agentes de Log: Executar um agente (por exemplo, Fluentd, Fluent Bit, Filebeat) em cada nó para coletar logs de todos os pods.
Armazenamento e Indexação de Logs: Armazenar logs em um repositório central (por exemplo, Elasticsearch, Loki, Splunk).
Visualização e Análise de Logs: Fornecer uma interface para pesquisar, filtrar e visualizar logs (por exemplo, Kibana, Grafana, Splunk UI).

Melhores Práticas para Logging

Log Estruturado: Emita logs em um formato estruturado (por exemplo, JSON) para torná-los facilmente analisáveis e consultáveis por sistemas de log centralizados.
Níveis de Log Apropriados: Use diferentes níveis de log (DEBUG, INFO, WARN, ERROR, FATAL) para categorizar mensagens e controlar a verbosidade.
Evite Informações Sensíveis: Não registre dados sensíveis (senhas, PII) diretamente.

Eventos do Kubernetes: O Contador de Histórias do Cluster

Eventos do Kubernetes são registros de mudanças de estado e operações que ocorrem dentro do cluster. Eles fornecem insights cruciais sobre o que o próprio Kubernetes está fazendo (ou deixando de fazer) em resposta ao seu estado desejado. Eventos são inestimáveis para entender por que os pods não estão sendo agendados, as imagens não estão sendo puxadas ou os volumes não estão sendo montados.

Acessando Eventos do Kubernetes

Eventos em todo o cluster:

kubectl get events

Este comando mostra todos os eventos recentes no namespace atual. Você pode adicionar --all-namespaces para ver eventos em todo o cluster.

Uma saída de evento típica se parece com isso:

ÚLTIMA VISTA   TIPO      MOTIVO      OBJETO                         MENSAGEM
3m21s          Normal    Scheduled   pod/my-app-789c6f66-abcde      Atribuído com sucesso default/my-app-789c6f66-abcde ao node01
3m20s          Normal    Pulling     pod/my-app-789c6f66-abcde      Puxando imagem "example/my-app:1.2.3"
2m58s          Warning   BackOff     pod/my-app-789c6f66-abcde      Back-off reiniciando contêiner com falha app

Eventos para um objeto:
```
kubectl describe pod <nome-do-pod>
```
A seção Eventos na parte inferior é frequentemente a maneira mais rápida de ver problemas de agendamento, puxamento, montagem e reinicialização para um único pod.

Ordenar eventos por hora de criação:

kubectl get events --sort-by=.metadata.creationTimestamp

O que os Eventos Geralmente Te Dizem

Eventos são registros de curta duração, então são melhores para falhas recentes. Procure por estas razões comuns:

FailedScheduling: O agendador não conseguiu colocar o pod. Verifique seletores de nó, taints, tolerâncias, solicitações de recursos e capacidade disponível.
ImagePullBackOff ou ErrImagePull: O Kubernetes não conseguiu puxar a imagem. Verifique o nome da imagem, tag, acesso ao registro e segredo de pull de imagem.
FailedMount: Um volume não pôde ser montado. Verifique a ligação do PVC, classe de armazenamento, permissões do nó e saúde do driver CSI.
BackOff: Um contêiner continua falhando. Combine o evento com kubectl logs --previous.

Métricas do Kubernetes: A Visão de Recursos

As métricas informam se o cluster tem CPU, memória e capacidade suficientes para a carga de trabalho. Elas também ajudam a separar bugs de aplicativos de pressão de recursos.

Verificações Rápidas com metrics-server

Se o metrics-server estiver instalado, use kubectl top:

kubectl top nodes
kubectl top pods
kubectl top pod <nome-do-pod> --containers

Alta memória de pod perto do limite do contêiner geralmente coincide com reinicializações OOMKilled. Alta CPU de nó pode explicar latência mesmo quando os logs do pod parecem limpos.

Métricas Mais Aprofundadas com Prometheus

Em produção, Prometheus e Grafana geralmente fornecem a visão histórica que kubectl top não tem. Sinais úteis incluem:

Reinicializações de contêiner ao longo do tempo.
Throttling de CPU para contêineres com limites baixos de CPU.
Conjunto de trabalho de memória comparado com limites.
Pods pendentes por namespace.
Latência de solicitação do servidor da API e taxa de erro.
Pressão de disco do nó, pressão de memória e saturação de rede.

Correlacionando Logs, Eventos e Métricas

Use uma janela de tempo e vá do sintoma à causa:

Verifique o estado do pod:

kubectl get pod <nome-do-pod> -o wide
kubectl describe pod <nome-do-pod>

Leia os logs atuais e anteriores:

kubectl logs <nome-do-pod> -c <nome-do-contêiner>
kubectl logs <nome-do-pod> -c <nome-do-contêiner> --previous

Verifique eventos recentes do namespace:

kubectl get events --sort-by=.metadata.creationTimestamp

Compare o uso de recursos:

kubectl top pod <nome-do-pod> --containers
kubectl top node

Por exemplo, um pod com CrashLoopBackOff, logs anteriores terminando em um erro de falta de memória e métricas mostrando memória perto do limite aponta para um problema de limite de memória ou memória do aplicativo. Um pod preso em Pending com eventos FailedScheduling e baixa capacidade do nó aponta para pressão de agendamento, não um bug de contêiner.

Conclusão

Não depure o Kubernetes com base em um único sinal. Logs explicam o comportamento do aplicativo, eventos explicam as decisões do plano de controle e métricas explicam a pressão de recursos. Quando você os alinha por tempo e nome do objeto, as causas raiz se tornam muito mais fáceis de separar dos sintomas.