GSP736

Visão geral
O Cloud Logging e o Cloud Monitoring são produtos completos e totalmente integrados ao Google Kubernetes Engine (GKE). 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ê aprenderá a fazer o seguinte:
- 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
-
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
-
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.
-
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.
-
Clique em Próxima.
-
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.
-
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.
-
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.
-
Clique em Ativar o Cloud Shell
na parte de cima do console do Google Cloud.
-
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.
- (Opcional) É possível listar o nome da conta ativa usando este comando:
gcloud auth list
- Clique em Autorizar.
Saída:
ACTIVE: *
ACCOUNT: {{{user_0.username | "ACCOUNT"}}}
To set the active account, run:
$ gcloud config set account `ACCOUNT`
- (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.
Tarefa 1: Realizar a configuração da infraestrutura
Conecte a um cluster do Google Kubernetes Engine e confirme se ele foi criado corretamente.
- Use este comando para conferir o status do cluster:
gcloud container clusters list
O status do cluster será PROVISIONAMENTO.
-
Espere um pouco e execute o comando acima novamente até que o status mude para EM EXECUÇÃO. Isso pode levar alguns minutos.
-
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.
- Quando o status do cluster mudar para EM EXECUÇÃO, execute o seguinte comando para receber as credenciais do cluster:
gcloud container clusters get-credentials central --zone {{{project_0.startup_script.zone | ZONE}}}
Saída:
Fetching cluster endpoint and auth data.
kubeconfig entry generated for central.
- Execute o seguinte comando para verificar se os nós foram criados:
kubectl get nodes
A saída será parecida com esta:
Saída:
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
Ativar o Gemini Code Assist no Cloud Shell IDE
Você pode usar o Gemini Code Assist em um ambiente de desenvolvimento integrado (IDE), como o Cloud Shell, para receber orientações sobre o código ou resolver problemas com ele. Antes de começar a usar o Gemini Code Assist, você precisa ativá-lo.
- No Cloud Shell, ative a API Gemini para Google Cloud com o seguinte comando:
gcloud services enable cloudaicompanion.googleapis.com
- Clique em Abrir editor na barra de ferramentas do Cloud Shell.
Observação: para abrir o editor do Cloud Shell, clique em Abrir editor na barra de ferramentas do Cloud Shell. Você pode alternar o Cloud Shell e o editor de código clicando em Abrir editor ou Abrir terminal, conforme necessário.
-
No painel à esquerda, clique no ícone Configurações e, na visualização Configurações, pesquise Gemini Code Assist.
-
Localize e verifique se a caixa de seleção Geminicodeassist: Ativar está marcada e feche as Configurações.
-
Clique em Cloud Code - Sem projeto na barra de status na parte de baixo da tela.
-
Autorize o plug-in conforme instruído. Se um projeto não for selecionado automaticamente, clique em Selecionar um projeto do Google Cloud e escolha .
-
Verifique se o projeto do Google Cloud () aparece na mensagem de status do Cloud Code na barra de status.
Tarefa 2: Implantar um 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.
- Execute este comando para clonar o repositório:
git clone https://github.com/xiangshen-dk/microservices-demo.git
- Mude para o diretório
microservices-demo com o seguinte comando:
cd microservices-demo
- No editor do Cloud Shell, abra o explorador de arquivos e navegue até microservices-demo > release > kubernetes-manifests.yaml.
Você pode usar os recursos com tecnologia de IA do Gemini Code Assist para fazer alterações no código diretamente no editor. Nesse caso, você decide pedir ajuda ao Gemini Code Assist para explicar o arquivo kubernetes-manifests.yaml para ajudar na integração de um novo membro da equipe.
-
Abra o arquivo kubernetes-manifests.yaml. Essa ação ativa o Gemini Code Assist, como indicado pela presença do ícone
no canto superior direito do editor.
-
Clique no ícone Gemini Code Assist: Ações Inteligentes
e selecione Explicar isto.
-
O Gemini Code Assist abre um painel de chat com o comando Explicar isto preenchido. Na caixa de texto inline do chat do Code Assist, substitua o comando preenchido previamente pelo seguinte e clique em Enviar:
Como arquiteto do Kubernetes na Cymbal AI, forneça uma explicação formal e abrangente do arquivo kubernetes-manifests.yaml para a integração de um novo membro da equipe.
Sua explicação deve:
* Detalhar os principais componentes usados no arquivo de configuração
* Descrever os principais serviços e suas funções
* Descrever os elementos de configurações comuns
* Descrever o que a configuração implanta
Para as melhorias sugeridas, não atualize este arquivo.
A explicação do código no arquivo kubernetes-manifests.yaml aparece na conversa do Gemini Code Assist.
- Execute o comando a seguir para instalar o app usando
kubectl:
kubectl apply -f release/kubernetes-manifests.yaml
- Execute o seguinte comando para confirmar se tudo está funcionando corretamente:
kubectl get pods
A saída será parecida com o exemplo a seguir.
Saída:
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
- Antes de seguir para a próxima etapa, execute novamente o comando até que todos os pods estejam com o status Em execução.
Clique em Verificar meu progresso para conferir o objetivo.
Implantar um aplicativo
- Execute o seguinte comando para acessar o IP externo do aplicativo. Este comando retorna apenas um endereço IP depois da implantação do serviço. Portanto, 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; }')
- Por fim, execute o seguinte comando para confirmar se o app está em execução:
curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP
Sua confirmação deve ser semelhante à seguinte saída.
Saída:
200
Depois que o aplicativo for implantado, acesse o console do Cloud e confira o status.
Na página Kubernetes Engine > Cargas de trabalho, todos os pods vão aparecer corretamente.

- Selecione Gateways, serviços e entrada e clique na guia Serviços para verificar se todos eles estão funcionando bem. Permaneça nessa tela para configurar o monitoramento do aplicativo.
Tarefa 3: abrir o aplicativo
- Role até front-end externo e clique no IP de Endpoints do serviço.

Isso vai abrir o aplicativo e exibir uma página como esta:

Tarefa 4: criar uma métrica com base em registros
Para essa tarefa, vai configurar 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.
- No console do Cloud, acesse o menu de navegação, abra a opção Logging e clique em Análise de registros.

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

- 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, nenhum resultado é exibido.
- Para criar a métrica com base em registros, clique no menu suspenso Ações e selecione Criar métrica.

- 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. Criar 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.
Nesta tarefa, 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.
-
No Menu de navegação, abra o Monitoring e clique em Alertas.
-
Depois de criar o 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.
-
Clique no menu suspenso Selecionar uma métrica. Desmarque a caixa de seleção Ativo.
-
No campo Filtrar por nome do recurso e da métrica, digite Error_Rate.
-
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:

-
Defina a Função de janela de rolagem como Taxa.
-
Clique em Próxima.
-
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.
-
Clique em Próxima novamente.
-
Desative a opção Usar canal de notificação.
-
Dê o nome de Error Rate SLI para o alerta e clique em Próxima.
-
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 o objetivo. Criar uma política de alertas.
Acionar um erro do aplicativo
Nesta seção, você vai usar um gerador de carga para criar 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.
-
No menu de navegação, selecione Kubernetes Engine, depois escolha Gateways, serviços e entrada e clique na guia Serviços.
-
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.
-
Crie uma simulação com 300 usuários acessando o app, com uma taxa de hatch de 30. O Locust adiciona 30 usuários por segundo até chegar a 300 usuários.
-
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:

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

- Clique na guia Falhas para verificar se já começaram a ocorrer falhas. 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:

Confirmar os erros e alertas do aplicativo
-
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.
-
Clique no link do incidente:

A página de detalhes vai ser aberta.
- 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.

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

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

-
Clique para expandir textPayload.
-
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.
Solucionar problemas usando o painel e os registros do Kubernetes
-
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).
-
Consulte a seção Cargas de trabalho.
-
Acesse Kubernetes Engine > Cargas de trabalho > productcatalogservice. É possível 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:
- 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.

- 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.
- No terminal do Cloud Shell, execute os comandos a seguir:
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):
Saída:
src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")
- 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.

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

- Com o arquivo
server.go aberto e o Gemini Code Assist ativado no ambiente de desenvolvimento integrado, observe a presença do ícone
no canto superior direito do editor.
Nesse caso, você decide pedir ao Gemini Code Assist para explicar a implementação do servidor ao novo membro da equipe.
-
Clique no ícone Gemini Code Assist: Ações Inteligentes
e selecione Explicar isto.
-
O Gemini Code Assist abre um painel de chat com o comando Explicar isto preenchido. Na caixa de texto inline do chat do Code Assist, substitua o comando preenchido previamente pelo seguinte e clique em Enviar:
Você é arquiteto do Kubernetes na Cymbal AI. Um novo membro da equipe não conhece essa implementação de servidor. Explique o arquivo server.go em detalhes, apresentando os principais componentes usados no código.
Para as melhorias sugeridas, não atualize este arquivo.
A explicação do código no arquivo server.go aparece no chat do Gemini Code Assist.
Verifique os registros novamente adicionando uma mensagem à sua consulta e determine se já existe alguma entrada.
- Volte para a guia em que a Análise de registros está aberta e adicione a linha a seguir à consulta:
jsonPayload.message:"catalog reloading"
A consulta completa no criador de consultas 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"
- 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.
Nesta tarefa, 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ê vai implantar o aplicativo novamente e verificar se as alterações solucionaram o problema.
-
Clique no botão Abrir terminal para voltar para o terminal do Cloud Shell, se ele estiver fechado.
-
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:
Saída:
373: - name: ENABLE_RELOAD
374- value: "1"
- Exclua essas duas linhas para desativar o recarregamento executando o seguinte comando:
sed -i -e '373,374d' release/kubernetes-manifests.yaml
- Em seguida, execute o seguinte comando para reaplicar 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.
- 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.

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

-
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.
-
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 essas verificações 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 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.
- 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 26 de agosto de 2025.
Laboratório testado em 14 de outubro 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.