Fazer análises históricas com o Cloud Logging

Quando um pod falha ou um serviço não funciona como esperado no Google Kubernetes Engine (GKE), é fundamental entender a sequência de eventos que levam ao problema. Inspecionar o estado atual nem sempre é suficiente para encontrar a causa raiz, o que torna os dados de registros históricos muito importantes.

Use esta página para saber como usar o Cloud Logging e investigar falhas anteriores (por exemplo, por que um pod não foi iniciado ou quem excluiu uma implantação crítica) consultando e analisando registros do GKE.

Essas informações são importantes para administradores e operadores de plataforma que precisam realizar análises de causa raiz em problemas em todo o cluster, auditar mudanças e entender as tendências de comportamento do sistema. Também é essencial para desenvolvedores de aplicativos depurarem erros específicos do aplicativo, rastrearem caminhos de solicitação e entenderem como o código deles se comporta no ambiente do GKE ao longo do tempo. Para mais informações sobre os papéis comuns e as tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Funções e tarefas de usuário comuns do GKE.

Entender os principais tipos de registro para solução de problemas

Para ajudar na solução de problemas, o Cloud Logging coleta e agrega automaticamente vários tipos de registros importantes dos clusters do GKE, apps contêinerizados e outrosGoogle Cloud serviços:

  • Registros de nó e de ambiente de execução (kubelet, containerd): os registros dos serviços de nó subjacentes. Como o kubelet gerencia o ciclo de vida de todos os pods no nó, os registros dele são essenciais para a solução de problemas como inicializações de contêineres, eventos de memória insuficiente (OOM), falhas de sondagem e erros de montagem de volume. Esses registros também são cruciais para diagnosticar problemas no nível do nó, como um nó com o status NotReady.

    Como o containerd gerencia o ciclo de vida dos contêineres, incluindo a extração de imagens, os registros dele são cruciais para resolver problemas que acontecem antes que o kubelet possa iniciar o contêiner. Os registros do containerd ajudam a diagnosticar problemas no nível do nó no GKE, porque documentam as atividades específicas e os possíveis erros do ambiente de execução do contêiner.

  • Registros do app (stdout, stderr): os streams de saída padrão e erro dos processos conteinerizados. Esses registros são essenciais para depurar problemas específicos do app, como falhas, erros ou comportamento inesperado.

  • Registros de auditoria: respondem à pergunta "quem fez o quê, onde e quando?" para seu cluster. Eles rastreiam ações administrativas e chamadas de API feitas para o servidor de API Kubernetes, o que é útil para diagnosticar problemas causados por mudanças de configuração ou acesso não autorizado.

Cenários comuns de solução de problemas

Depois de identificar um problema, consulte esses registros para descobrir o que aconteceu. Para ajudar você a começar, a análise de registros pode ajudar com estes problemas:

  • Se um nó tiver o status NotReady, revise os registros dele. Os registros kubelet e containerd geralmente revelam a causa subjacente, como problemas de rede ou restrições de recursos.
  • Se um novo nó não for provisionado e não entrar no cluster, analise os registros da porta serial do nó. Esses registros capturam a inicialização antecipada e a atividade de inicialização do kubelet antes que os agentes do Logging do nó estejam totalmente ativos.
  • Se um pod não tiver sido iniciado no passado, revise os registros do app para verificar se houve falhas. Se os registros estiverem vazios ou o pod não puder ser programado, verifique os registros de auditoria em busca de eventos relevantes ou os registros do nó de destino para encontrar pistas sobre pressão de recursos ou erros de extração de imagem.
  • Se uma implantação crítica foi excluída e ninguém sabe o motivo, consulte os registros de auditoria de atividade do administrador. Esses registros ajudam a identificar qual usuário ou conta de serviço emitiu a chamada de API de exclusão, fornecendo um ponto de partida claro para sua investigação.

Como acessar registros

Use a Análise de registros para consultar, visualizar e analisar registros do GKE no console Google Cloud . A Análise de registros oferece opções de filtragem eficientes que ajudam a isolar o problema.

Para acessar e usar a Análise de registros, siga estas etapas:

  1. No console do Google Cloud , acesse a página Análise de registros.

    Acessar a Análise de registros

  2. No painel de consulta, insira uma consulta. Use a linguagem de consulta do Logging para escrever consultas segmentadas. Confira alguns filtros comuns para começar:

    Tipo de filtro Descrição Valor de exemplo
    resource.type O tipo de recurso do Kubernetes. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id O stream de registros do recurso. stdout, stderr
    resource.labels.RESOURCE_TYPE.name Filtre recursos com um nome específico.
    Substitua RESOURCE_TYPE pelo nome do recurso que você quer consultar. Por exemplo, namespace ou pod.    		 example-namespace-name, example-pod-name
    severity O nível de gravidade do registro. DEFAULT, INFO, WARNING, ERROR, CRITICAL
    jsonPayload.message=~ Uma pesquisa de expressão regular por texto na mensagem de registro. scale.down.error.failed.to.delete.node.min.size.reached

    Por exemplo, para resolver problemas de um pod específico, isole os registros de erros dele. Para ver apenas os registros com uma gravidade ERROR para esse pod, use a consulta a seguir:

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    Substitua:

    • POD_NAME: o nome do pod com problemas.
    • NAMESPACE_NAME: o namespace em que o pod está. Se você não souber qual é o namespace, consulte a coluna Namespace na saída do comando kubectl get pods.

    Para mais exemplos, consulte Consultas relacionadas ao Kubernetes na documentação do Google Cloud Observability.

  3. Clique em Executar consulta.

  4. Para conferir a mensagem de registro completa, incluindo o payload JSON, os metadados e o carimbo de data/hora, clique na entrada de registro.

Para mais informações sobre os registros do GKE, consulte Sobre os registros do GKE.

A seguir