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 conferir 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 aplicativo 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 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 laboratório. Se for preciso pagar por ele, uma caixa de diálogo vai aparecer para você selecionar a forma de pagamento.
À direita, você encontra o painel Configuração e acesso ao laboratório com as seguintes informações:
- O botão Abrir console do Google Cloud
- As credenciais temporárias (nome de usuário e senha) que você vai usar no laboratório
- Outros dados, se necessários
O timer do laboratório fica na parte de cima da página e mostra o tempo restante.
-
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 "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 Login.
{{{user_0.username | "Username"}}}
Você também encontra o nome de usuário no painel Configuração e acesso ao laboratório.
-
Clique em Avançar.
-
Copie a Senha abaixo e cole na caixa de diálogo Olá!.
{{{user_0.password | "Password"}}}
Você também encontra a senha no painel Configuração e acesso ao laboratório.
-
Clique em Avançar.
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, talvez 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 sem custo financeiro.
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: configurar a 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 comando a seguir para receber as credenciais do cluster:
gcloud container clusters get-credentials central --zone {{{project_0.startup_script.zone | ZONE}}}
Resultado:
Fetching cluster endpoint and auth data.
kubeconfig entry generated for central.
- Execute o comando a seguir para verificar se os nós foram criados:
kubectl get nodes
O resultado será parecido com o exemplo a seguir.
Resultado:
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.
-
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 acesse microservices-demo > release > kubernetes-manifests.yaml.
É possível usar os recursos com tecnologia de IA do Gemini Code Assist para fazer alterações no código diretamente no editor. Nesse caso, você pede para o Gemini Code Assist 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 Explique isso.
-
O Gemini Code Assist abre um painel de conversa com o comando Explique isso preenchido. Na caixa de texto inline da conversa do Code Assist, substitua o comando preenchido previamente pelo exibido abaixo 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 as respectivas 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 aplicativo usando
kubectl:
kubectl apply -f release/kubernetes-manifests.yaml
- Execute o comando a seguir para confirmar se tudo está funcionando corretamente:
kubectl get pods
O resultado será parecido com o exemplo a seguir.
Resultado:
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 comando a seguir 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 comando a seguir para confirmar se o aplicativo está em execução:
curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP
A confirmação deve ser semelhante ao resultado a seguir.
Resultado:
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 corretamente. Permaneça nessa tela para configurar o monitoramento do aplicativo.
Tarefa 3: abrir o aplicativo
- Role até frontend-external 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, você vai configurar o Cloud Logging para criar uma métrica com base em registros. Essa é uma métrica personalizada do Cloud Monitoring, útil para a contagem do número de entradas de registros, além do monitoramento da distribuição de um valor entre eles.
Nesse caso, use a métrica com base em registros para contar o número de erros no serviço de front-end. Depois você poderá usar a métrica nos painéis e nos alertas.
- No console do Cloud, acesse o Menu de navegação, abra Logging e clique em Análise de Registros.

- Ative a opção Mostrar consulta. Na caixa Criador de Consultas, adicione esta consulta:
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 dos 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 exibir 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.
A tela será semelhante a esta:

-
Defina a Função de janela de rolagem como Taxa.
-
Clique em Próximo.
-
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óximo novamente.
-
Desative a opção Usar canal de notificação.
-
Dê o nome de Error Rate SLI para o alerta e clique em Próximo.
-
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, aplicativos 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, um determinado volume de tráfego vai acionar erros. Siga as etapas abaixo 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 dos 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 simula vários usuários alcançando simultaneamente os endpoints do aplicativo a uma certa taxa.
-
Crie uma simulação com 300 usuários acessando o aplicativo, 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, cerca de 300 usuários vão acessar os URLs predefinidos.

- Clique na guia Falhas para verificar se já começaram a ocorrer falhas. Você verá 500 erros.

No entanto, se você clicar em qualquer produto na página inicial, perceberá que ele está lento ou verá erros como este:

Confirmar os alertas e erros do aplicativo
-
No console, acesse o Menu de navegação, clique em Monitoring e, em seguida, 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. O alerta pode levar até cinco minutos para ser disparado.
-
Clique no link do incidente:

A página de detalhes vai ser aberta.
- Na seção "Registros", clique em Visualizar na Análise de Registros e, no menu suspenso, selecione o ID do projeto para acessar os registros do pod.

- 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. Nesse menu suspenso, é possível adicionar diferentes valores de gravidade.
O resultado vai adicionar severity=ERROR à consulta. Depois que você fizer isso, os erros do pod "recommendationservice" serão exibidos.

- Confira os detalhes do erro expandindo um evento de erro. 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ê revisita o diagrama de 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 o 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.
Usar o painel e os registros do Kubernetes para solucionar problemas
-
Um dos primeiros lugares para analisar as métricas é na seção Kubernetes Engine do console do Monitoring (Menu 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 falha e reinicia constantemente.

Depois, confira se há algo interessante nos registros.
Há duas maneiras simples de acessar os registros do contêiner:
- 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.

- Na página de visão geral de "Detalhes da implantação", clique no link Registros do contêiner.

A página "Análise de Registros" vai ser aberta novamente, mas com uma consulta predefinida, especificamente filtrada com 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 analisa 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 de tempo 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 o comando a seguir:
grep -nri 'successfully parsed product catalog json' src
O resultado será parecido com o exemplo a seguir (com o nome do arquivo de origem e um número de linha).
Resultado:
src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")
- Para visualizar o arquivo de origem, clique no botão Abrir editor no menu do Cloud Shell. Em seguida, clique em Abrir em nova janela (se o erro "Não é possível carregar o editor de código porque os cookies de terceiros estão desativados" for exibido, 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 esta mensagem:

Indo um pouco mais além, 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. Isso não parece necessário.
Se você pesquisar a variável reloadCatalog no código, verá que ela é controlada pela variável de ambiente ENABLE_RELOAD e que ela tem 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 (IDE), o ícone
vai aparecer 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 Explique isso.
-
O Gemini Code Assist abre um painel de conversa com o comando Explique isso preenchido. Na caixa de texto inline da conversa do Code Assist, substitua o comando preenchido previamente pelo exibido abaixo e clique em Enviar:
Você trabalha com a arquitetura 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, detalhando 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 na conversa do Gemini Code Assist.
Adicione uma mensagem à consulta para verificar os registros novamente 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 pelo overhead do carregamento repetido do catálogo a cada solicitação. Ao aumentar 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 no conteúdo dos registros, tente desativar o recarregamento de catálogo para corrigir o problema.
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
O resultado vai mostrar o número da linha da variável de ambiente no arquivo de manifesto.
Resultado:
373: - name: ENABLE_RELOAD
374- value: "1"
- Execute o comando abaixo para excluir essas duas linhas e desativar o recarregamento:
sed -i -e '373,374d' release/kubernetes-manifests.yaml
- Em seguida, execute o comando a seguir para reaplicar o arquivo de manifesto:
kubectl apply -f release/kubernetes-manifests.yaml
Nesse 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. 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, verá que as mensagens
successfully parsing the catalog json repetidas não são mais exibidas:

-
Se você voltar para o URL do app da web e clicar nos produtos da página inicial, verá que ele está mais responsivo e nenhum erro de HTTP foi 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 configurada de maneira incorreta. Esse é um processo de solução de problemas semelhante ao que pode ser usado para reduzir problemas de aplicativos do GKE em um ambiente de produção.
Primeiro você implantou o aplicativo 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. Com o alerta, você restringiu o problema a determinados serviços usando o Cloud Logging. Depois usou o Cloud Monitoring e a interface do GKE para exibir 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 é baseado neste post do blog sobre como usar o Logging para aplicativos executados no GKE.
- O próximo post 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 2026 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.