1. Introdução
Última atualização:28/07/2023
O que é o pacote de operações do Google Cloud?
O pacote de operações do Google Cloud é uma plataforma em que você pode monitorar, solucionar problemas e melhorar o desempenho dos aplicativos no seu ambiente do Google Cloud. Os principais pilares do pacote de operações do Cloud incluem o Cloud Monitoring, o Cloud Logging e o Cloud Tracing.
Confira este vídeo para ter uma visão geral de alto nível das operações do Google Cloud.
O que você vai criar
Neste codelab, você vai implantar uma API de amostra no Google Cloud. Em seguida, você vai conhecer e configurar vários recursos do Cloud Monitoring em relação à API.
O que você vai aprender
- Uso do Cloud Shell do Google Cloud para implantar um exemplo de aplicativo no Cloud Run.
- Uso dos recursos do Google Cloud Monitoring, como painéis, alertas, verificações de tempo de atividade, monitoramento de SLI/SLO e muito mais.
O que é necessário
- Uma versão recente do Chrome (74 ou mais recente)
- Uma conta e um projeto do Google Cloud
2. Configuração e requisitos
Configuração de ambiente autoguiada
Se você ainda não tem uma Conta do Google (Gmail ou Google Apps), crie uma. Faça login no Console do Google Cloud Platform ( console.cloud.google.com) e crie um novo projeto.
- O nome do projeto é o nome de exibição para os participantes dele. É uma string de caracteres não usada pelas APIs do Google É possível atualizar o local a qualquer momento.
- O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser alterado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto.
- Para sua informação, há um terceiro valor, um número de projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
Atenção: o ID do projeto precisa ser globalmente exclusivo e não pode ser usado por outras pessoas após a seleção. Você é o único usuário com esse ID. Mesmo que um projeto seja excluído, o ID não poderá ser usado novamente.
- Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não será muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou o projeto inteiro. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.
Configuração do Google Cloud Shell
Embora o Google Cloud e o Google Cloud Trace possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
Para ativar o Cloud Shell no Console do Cloud, basta clicar em "Ativar o Cloud Shell". Leva apenas alguns instantes para provisionar e se conectar ao ambiente.
Se você nunca iniciou o Cloud Shell, vai ver uma tela intermediária abaixo da dobra com a descrição dele. Se esse for o caso, clique em "Continuar" e você não a verá novamente. Esta é a aparência dessa tela única:
Leva apenas alguns instantes para provisionar e se conectar ao Cloud Shell.
Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Praticamente todo o seu trabalho neste codelab pode ser feito em um navegador ou no seu Chromebook.
Depois de se conectar ao Cloud Shell, você já estará autenticado e o projeto já estará configurado com seu ID do projeto.
Execute o seguinte comando no Cloud Shell para confirmar se a conta está autenticada:
Depois de se conectar ao Cloud Shell, você já estará autenticado e o projeto estará configurado com seu PROJECT_ID.
gcloud auth list
Resposta ao comando
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Resposta ao comando
[core] project = <PROJECT_ID>
Se, por algum motivo, o projeto não estiver definido, basta emitir o seguinte comando:
gcloud config set project <PROJECT_ID>
O Cloud Shell também define algumas variáveis de ambiente por padrão, o que pode ser útil ao executar comandos futuros.
echo $GOOGLE_CLOUD_PROJECT
Resposta ao comando
<PROJECT_ID>
Aplicativos de amostra
Colocamos tudo o que você precisa para este projeto em um repositório Git. O repositório contém alguns aplicativos de exemplo, e você pode escolher qualquer um deles para este exercício.
Link do repositório Git: https://github.com/rominirani/cloud-code-sample-repository
3. Implantar o aplicativo de API
Qual é o assunto do aplicativo ou da API de exemplo?
Nosso aplicativo é um aplicativo simples da API Inventory que expõe um endpoint de API REST com algumas operações para listar os itens do inventário e receber a contagem de inventário de um item específico.
Depois de implantar a API e supondo que ela esteja hospedada em https://<somehost>, podemos acessar os endpoints da API da seguinte maneira:
- https://<somehost>/inventory
Isso vai listar todos os itens de produto com os níveis de inventário disponíveis.
- https://<somehost>/inventory/{productid}
Isso vai fornecer um único registro com o productid e o nível de inventário disponível para esse produto.
Os dados de resposta retornados estão no formato JSON.
Dados de amostra e solicitação/resposta da API
O aplicativo não é alimentado por um banco de dados no back-end para simplificar. Ele contém três exemplos de IDs de produtos e os níveis de estoque disponíveis.
ID do produto | Nível de inventário disponível |
I-1 | 10 |
I-2 | 20 |
I-3 | 30 |
Confira abaixo um exemplo de solicitação e resposta da API:
Solicitação de API | Resposta da API |
https://<somehost>/inventory | [ { "I-1": 10, "I-2": 20, "I-3": 30 }] |
https://<somehost>/inventory/I-1 | { "productid": "I-1", "qty": 10} |
https://<somehost>/inventory/I-2 | { "productid": "I-2", "qty": 20} |
https://<somehost>/inventory/I-200 | { "productid": I-200, "qty": -1} |
Clone o repositório
Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:
O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:
Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.
Configurar o gcloud
No Cloud Shell, defina o ID do projeto e salve-o como a variável PROJECT_ID.
PROJECT_ID=[YOUR-PROJECT-ID]
gcloud config set project $PROJECT_ID
Agora, execute o seguinte comando:
$ git clone https://github.com/rominirani/cloud-code-sample-repository.git
Isso vai criar uma pasta chamada cloud-code-sample-repository nessa pasta.
(Opcional) Executar o aplicativo no Cloud Shell
Para executar o aplicativo localmente, siga estas etapas:
- No terminal, navegue até a versão em Python da API com o seguinte comando:
$ cd cloud-code-sample-repository
$ cd python-flask-api
- No terminal, forneça o seguinte comando (no momento da redação, o Cloud Shell vem com o Python 3.9.x instalado e vamos usar a versão padrão. Se você planeja executar o código localmente no seu notebook, use o Python 3.8 ou mais recente:
$ python app.py
- É possível executar o comando a seguir para iniciar o servidor Python localmente.
- Isso vai iniciar um servidor na porta 8080, e você poderá testá-lo localmente usando o recurso de visualização da Web do Cloud Shell. Clique no botão Visualização da Web, como mostrado abaixo:
Clique em "Visualizar na porta 8080".
- Uma janela do navegador será aberta. Você vai receber um erro 404, mas não tem problema. Modifique o URL para que ele tenha apenas /inventory depois do nome do host.
Por exemplo, na minha máquina, ele aparece assim:
https://8080-cs-557561579860-default.cs-asia-southeast1-yelo.cloudshell.dev/inventory
Isso vai mostrar a lista de itens de inventário, conforme explicado anteriormente:
- Para interromper o servidor, acesse o terminal e pressione Ctrl-C.
Implante o aplicativo
Agora vamos implantar esse aplicativo de API no Cloud Run. O processo envolveu o uso do cliente de linha de comando gcloud para executar o comando de implantação do código no Cloud Run.
No terminal, execute o seguinte comando gcloud:
$ gcloud run deploy --source .
Você vai precisar responder a várias perguntas (se for solicitado a autorizar, faça isso). Alguns dos pontos estão mencionados abaixo. Você pode receber ou não todas as perguntas, dependendo da configuração e se já ativou APIs específicas no seu projeto do Google Cloud.
- Nome do serviço (python-flask-api): use o padrão ou escolha algo como my-inventory-api.
- API [run.googleapis.com] not enabled on project [project-number]. Would you like to enable and retry (this will take a few minutes)? (y/N)? S
- Especifique uma região: escolha uma região digitando um número.
- API [artifactregistry.googleapis.com] not enabled on project [project-number]. Would you like to enable and retry (this will take a few minutes)? (y/N)? S
- A implantação da origem exige um repositório do Docker do Artifact Registry para armazenar contêineres criados. Um repositório chamado [cloud-run-source-deploy] na região [us-west1] será criado.
Do you want to continue (Y/n)? S
- Allow unauthenticated invocations to [my-inventory-api] (y/N)? S
Eventualmente, isso vai iniciar o processo para pegar seu código-fonte, colocar em contêineres, enviar para o Artifact Registry e implantar o serviço e a revisão do Cloud Run. Tenha paciência durante esse processo, que pode levar de 3 a 4 minutos. Ele será concluído com o URL do serviço mostrado.
Confira um exemplo de execução abaixo:
teste o aplicativo
Agora que implantamos o aplicativo no Cloud Run, é possível acessar o aplicativo de API da seguinte maneira:
- Anote o URL do serviço da etapa anterior. Por exemplo, na minha configuração, ele aparece como
https://my-inventory-api-bt2r5243dq-uw.a.run.app. Vamos chamar isso de <SERVICE_URL>. - Abra um navegador e acesse os três URLs a seguir para os endpoints da API:
- <SERVICE_URL>/inventory
- <SERVICE_URL>/inventory/I-1
- <SERVICE_URL>/inventory/I-100
Ela precisa estar de acordo com as especificações que fornecemos em uma seção anterior com exemplos de solicitação e resposta da API.
Receber detalhes do serviço do Cloud Run
Implantamos nosso serviço de API no Cloud Run, um ambiente de computação sem servidor. É possível acessar o serviço do Cloud Run pelo console do Google Cloud a qualquer momento.
No menu principal, navegue até o Cloud Run. Isso vai mostrar a lista de serviços em execução no Cloud Run. O serviço que você acabou de implantar vai aparecer. Dependendo do nome selecionado, você vai ver algo assim:
Clique no nome do serviço para conferir os detalhes. Confira abaixo os detalhes da amostra:
Observe o URL, que é apenas o URL do serviço que você pode inserir no navegador e acessar a API Inventory que acabamos de implantar. Confira as métricas e outros detalhes.
Vamos começar com o pacote de operações do Google Cloud agora mesmo.
4. Configurar um painel
Um dos recursos convenientes do Cloud Monitoring são os painéis prontos para uso (OOTB, na sigla em inglês) em vários recursos do Google Cloud. Isso torna a configuração inicial dos painéis com métricas padrão um processo rápido e conveniente.
Vamos ver como fazer isso para o serviço de API que acabamos de implantar no Cloud Run.
Painel personalizado para nosso Serviço
Como implantamos nosso serviço de API no Cloud Run, vamos verificar como configurar painéis que ajudam a visualizar várias métricas, incluindo a latência do serviço.
Primeiro, no console, acesse Monitoring → Visão geral, conforme mostrado abaixo:
A visão geral mostra várias coisas que você teria configurado no Monitoring, como painéis, alertas, verificações de tempo de atividade etc.
Por enquanto, clique em Painéis no menu principal lateral. Isso vai abrir a seguinte tela:
Clique em BIBLIOTECA DE AMOSTRA . Isso vai mostrar a lista de painéis prontos para uso (OOTB, na sigla em inglês) disponíveis no Google Cloud em vários recursos. Role a lista para baixo e selecione Google Cloud Run, conforme mostrado abaixo.
Isso vai mostrar uma lista de painéis padrão disponíveis para o Google Cloud Run. Isso é interessante para nós, já que implantamos nosso serviço no Cloud Run.
Você vai encontrar um painel para o monitoramento do Cloud Run. Clique no link PRÉVIA para conferir a lista de gráficos padrão (métricas) disponíveis para o monitoramento do Cloud Run. Basta clicar em IMPORTAR PAINEL DE AMOSTRA para importar todos esses gráficos para um painel personalizado. Isso vai apresentar uma tela de painel com um nome preenchido previamente, como mostrado abaixo:
Para voltar, clique na seta para a esquerda, que fica à esquerda do nome do painel, no canto superior esquerdo. Isso vai abrir a lista de painéis, em que você poderá ver o novo painel que acabou de criar.
Clique nesse link para monitorar várias métricas disponíveis. Essas métricas incluem latência, contagem de solicitações, métricas de contêiner e muito mais.
Você também pode marcar qualquer painel como favorito. Basta selecionar o ícone de estrela, conforme mostrado abaixo:
Isso adiciona o painel à tela "Visão geral" do Monitoring e facilita a navegação até os painéis usados com frequência.
Fantástico! Você acabou de adicionar um painel personalizado para monitorar seus serviços do Cloud Run. Muito bem!
5. Verificações de tempo de atividade
Nesta seção, vamos configurar uma verificação de tempo de atividade para o serviço de API que implantamos. Uma verificação pública de tempo de atividade pode emitir solicitações de vários locais do mundo para URLs disponíveis publicamente ou recursos do Google Cloud para verificar se o recurso responde.
Nesse caso, o recurso será o serviço de API que implantamos no Cloud Run. O URL será um endpoint específico que o serviço de API expõe para indicar a integridade do serviço.
No exemplo de código do serviço de API, expusemos um endpoint /healthy que retorna um valor de string "All Izz Well". Então, tudo o que precisamos fazer é definir uma verificação de disponibilidade que acesse algo como https://<SERVICE_URL>/healthy e verifique se a string "All Izz Well" é retornada ou não.
Criar um canal de notificação
Antes de criar a verificação de tempo de atividade, é importante configurar os canais de notificação. Um canal de notificação é um meio pelo qual você vai receber um alerta se houver um incidente/problema com algum dos nossos recursos monitorados. Um exemplo de canal de notificação é o e-mail, e você vai receber e-mails caso haja um alerta etc.
Por enquanto, vamos configurar um canal de notificação por e-mail com nosso endereço de e-mail para receber alertas que nosso sistema vai gerar e configurar.
Para criar um canal de notificação, siga estas etapas:
Acesse Monitoring → Alertas no menu principal do console do Google Cloud, conforme mostrado abaixo:
Uma página com alertas, políticas e muito mais será exibida. Por enquanto, um link chamado EDITAR CANAIS DE NOTIFICAÇÃO vai aparecer na parte de cima. Clique nele.
Isso vai mostrar uma lista de vários canais de notificação, conforme mostrado abaixo:
Localize a seção E-mail e clique em ADICIONAR NOVO nessa linha. Isso vai abrir os detalhes da configuração de e-mail, conforme mostrado abaixo:
Insira seu endereço de e-mail e um nome de exibição, como mostrado abaixo. Clique em SALVAR.
Isso conclui a criação do canal de notificação por e-mail. Vamos configurar a verificação de tempo de atividade agora.
Como criar uma verificação do tempo de atividade
Acesse Monitoring → verificações de tempo de atividade no menu principal do Console do Google Cloud. Na parte de cima, você vai encontrar o link CRIAR UMA VERIFICAÇÃO DE TEMPO DE ATIVIDADE. Clique nele.
Isso abre uma série de etapas que você precisa concluir para configurar a verificação de tempo de atividade.
A primeira etapa é configurar os detalhes do destino, ou seja, informações sobre o serviço do Cloud Run que implantamos. Confira abaixo um formulário preenchido:
Os diferentes valores podem ser selecionados da seguinte maneira:
- Protocolo : HTTPS
- Tipo de recurso : selecione "Serviço do Cloud Run". Observe os outros recursos compatíveis e em que você também pode definir verificações de tempo de atividade.
- Serviço do Cloud Run : selecione my-inventory-api ou o nome específico do serviço do Cloud Run.
- O caminho é /healthy, já que estamos retornando uma string "All Izz Well" e queremos verificar isso.
Clique em CONTINUAR para ir para a próxima etapa. A próxima etapa é a Validação da resposta, conforme mostrado abaixo:
Você pode ver que estamos ativando a verificação de "Correspondência de conteúdo" e configurando que a resposta retornada pelo endpoint /healthy será "All Izz Well". Clique em CONTINUAR para ir para a próxima etapa, em que vamos configurar o alerta e o canal de notificação em que vamos receber um aviso se a verificação de tempo de atividade falhar.
Nesta etapa, dê um nome ao alerta. Escolhi Falha na verificação de tempo de atividade da API Inventory, mas você pode escolher o nome que quiser. O importante aqui é selecionar o canal de notificação correto na lista que você configurou anteriormente.
Clique em ANALISAR para a etapa final de revisão da verificação de tempo de atividade que configuramos.
Nesta etapa final, dê um nome à verificação de tempo de atividade (por exemplo, Verificação de tempo de atividade da API Inventory) e teste se ela está configurada corretamente. Clique no botão TESTAR.
Conclua o processo (clique no botão CRIAR à esquerda). O Google Cloud vai instruir as sondagens de verificação de tempo de atividade configuradas em diferentes regiões a fazer ping no URL, e essas respostas serão coletadas. Acesse a seção Monitoramento → Verificações de tempo de atividade depois de alguns minutos. O ideal é que você veja todos os sinais verdes que indicam que o URL estava acessível nas diferentes sondagens.
Se alguma das sondagens falhar por um período (que pode ser configurado), você vai receber uma notificação de alerta no canal de e-mail configurado.
Isso conclui nossa seção sobre como configurar uma verificação de tempo de atividade. Muito bem!
6. Metrics Explorer
O Cloud Monitoring expõe milhares de métricas padrão de vários produtos do Google Cloud. Essas métricas estão disponíveis para você investigar, consultar, converter em gráficos, adicionar a painéis, gerar alertas e muito mais.
Nesta seção, vamos:
- Entenda como analisar várias métricas e, em seguida, vamos investigar uma métrica específica (latência) para nosso serviço de API.
- Converta essa métrica em um gráfico e um painel personalizado que podem ser usados para visualizar a métrica a qualquer momento.
Analisar a métrica de latência do serviço da API Inventory
Acesse Monitoring → Metrics Explorer no menu principal do console do Google Cloud. Isso vai levar você à tela do Metrics Explorer. Clique em SELECIONAR UMA MÉTRICA. Agora é possível navegar por vários recursos ativos que têm métricas geradas.
Como estamos lidando com serviços do Cloud Run, clique em "Revisão do Cloud Run", depois na categoria e na métrica específica intitulada Latência de solicitação, conforme mostrado abaixo:
Clique em Aplicar. Isso vai mostrar a latência da solicitação em um gráfico. Você pode mudar o tipo de widget para um gráfico de linhas nas configurações de exibição à direita, conforme mostrado abaixo:
Isso vai mostrar o gráfico de latência, como mostrado abaixo:
Criar um gráfico e um painel personalizado
Vamos salvar este gráfico. Clique em Salvar gráfico e use os detalhes mostrados abaixo:
Lembre-se de que estamos criando um novo painel , em vez de salvar em um painel existente. Clique no botão SALVAR. Isso vai adicionar o painel recém-criado à nossa lista de painéis, conforme mostrado abaixo:
Clique no painel específico que criamos para ver os detalhes.
Assim, concluímos a seção sobre como investigar várias métricas usando o Metrics Explorer e criar painéis personalizados.
7. Cloud Logging
Nesta seção, vamos conhecer o Cloud Logging. O Cloud Logging vem com uma interface da Análise de registros que ajuda você a navegar e analisar os registros gerados por vários serviços do Google e seus próprios aplicativos.
Nesta seção, vamos aprender sobre a Análise de registros e simular algumas mensagens de registro que podem ser pesquisadas e convertidas em métricas usando um recurso chamado Métricas com base em registros.
Explorador de registros
Acesse a Análise de registros em Geração de registros → Análise de registros no console principal do Google Cloud, conforme mostrado abaixo:
Isso vai mostrar uma interface de registro em que você pode selecionar/desmarcar vários recursos (projeto, recurso do Google Cloud, nomes de serviços etc.) e níveis de registro para filtrar as mensagens de registro conforme necessário.
Acima, mostramos a lista de registros da revisão do Cloud Run, ou seja, os serviços do Cloud Run que implantamos. Você vai notar várias solicitações que são verificações de tempo de atividade atingindo o endpoint /healthy que configuramos.
Pesquisar avisos
Simule algumas solicitações inválidas para o serviço de inventário fornecendo IDs de produtos que não sejam I-1, I-2 e I-3. Por exemplo, uma solicitação incorreta é:
https://<SERVICE_URL>/inventory/I-999
Agora vamos pesquisar todos os AVISOS gerados pela nossa API quando um ID de produto incorreto é fornecido na consulta.
Na caixa de consulta, insira os seguintes parâmetros de consulta:
resource.type="cloud_run_revision"
textPayload =~ "Received inventory request for incorrect productid"
O código será semelhante a este:
Clique em "Executar consulta". Isso vai mostrar todas as solicitações que chegaram e que têm esse problema.
Métricas com base em registros
Vamos criar uma métrica de registro personalizada para rastrear esses erros. Queremos saber se há um número significativo de chamadas com IDs de produtos incorretos.
Para converter o exemplo acima em uma métrica de erro, clique no botão Criar métrica no Análise de registros.
Isso vai abrir o formulário para criar a definição de métrica. Escolha uma métrica de contador e insira os detalhes do nome da métrica (inventory_lookup_errors) e da descrição, conforme mostrado abaixo. Depois, clique em Criar métrica.
Isso vai criar a métrica de contador, e você vai ver uma mensagem como a mostrada abaixo:
Acesse Logging → Métricas com base em registros no menu principal. A métrica personalizada que definimos vai aparecer na lista de métricas definidas pelo usuário, conforme mostrado abaixo:
No final dessa entrada, você vai encontrar três pontos verticais. Clique neles para conferir as operações que podem ser realizadas nessa métrica personalizada. A lista será semelhante à mostrada abaixo. Clique na opção Ver no Metrics Explorer.
Isso vai nos levar ao Metrics Explorer que aprendemos na seção anterior, só que agora ele já está preenchido.
Clique em Salvar gráfico. Use os seguintes valores para as opções de "Salvar gráfico":
Isso vai criar um novo painel em que você pode ver os erros da Pesquisa de inventário, que estará disponível na lista de painéis.
Ótimo! Você criou uma métrica personalizada com base nos seus registros, converteu isso em um gráfico que está em um painel personalizado. Isso nos ajuda a rastrear o número de chamadas que usam IDs de produto incorretos.
8. Políticas de alerta
Nesta seção, vamos usar a métrica personalizada que criamos e monitorar os dados dela para um limite. Por exemplo, se o número de erros ultrapassar um determinado limite, vamos gerar um alerta. Em outras palavras, vamos configurar uma política de alertas.
Criar uma política de alertas
Vamos acessar o painel de pesquisa de inventário. Isso vai abrir o gráfico que criamos para observar os erros de pesquisa de inventário, conforme mostrado abaixo:
Isso vai mostrar os dados de métricas atuais. Primeiro, edite a métrica conforme mostrado abaixo (clique no botão "Editar"):
Isso vai abrir os detalhes da métrica. Vamos converter o gráfico de taxa de erros para uma soma, ou seja, o número de erros. O campo a ser mudado é mostrado abaixo:
Clique em APLICAR no canto superior direito. Você vai voltar para a tela "Métricas", mas agora poderá ver o número total de erros no período de alinhamento em comparação com a taxa de erros.
Vamos criar uma política de alertas que pode nos notificar caso o número de erros ultrapasse um limite. Clique nos três pontos no canto superior direito do gráfico e, na lista de opções, como mostrado acima, clique em Converter em gráfico de alerta.
Você vai ver uma tela como esta:
Clique em Próxima. Isso vai abrir um valor de limite que podemos definir. O limite de amostra que usamos aqui é 5 , mas você pode escolher de acordo com sua preferência.
Clique em PRÓXIMA para abrir o formulário de notificações.
Selecionamos o canal de notificação como o canal de e-mail que criamos anteriormente. Você pode preencher os outros detalhes, como documentação (que será fornecida como parte do alerta gerado). Clique em PRÓXIMA para ver o resumo e concluir o processo.
Depois de criar essa política de alertas, ela vai aparecer na lista de políticas de alertas, conforme mostrado abaixo. Para acessar a lista de políticas de alertas, acesse Monitoring → Alertas. Procure a seção Políticas na página para ver a lista de políticas que configuramos até agora.
Ótimo! Agora você configurou uma política de alertas personalizada que vai notificar você em caso de aumento na taxa de erros ao pesquisar a API Inventory.
9. Service Monitoring (opcional)
Nesta seção, vamos configurar SLIs/SLOs para nossos serviços de acordo com os princípios da engenharia de confiabilidade do site (SRE). O Cloud Monitoring facilita o processo ao descobrir automaticamente os serviços implantados no Cloud Run e calcular automaticamente os principais SLIs, como disponibilidade e latência, além de cálculos de orçamento de erros.
Vamos configurar o SLO de latência para nosso serviço de API.
Como configurar o SLO de latência para o serviço de inventário
Clique em Monitoring → Serviços no menu principal do console do Cloud. Isso vai abrir a lista de serviços configurados para o Service Monitoring.
No momento, não temos serviços configurados para monitoramento de SLI/SLO. Por isso, a lista está vazia. Clique no link DEFINIR SERVIÇO na parte de cima para definir / identificar um serviço primeiro.
Isso vai descobrir automaticamente os serviços que são candidatos ao monitoramento de SLO. Ele consegue descobrir serviços do Cloud Run, e, portanto, nosso serviço da API Inventory implantado no Cloud Run vai aparecer na lista.
O nome de exibição que aparece pode ser diferente e depende do que você escolheu ao implantar o serviço no Cloud Run. Clique no botão ENVIAR. Isso vai abrir a tela mostrada abaixo:
Clique em CRIAR SLO. Agora você pode selecionar entre os SLIs calculados automaticamente para você.
Vamos começar com o SLI de latência. Clique em CONTINUAR. Em seguida, você verá uma tela que mostra o desempenho atual desse serviço e a latência típica.
Inserimos um valor para o limite, ou seja, 300 ms, que é o que queremos alcançar. Você pode escolher um valor diferente, mas lembre-se de que isso vai afetar a margem de erro que você define de acordo. Clique em CONTINUAR.
Agora definimos o SLO (meta e período de medição) conforme mostrado abaixo:
Isso significa que estamos selecionando a janela de medição como um tipo contínuo e medindo-a em sete dias. Da mesma forma, para a meta, escolhemos um objetivo de 90%. O que estamos tentando dizer aqui é que 90% das solicitações ao serviço de API precisam ser concluídas em até 300 ms, e isso deve ser medido em sete dias.
Clique em Continuar. Isso abre a tela de resumo, que pode ser confirmada clicando no botão ATUALIZAR SLO.
Isso salva a definição de SLO, e a margem de erro é calculada automaticamente.
Algumas opções:
- Teste a API com várias chamadas e confira a performance do serviço e como isso afeta o restante do orçamento de erros.
- Modifique o código-fonte para introduzir um atraso adicional (suspensão) aleatoriamente em algumas chamadas. Isso vai aumentar a latência de várias chamadas e afetar negativamente a margem de erro.
10. Parabéns
Parabéns! Você implantou um aplicativo de amostra no Google Cloud e aprendeu a usar o pacote de operações do Google Cloud para monitorar a integridade dele.
O que vimos
- Como implantar um serviço no Google Cloud Run.
- Como configurar um painel para o serviço do Google Cloud Run.
- Verificações de tempo de atividade.
- Configurar métricas de registro personalizadas e painel/gráfico com base nelas.
- Como usar o Metrics Explorer e configurar um painel/gráfico.
- Configurar políticas de alertas.
- Configurar SLI/SLO para o monitoramento de serviços no Google Cloud.
Observação:se você executou o codelab usando sua própria conta e projeto do Google Cloud, os recursos alocados podem continuar gerando uma cobrança de faturamento. Exclua o projeto e os recursos quando terminar o laboratório.
Qual é a próxima etapa?
Confira esta Quest do Cloud Skills Boost para saber mais sobre o pacote de operações do Google Cloud.