GSP736

Informações gerais

O Cloud Logging e sua ferramenta complementar, 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, além de algumas práticas recomendadas para a coleta de registros usando casos de uso comuns de geração de registros.

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 que está em execução no GKE

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

Para usar um exemplo concreto, você vai resolver problemas de uma amostra de 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 usando um gerador de carga e, em seguida, usar o Logging, o Monitoring e o GKE para notificar o erro (alerta/métricas), identificar a causa raiz com Logging e corrigir o problema/confirmar a correção com o Logging e o Monitoring.

Configuração e requisitos

Antes de clicar no botão Start Lab

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é iniciado quando você clica em Começar o 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, 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 ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e a conta de estudante, o que poderia causar cobranças extras na sua conta pessoal.

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

Observação: não use seu projeto ou conta do Google Cloud neste laboratório para evitar cobranças extras na sua conta.

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, você verá um pop-up para selecionar a forma de pagamento. No painel Detalhes do laboratório à esquerda, você verá o seguinte:

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

2. Clique em Abrir Console do Google. O laboratório ativa recursos e depois abre outra guia com a página Fazer login.

   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. Caso seja preciso, copie o Nome de usuário no painel Detalhes do laboratório e cole esse nome na caixa de diálogo Fazer login. Clique em Avançar.

4. Copie a Senha no painel Detalhes do laboratório e a cole na caixa de diálogo Olá. Clique em Avançar.

   Importante: você precisa usar as credenciais do painel à esquerda. Não use suas credenciais do Google Cloud Ensina. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.

5. 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 GCP vai ser aberto nesta guia.

Observação: para ver uma lista dos produtos e serviços do Google Cloud, clique no Menu de navegação no canto superior esquerdo.

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.

Depois de se conectar, vai notar 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 YOUR_PROJECT_ID

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

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

gcloud auth list

3. Clique em Autorizar.

4. A saída será parecida com esta:

Saída:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net 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_ID>

Exemplo de saída:

[core] project = qwiklabs-gcp-44776a13dea667a6 Observação: para conferir a documentação completa da gcloud, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.

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

Conecte-se a um cluster do Google Kubernetes Engine e confirme 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 seja EM EXECUÇÃO. Isso pode demorar alguns minutos.

4. Verifique se o cluster chamado central foi criado.

Também é possível monitorar o progresso no Console do Cloud navegando até o menu Navegação > Kubernetes Engine > Clusters.

5. Quando o status mudar para EM EXECUÇÃO, consulte 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.

7. 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

Implante um aplicativo de microsserviços chamado Hipster Shop no cluster para criar a carga de trabalho que será monitorada.

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 o objetivo. Implante o aplicativo .

6. Execute o comando abaixo para exibir o IP externo do aplicativo. Este comando retorna apenas um 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. Agora verifique se o app está em execução:

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

A confirmação será parecida com esta:

200

Depois que o aplicativo for implantado, acesse o Console do Cloud e visualize o status.

Na página Kubernetes Engine > Cargas de trabalho, é possível conferir se todos os pods estão corretos.

8. Agora, clique em Serviços e entrada e verifique se todos os serviços estão corretos. Permaneça 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 composta por entradas de registro. As métricas com base em registros são boas para contar o número de entradas de registro e rastrear a distribuição de um valor. Neste caso, você vai usar a métrica com base em registros para contar o número de erros no serviço de front-end. Depois, use a métrica nos painéis e nos alertas.

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

2. Ative Mostrar consulta na caixa Criador de consultas e adicione esta consulta:

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

3. Selecione Executar consulta.

A consulta que você está usando permite encontrar todos os erros do pod de front-end. No entanto, como ainda não há erros, nenhum resultado é exibido.

4. Para criar a métrica com base em registros, clique em Criar métrica.

5. Nomeie a métrica como Error_Rate_SLI e clique em Criar métrica para salvar a métrica com base em registros:

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 o objetivo. Crie uma métrica com base em registros.

Tarefa 5: criar uma política de alertas

O alerta proporciona reconhecimento oportuno de problemas nos seus aplicativos em nuvem para que você possa resolvê-los rapidamente. Agora você vai usar o Cloud Monitoring para monitorar a disponibilidade do serviço de front-end ao criar uma política de alertas baseada na métrica com base em registros de erros do front-end criada anteriormente. Quando a condição da política de alertas é atendida, o Cloud Monitoring cria e exibe um incidente no Console do Cloud.

1. No menu Navegação, abra o Monitoring e clique em Alertas.

2. Depois da criação do espaço de trabalho, clique em Criar política na parte de cima.

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

3. Clique no menu suspenso Selecionar uma métrica. Desative a opção Mostrar apenas métricas e recursos ativos

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, algo assim deve aparecer:

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

7. Clique em Próxima.

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

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. Forneça um nome de alerta como Error Rate SLI e clique em Próxima.

12. Analise 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, o que permite que você envie notificações por e-mail, por apps para dispositivos móveis, SMS, Pub/Sub e webhooks.

Clique em Verificar meu progresso para conferir o objetivo. Crie uma política de alertas.

Acionar um erro do aplicativo

Agora você vai usar um gerador de carga para criar algum tráfego para o aplicativo da Web. Como há um bug que foi intencionalmente introduzido nesta versão do aplicativo, uma determinada quantidade de volume de tráfego vai acionar erros. Realize as etapas para identificar e corrigir o bug.

1. No menu Navegação, selecione Kubernetes Enginee, em seguida, Serviço e entrada.

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, que permite carregar e testar um app da Web. Ele pode simular vários usuários alcançando simultaneamente os endpoints do aplicativo a uma certa taxa.

1. Simule 300 usuários alcançando 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 Serviços e entrada. Não esqueça de excluir a porta. Exemplo:

3. Clique no botão Start swarming. Em alguns segundos, você deverá ter cerca de 300 usuários alcançando os URLs predefinidos.

4. Clique na guia Falhas para conferir se já começaram a ocorrer falhas. Você vai perceber um grande número de erros 500.

Enquanto isso, se você clicar em qualquer produto na página inicial, vai perceber que ele está lento ou 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 depois em 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. Clique no link MOSTRAR REGISTROS para acessar os registros do pod.

4. Clique em Erro no painel "Explorador do campo de registros" para consultar apenas os erros.

Como alternativa, clique no campo "Visualização da consulta" para mostrar 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. O menu suspenso permite adicionar vários valores de gravidade.

O resultado vai adicionar severity=ERROR à consulta. Depois que você fizer isso, os erros do pod recommendationservice serão vão aparecer.

5. Confira os detalhes do erro expandindo um evento de erro. Exemplo:

6. Expanda o textPayload.

7. Clique na mensagem de erro e selecione Adicionar campo à linha de resumo para que as mensagens de erro apareçam como um campo de resumo:

Em seguida, confirme se há realmente muitos erros no serviço RecommendationService. Considerando as 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. No entanto, 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 na métrica 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. Um dos primeiros lugares para analisar as 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. Navegue até Kubernetes Engine > Cargas de trabalho > productcatalogservice. É possível confirmar que o pod do serviço está constantemente falhando e reiniciando.

Confira se há algo interessante nos registros.

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

1. Clique na guia Registros para visualizar rapidamente os 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 página "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 repetidamente os catálogos de produtos em um curto período de tempo. Isso não é muito eficiente.

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

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 o erro "Não é possível carregar o editor de código porque os cookies de terceiros estão desativados" aparecer, 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:

Você poderá confirmar 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, confirmará que ela é controlada pela variável de ambiente ENABLE_RELOAD e tem 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 em que 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 que aconteceu ao carregar o catálogo para todas as solicitações. Quando você aumentou a carga, isso fez com que o serviço falhasse e gerasse o erro.

Tarefa 6: corrigir o problema e verificar o resultado

Considerando o código e o conteúdo dos registros, tente 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, reimplante o aplicativo e verifique se as mudanças solucionaram o problema observado.

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 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 successfully parsing the catalog json repetidas não vão mais aparecer:

7. Se você voltar para o URL do webapp e clicar nos produtos na 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 o erro 500 ainda for exibido, 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 configurada de maneira 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ê reduziu 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.

Terminar a Quest

Este laboratório autoguiado faz parte da Quest Google Cloud's Operations Suite on GKE. Uma Quest é uma série de laboratórios relacionados que formam um programa de aprendizado. Ao concluir uma Quest, você ganha um selo como reconhecimento da sua conquista. É possível publicar os selos e incluir um link para eles no seu currículo on-line ou nas redes sociais. Inscreva-se nesta Quest e receba créditos de conclusão imediatamente. Consulte o catálogo do Google Cloud Ensina para conferir todas as Quests disponíveis.

Começar o próximo laboratório

Continue com sua Quest Cloud Logging no Kubernetes Engine ou confira estas sugestões:

• Operações do Cloud para GKE(em inglês)
• Como resolver problemas de confiabilidade no site com o Cloud Monitoring APM

Próximas etapas / Saiba mais

• O laboratório tem base nesta postagem do blog sobre como usar o Logging para os apps em execução no GKE.
• A próxima postagem sobre como as equipes do DevOps podem usar o Cloud Monitoring e o Logging para encontrar problemas com rapidez também pode ser 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 31 de julho de 2023

Laboratório testado em 31 de julho de 2023

Copyright 2024 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.