![](https://cdn.qwiklabs.com/assets/labs/start_lab-f45aca49782d4033c3ff688160387ac98c66941d.png)
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you restart it, you'll have to start from the beginning.
- On the top left of your screen, click Start lab to begin
Deploy Application
/ 30
Create a logs-based metric
/ 30
Create an alerting policy
/ 40
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.
Neste laboratório, você vai aprender a:
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.
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:
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ê vai encontrar o seguinte:
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.
Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Fazer login.
Você também encontra o Nome de usuário no painel Detalhes do laboratório.
Clique em Seguinte.
Copie a Senha abaixo e cole na caixa de diálogo de boas-vindas.
Você também encontra a Senha no painel Detalhes do laboratório.
Clique em Seguinte.
Acesse as próximas páginas:
Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.
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.
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:
gcloud
é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.
Clique em Autorizar.
A saída será parecida com esta:
Saída:
Saída:
Exemplo de saída:
gcloud
, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.
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:
Conecte-se a um cluster do Google Kubernetes Engine e confirme se ele foi criado corretamente.
O status do cluster será PROVISIONAMENTO.
Espere um pouco e execute o comando acima novamente até que o status seja EM EXECUÇÃO. Isso pode demorar alguns minutos.
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.
Saída:
A saída será parecida com esta:
Implante um aplicativo de microsserviços chamado Hipster Shop no cluster para criar a carga de trabalho que será monitorada.
microservices-demo
:kubectl
:A saída será parecida com este exemplo:
Clique em Verificar meu progresso para conferir o objetivo.
A confirmação será parecida com esta:
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.
Isso abre o aplicativo e mostra uma página como esta:
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.
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.
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.
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.
No menu Navegação, abra o Monitoring e clique em Alertas.
Depois da criação do espaço de trabalho, clique em Criar política na parte de cima.
Clique no menu suspenso Selecionar uma métrica. Desative a opção Mostrar apenas métricas e recursos ativos
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, algo assim deve aparecer:
Defina a Função de janela de rolagem como Taxa
.
Clique em Próxima.
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.
Clique em Próxima novamente.
Desative a opção Usar canal de notificação.
Forneça um nome de alerta como Error Rate SLI
e clique em Próxima.
Analise o alerta e clique em Criar política.
Clique em Verificar meu progresso para conferir o objetivo.
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.
No menu Navegação, selecione Kubernetes Enginee, em seguida, Serviço e entrada.
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.
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.
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:
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:
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.
Clique no link do incidente:
A página de detalhes vai ser aberta.
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.
Expanda o textPayload
.
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.
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).
Consulte a seção Cargas de trabalho.
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:
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:
Isso pode estar causando falha no pod.
Para entender melhor o motivo, pesquise a mensagem de registro no código.
A saída será semelhante a esta (com o nome do arquivo de origem e um número de linha):
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.
A consulta completa será:
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.
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.
Clique no botão Abrir terminal para voltar para o terminal do Cloud Shell se ele estiver fechado.
Execute este comando:
A saída vai mostrar o número da linha da variável de ambiente no arquivo de manifesto:
Neste caso, apenas productcatalogservice está configurado. Os outros serviços não foram alterados.
successfully parsing the catalog json
repetidas não vão mais aparecer: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.
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.
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.
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.
Continue com sua Quest Cloud Logging no Kubernetes Engine ou confira estas sugestões:
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 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.