GSP736

Informações gerais

O Cloud Logging e o Cloud Monitoring são produtos completos e totalmente integrados ao Google Kubernetes Engine. Neste laboratório, você vai aprender como o Cloud Logging funciona com clusters do GKE e com aplicativos. Também vamos abordar as práticas recomendadas para a coleta de registros, usando casos de uso como exemplo.

Objetivos

Neste laboratório, você vai aprender a:

• Usar o Cloud Monitoring para detectar problemas
• Usar o Cloud Logging para resolver problemas de um aplicativo executado no GKE

O aplicativo de demonstração usado no laboratório

Para uma experiência mais concreta, vamos usar um aplicativo de exemplo. Você vai resolver problemas em um app de demonstração de microsserviços, implantado em um cluster do GKE. Nesse app de demonstração, há diversos microsserviços com dependências entre eles. Você vai gerar tráfego com o auxílio de um gerador de carga e, em seguida, usar o Logging, o Monitoring e o GKE para notificar o erro (alerta/métricas). Também vamos usar essas ferramentas para identificar a causa raiz, corrigir o problema (Logging) e confirmar a correção dele (Logging e Monitoring).

Configuração e requisitos

Antes de clicar no botão Começar o Laboratório

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é ativado quando você clica em Iniciar laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.

Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, e não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.

Confira os requisitos para concluir o laboratório:

• Acesso a um navegador de Internet padrão (recomendamos o Chrome).

Observação: para executar este laboratório, use o modo de navegação anônima (recomendado) ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e de estudante, o que poderia causar cobranças extras na sua conta pessoal.

• Tempo para concluir o laboratório: não se esqueça que, depois de começar, não será possível pausar o laboratório.

Observação: use apenas a conta de estudante neste laboratório. Se usar outra conta do Google Cloud, você poderá receber cobranças nela.

Como iniciar seu laboratório e fazer login no console do Google Cloud

1. Clique no botão Começar o laboratório. Se for preciso pagar por ele, uma caixa de diálogo vai aparecer para você selecionar a forma de pagamento. No painel Detalhes do Laboratório, à esquerda, você vai encontrar o seguinte:

   • O botão Abrir Console do Google Cloud
   • O tempo restante
   • As credenciais temporárias que você vai usar neste laboratório
   • Outras informações, se forem necessárias

2. Se você estiver usando o navegador Chrome, clique em Abrir console do Google Cloud ou clique com o botão direito do mouse e selecione Abrir link em uma janela anônima.

   O laboratório ativa os recursos e depois abre a página Fazer Login em outra guia.

   Dica: coloque as guias em janelas separadas lado a lado.

   Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.

3. Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Fazer login.

   {{{user_0.username | "Username"}}}

   Você também encontra o nome de usuário no painel Detalhes do Laboratório.

4. Clique em Próxima.

5. Copie a Senha abaixo e cole na caixa de diálogo de Olá.

   {{{user_0.password | "Password"}}}

   Você também encontra a senha no painel Detalhes do Laboratório.

6. Clique em Próxima.

   Importante: você precisa usar as credenciais fornecidas no laboratório, e não as da sua conta do Google Cloud. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.

7. Acesse as próximas páginas:

   • Aceite os Termos e Condições.
   • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
   • Não se inscreva em testes gratuitos.

Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.

Observação: para acessar os produtos e serviços do Google Cloud, clique no Menu de navegação ou digite o nome do serviço ou produto no campo Pesquisar.

Ativar o Cloud Shell

O Cloud Shell é uma máquina virtual com várias ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud. O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

1. Clique em Ativar o Cloud Shell na parte de cima do console do Google Cloud.

2. Clique nas seguintes janelas:

   • Continue na janela de informações do Cloud Shell.
   • Autorize o Cloud Shell a usar suas credenciais para fazer chamadas de APIs do Google Cloud.

Depois de se conectar, você verá que sua conta já está autenticada e que o projeto está configurado com seu Project_ID, . A saída contém uma linha que declara o projeto PROJECT_ID para esta sessão:

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

A gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

3. (Opcional) É possível listar o nome da conta ativa usando este comando:

gcloud auth list

4. Clique em Autorizar.

Saída:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Opcional) É possível listar o ID do projeto usando este comando:

gcloud config list project

Saída:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Observação: consulte a documentação completa da gcloud no Google Cloud no guia de visão geral da gcloud CLI.

Configure sua região e zona

Alguns recursos do Compute Engine estão em regiões e zonas. As regiões são localizações geográficas específicas onde você executa seus recursos. Todas elas têm uma ou mais zonas.

Execute os comandos gcloud a seguir no console do Cloud para definir a região e a zona padrão do laboratório:

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

Tarefa 1: configurar a infraestrutura

Para começar, você precisa se conectar a um cluster do Google Kubernetes Engine. Verifique se ele foi criado corretamente.

1. Defina a variável "ID do projeto":

export PROJECT_ID={{{project_0.startup_script.project | Project ID}}}

2. Use este comando para conferir o status do cluster:

gcloud container clusters list

O status do cluster será PROVISIONAMENTO.

3. Espere um pouco e execute o comando acima novamente até que o status mude para EM EXECUÇÃO. Isso pode levar alguns minutos.

4. Verifique se o cluster chamado central foi criado.

Também é possível monitorar o progresso no Console do Cloud. Acesse o Menu de navegação > Kubernetes Engine > Clusters.

5. Quando o status mudar para EM EXECUÇÃO, pegue as credenciais do cluster:

gcloud container clusters get-credentials central --zone $ZONE

Saída:

Fetching cluster endpoint and auth data. kubeconfig entry generated for central.

6. Verifique se os nós foram criados:

kubectl get nodes

A saída será parecida com esta:

NAME STATUS ROLES AGE VERSION gke-central-default-pool-5ff4130f-qz8v Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-ssd2 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-tz63 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-zfmn Ready 24d v1.27.2-gke.1200

Tarefa 2: implantar o aplicativo

A próxima tarefa inclui a implantação do aplicativo de microsserviços chamado Hipster Shop no cluster, para criar a carga de trabalho que você vai monitorar.

1. Execute este comando para clonar o repositório:

git clone https://github.com/xiangshen-dk/microservices-demo.git

2. Mude para o diretório microservices-demo:

cd microservices-demo

3. Instale o app usando kubectl:

kubectl apply -f release/kubernetes-manifests.yaml

4. Verifique se tudo está funcionando corretamente:

kubectl get pods

A saída será parecida com este exemplo:

NAME READY STATUS RESTARTS AGE adservice-55f94cfd9c-4lvml 1/1 Running 0 20m cartservice-6f4946f9b8-6wtff 1/1 Running 2 20m checkoutservice-5688779d8c-l6crl 1/1 Running 0 20m currencyservice-665d6f4569-b4sbm 1/1 Running 0 20m emailservice-684c89bcb8-h48sq 1/1 Running 0 20m frontend-67c8475b7d-vktsn 1/1 Running 0 20m loadgenerator-6d646566db-p422w 1/1 Running 0 20m paymentservice-858d89d64c-hmpkg 1/1 Running 0 20m productcatalogservice-bcd85cb5-d6xp4 1/1 Running 0 20m recommendationservice-685d7d6cd9-pxd9g 1/1 Running 0 20m redis-cart-9b864d47f-c9xc6 1/1 Running 0 20m shippingservice-5948f9fb5c-vndcp 1/1 Running 0 20m

5. Antes de seguir para a próxima etapa, execute o comando até que todos os pods estejam com o status Em execução.

Clique em Verificar meu progresso para conferir se esta etapa foi concluída. Implantar o aplicativo .

6. Execute o comando abaixo para ver o IP externo do aplicativo. Este comando só retorna o endereço IP depois da implantação do serviço. Por isso, pode ser necessário repetir o comando até que haja um endereço IP externo atribuído:

export EXTERNAL_IP=$(kubectl get service frontend-external | awk 'BEGIN { cnt=0; } { cnt+=1; if (cnt > 1) print $4; }')

7. Para terminar, confirme se o app está sendo executado:

curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP

A confirmação será parecida com esta:

200

Depois da implantação do app, você pode verificar o status no Console do Cloud.

Na página Kubernetes Engine > Cargas de trabalho, você pode checar se todos os pods estão corretos.

8. Selecione Gateways, serviços e entrada e clique na guia Serviços para verificar se todos eles estão funcionando bem. Fique nessa tela para configurar o monitoramento do aplicativo.

Tarefa 3: abrir o aplicativo

1. Role até front-end externo e clique no IP de Endpoints do serviço.

Isso abre o aplicativo e mostra uma página como esta:

Tarefa 4: criar uma métrica com base em registros

Agora, configure o Cloud Logging para criar uma métrica com base em registros. Essa é uma métrica personalizada no Cloud Monitoring, útil para a contagem do número de entradas de registro, além do monitoramento da distribuição de um valor entre eles. Neste caso, ela será usada para contar o número de erros no serviço de front-end. Depois, você poderá usar a métrica com base em registros nos painéis e nos alertas.

1. No Console do Cloud, acesse o Menu de navegação, abra a opção Logging e clique em Análise de registros.

2. Na caixa Criador de consultas, ative a opção Mostrar consulta e adicione o código a seguir:

resource.type="k8s_container" severity=ERROR labels."k8s-pod/app": "recommendationservice"

3. Clique em Executar consulta.

Com essa consulta, você encontra todos os erros do pod de front-end. No entanto, como ainda não há erros, não vai aparecer nenhum resultado.

4. Para criar a métrica com base em registros, clique no menu suspenso Ações e selecione Criar métrica.

5. Dê a ela o nome de Error_Rate_SLI e clique em Criar métrica para salvar:

A métrica vai aparecer listada em "Métricas definidas pelo usuário" na página "Métricas com base em registros".

Clique em Verificar meu progresso para conferir se esta etapa foi concluída. Criar uma métrica com base em registros.

Tarefa 5: criar uma política de alertas

Os alertas informam sobre os problemas dos seus apps na nuvem, para você resolver possíveis falhas em tempo oportuno. Agora você vai usar o Cloud Monitoring para monitorar a disponibilidade do serviço de front-end, elaborando uma política de alertas. Ela será baseada na métrica com base em registros criada anteriormente para os erros de front-end. Quando a condição da política de alertas for atendida, o Cloud Monitoring vai criar e apresentar um incidente no Console do Cloud.

1. No Menu de navegação, abra o Monitoring e clique em Alertas.

2. Depois de criar o espaço de trabalho, clique em Criar política na parte de cima.

Observação: se necessário, clique em Faça o teste! para usar o fluxo de criação de alertas atualizado.

3. Clique no menu suspenso Selecionar uma métrica. Desmarque a opção Ativo.

4. No campo Filtrar por nome do recurso e da métrica, digite Error_Rate.

5. Clique em Contêiner do Kubernetes > Métrica com base em registros. Selecione logging/user/Error_Rate_SLI e clique em Aplicar.

Na tela, você vai ver algo mais ou menos assim:

6. Defina a Função de janela de rolagem como Taxa.

7. Clique em Próxima.

8. Defina o Valor do limite em 0,5.

Como esperado, não existem falhas e o aplicativo atende ao Objetivo de Nível de Serviço (SLO) de disponibilidade.

9. Clique em Próxima novamente.

10. Desative a opção Usar canal de notificação.

11. Dê o nome de Error Rate SLI para o alerta e clique em Próxima.

12. Confirme que está tudo certo com o alerta e clique em Criar política.

Observação: você não vai criar um canal de notificação para este laboratório, mas precisa fazer isso para os aplicativos executados em produção. Com isso, será possível enviar notificações por e-mail, apps móveis, SMS, Pub/Sub e webhooks.

Clique em Verificar meu progresso para conferir se esta etapa foi concluída. Criar uma política de alertas.

Acionar um erro no aplicativo

Agora você vai usar um gerador de carga para criar algum tráfego para o aplicativo da Web. Um bug foi intencionalmente inserido nesta versão do aplicativo e, portanto, erros serão acionados a partir de um determinado volume de tráfego. Siga as etapas para identificar e corrigir o bug.

1. No menu de navegação, selecione Kubernetes Engine, depois escolha Gateways, serviços e entrada e clique na guia Serviços.

2. Encontre o serviço loadgenerator-external e clique no link endpoints.

Como alternativa, abra uma nova janela ou guia do navegador, copie/cole o IP no campo do URL, por exemplo: http://\[loadgenerator-external-ip\]

A página do gerador de carga Locust vai aparecer:

Locust é um gerador de carga de código aberto para testes de performance de apps da Web. Ele consegue simular um número de usuários acessando simultaneamente os endpoints do aplicativo a uma certa taxa.

1. Crie uma simulação com 300 usuários acessando o app, com uma taxa de hatch de 30. O Locust vai adicionar 30 usuários por segundo até chegar a 300 usuários.

2. Para o campo do host, use o frontend-external. Copie o URL da página Gateways, serviços e entrada. Não se esqueça de excluir a porta. Exemplo:

3. Clique no botão Start swarming. Em alguns segundos, você terá cerca de 300 usuários acessando o URL predefinido.

4. Clique na guia Falhas para ver se os erros já começaram a ocorrer. O número de erros vai ser grande, chegando a 500.

Nesse período, se você clicar em qualquer produto da página inicial, vai perceber uma lentidão fora do normal ou vai receber mensagens de erro como esta:

Como confirmar os erros e alertas do aplicativo

1. No Console do Cloud, acesse o Menu de navegação, clique em Monitoramento e, em seguida, Alertas. Um incidente relacionado a logging/user/Error_Rate_SLI vai aparecer. Se um incidente não for exibido imediatamente, aguarde um ou dois minutos e atualize a página. Pode levar até cinco minutos para que o alerta seja disparado.

2. Clique no link do incidente:

A página de detalhes vai ser aberta.

3. Na seção Registros, clique em Ver na Análise de registros e, no menu suspenso, selecione o ID do projeto para acessar os registros do pod.

4. No painel "Buscador de campo de registros", clique em Erro para consultar apenas as opções contendo falhas.

Como alternativa, clique no campo "Visualização da consulta", para abrir o Criador de Consultas. Em seguida, clique no menu suspenso Gravidade e adicione Erro à consulta. Clique no botão Adicionar e depois em Executar consulta. Nesse menu suspenso, é possível adicionar diferentes valores, de acordo com o nível de gravidade.

O resultado vai adicionar severity=ERROR à consulta. Depois disso, você vai ver todos os erros do pod recommendationservice.

5. Clique para expandir um evento de erro e ver informações detalhadas. Exemplo:

6. Clique para expandir textPayload.

7. Clique na mensagem de erro e selecione Adicionar campo à linha de resumo. Assim as mensagens de erro serão mostradas como um campo de resumo:

Em seguida, confirme se há muitos erros no serviço RecommendationService. Com base nas mensagens de erro, parece que RecommendationService não conseguiu se conectar a alguns serviços de downstream para receber produtos ou recomendações. Entretanto, a causa raiz dos erros não ficou clara.

Quando você analisa o diagrama da arquitetura, o RecommendationService fornece uma lista de recomendações para os serviços de Front-end. Mas tanto o serviço de Front-end quanto de RecommendationService invocam ProductCatalogService para uma lista de produtos.

Na próxima etapa, você vai analisar a presença de anomalias nas métricas do principal suspeito, ProductCatalogService. Seja qual for o caso, é possível detalhar os registros para conseguir insights.

Como solucionar problemas usando o painel e os registros do Kubernetes

1. Uma das opções de análise de métricas é na seção Kubernetes Engine do console do Monitoring (Menu de navegação > Monitoring> Painéis > GKE).

2. Consulte a seção Cargas de trabalho.

3. Acesse Kubernetes Engine > Cargas de trabalho > productcatalogservice. Você verá que o pod do serviço está constantemente falhando e reiniciando.

Agora, verifique se tem algo interessante acontecendo nos registros.

Há duas maneiras simples de acessar os registros do contêiner:

1. Clique na guia Registros para acesso rápido aos registros mais recentes. Em seguida, clique no botão do link externo, no canto superior direito do painel de registros, para voltar para a Análise de registros.

2. Na página de informações gerais, clique no link Registros do contêiner na seção Detalhes da Implantação.

A página Análise de Registros vai ser aberta novamente, mas com uma consulta predefinida, especificamente filtrada para os registros do contêiner que estavam sendo analisados no GKE.

No Visualizador de Registros, tanto as mensagens de registro quanto o histograma mostram que o contêiner está analisando os catálogos de produtos repetidamente, em um curto período de tempo. Isso não é muito eficiente.

Na parte de baixo dos resultados da consulta, também pode aparecer um erro do ambiente de execução, como este:

panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation

Isso pode estar causando falha no pod.

Para entender melhor o motivo, pesquise a mensagem de registro no código.

1. No Cloud Shell, execute este comando:

grep -nri 'successfully parsed product catalog json' src

A saída será semelhante a esta (com o nome do arquivo de origem e um número de linha):

src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")

2. Para acessar o arquivo de origem, clique no botão Abrir editor, no menu do Cloud Shell. Em seguida, clique em Abrir em uma nova janela. Se surgir o erro "Não é possível carregar o editor de código porque os cookies de terceiros estão desativados", clique no olho, na parte de cima da página do Chrome.

3. Clique no arquivo microservices-demo/src/productcatalogservice/server.go, role até a linha 237 e verifique se o método readCatalogFile contém a seguinte mensagem:

Com um pouco mais de pesquisa, você verá que, se a variável booleana reloadCatalog for verdadeira, o serviço vai recarregar e analisar o catálogo de produtos toda vez que for invocado, o que não é necessário.

Se você pesquisar a variável reloadCatalog no código, verá que ela é controlada pela variável de ambiente ENABLE_RELOAD e grava uma mensagem de registro do próprio estado.

Verifique os registros novamente, adicionando essa mensagem à sua consulta, e determine se já existe alguma entrada.

1. Volte para a guia com a Análise de Registros está aberta e adicione esta linha à consulta:

jsonPayload.message:"catalog reloading"

A consulta completa será:

resource.type="k8s_container" resource.labels.location="{{{project_0.startup_script.zone | ZONE}}}" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

2. Clique em Executar consulta novamente e procure a mensagem "Ativar recarregamento de catálogo" no registro do contêiner. Ela confirma que o recurso de recarregamento de catálogo está ativado.

Agora temos certeza de que o erro de front-end foi causado pela sobrecarga de carregar repetidamente o catálogo a cada solicitação. Quando você aumentou a carga, esse overhead causou a falha no serviço e gerou o erro.

Tarefa 6: corrigir o problema e verificar o resultado

Com base no código e o conteúdo dos registros, você vai tentar corrigir o problema desativando o recarregamento do catálogo. Agora você vai remover a variável de ambiente ENABLE_RELOAD do serviço do catálogo de produtos. Depois de fazer as mudanças de variável, você poderá implantar o aplicativo novamente e verificar se as alterações solucionaram o problema.

1. Clique no botão Abrir terminal para voltar para o terminal do Cloud Shell, se ele estiver fechado.

2. Execute este comando:

grep -A1 -ni ENABLE_RELOAD release/kubernetes-manifests.yaml

A saída vai mostrar o número da linha da variável de ambiente no arquivo de manifesto:

373: - name: ENABLE_RELOAD 374- value: "1"

3. Exclua essas duas linhas para desativar o recarregamento, executando:

sed -i -e '373,374d' release/kubernetes-manifests.yaml

4. Em seguida, reaplique o arquivo de manifesto:

kubectl apply -f release/kubernetes-manifests.yaml

Neste caso, apenas productcatalogservice está configurado. Os outros serviços não foram alterados.

5. Volte para a página Detalhes da implantação (Menu de navegação > Kubernetes Engine > Cargas de trabalho > productcatalogservice) e aguarde até que o pod seja executado com sucesso. Aguarde de 2 a 3 minutos ou até que seja possível confirmar que ele parou de falhar.

6. Se você clicar no link Registros do contêiner novamente, vai perceber que as mensagens repetidas de successfully parsing the catalog json não estão mais lá:

7. Se você voltar para o URL do webapp e clicar nos produtos da página inicial, ele estará mais responsivo e nenhum erro de HTTP será exibido.

8. Volte para o gerador de carga e clique no botão Redefinir estatísticas, no canto superior direito. A porcentagem de falha será redefinida e não vai aumentar mais.

Todas as verificações acima indicam que o problema foi corrigido. Se ainda aparecer o erro 500, aguarde mais alguns minutos e tente clicar em um produto novamente.

Parabéns!

Você usou o Cloud Logging e o Cloud Monitoring para encontrar um erro em uma versão do app de demonstração de microsserviços que foi propositalmente configurada de forma incorreta. Esse é um processo de solução de problemas semelhante ao que pode ser usado para reduzir problemas em apps do GKE em um ambiente de produção.

Primeiro, você implantou o app no GKE e configurou uma métrica e alertas para os erros de front-end. Em seguida, gerou uma carga e observou que o alerta foi acionado. A partir do alerta, você restringiu o problema a determinados serviços usando o Cloud Logging. Depois, usou o Cloud Monitoring e a IU do GKE para ver as métricas dos serviços do GKE. Para corrigir o problema, você implantou uma configuração atualizada no GKE e confirmou que a correção resolveu os erros nos registros.

Próximas etapas / Saiba mais

• O laboratório tem base neste post do blog sobre como usar o Logging para apps executados no GKE.
• O post complementar, que fala sobre como as equipes do DevOps podem usar o Cloud Monitoring e o Logging para encontrar problemas com agilidade, também é uma leitura interessante.

Treinamento e certificação do Google Cloud

Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.

Manual atualizado em 21 de fevereiro de 2025.

Laboratório testado em 21 de fevereiro de 2025.

Copyright 2025 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.