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 para monitorar, resolver problemas e melhorar o desempenho de 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 exemplo no Google Cloud. Em seguida, você vai analisar e configurar vários recursos do Cloud Monitoring em relação à API.
O que você vai aprender
- Use o Cloud Shell do Google Cloud para implantar um exemplo de aplicativo no Cloud Run.
- Uso de 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 dos participantes do projeto. É 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. Normalmente, você não se importa com ele. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, que normalmente é identificado como PROJECT_ID. Se você não gostar do ID gerado, poderá gerar outro ID 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 do projeto que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
Cuidado: um ID de projeto precisa ser globalmente exclusivo e não pode ser usado por mais ninguém depois de selecionado. 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 exclua 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 em seu laptop, neste codelab vamos usar 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". O provisionamento e a conexão ao ambiente levam apenas alguns instantes.
Se você nunca iniciou o Cloud Shell, vai aparecer uma tela intermediária (abaixo da dobra) com a descrição dele. Se esse for o caso, clique em "Continuar" e você não vai encontrar essa tela 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 usar qualquer um deles para este exercício.
Link do repositório Git: https://github.com/rominirani/cloud-code-sample-repository (em inglês)
3. Implantar o aplicativo de API
Sobre o que é o aplicativo ou a 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 específica do inventário de itens.
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 do produto com os níveis de inventário disponíveis.
- https://<somehost>/inventory/{productid}
Isso vai gerar um único registro com o ID do produto e o nível de inventário disponível para esse produto.
Os dados de resposta retornados estão no formato JSON.
Exemplo de dados e solicitação/resposta da API
Para simplificar, o aplicativo não é alimentado por um banco de dados no back-end. Ele contém três IDs de produtos de exemplo e os níveis de inventário 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.
(Opcional) Execute o aplicativo no Cloud Shell
Para executar o aplicativo localmente, siga estas etapas:
- No terminal, use o seguinte comando para acessar a versão em Python da API:
$ cd cloud-code-sample-repository
$ cd python-flask-api
- No terminal, digite o comando a seguir. No momento da redação deste artigo, o Cloud Shell vem com o Python 3.9.x instalado, e vamos usar a versão padrão. Se você planeja executar localmente no laptop, use o Python 3.8+:
$ python app.py
- É possível executar o comando abaixo para iniciar o servidor Python localmente.
- Isso vai iniciar um servidor na porta 8080, e você poderá testá-lo localmente pelo recurso de visualização da Web do Cloud Shell. Clique no botão Visualização da Web, conforme mostrado abaixo:
Clique em "Visualizar na porta 8080".
- Uma janela do navegador será aberta. Você vai receber um erro 404, e isso é normal. Modifique o URL e deixe apenas /inventory após o nome do host.
Por exemplo, na minha máquina, ele tem esta aparência:
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 agora, vá até o terminal e pressione Ctrl-C
Implante o aplicativo
Agora vamos implantar este aplicativo de API no Cloud Run. O processo envolvia a utilização do cliente de linha de comando glcoud para executar o comando e implantar o código no Cloud Run.
No terminal, execute o seguinte comando gcloud:
$ gcloud run deploy --source .
Isso vai fazer com que você responda a várias perguntas (se for solicitado que você autorize, prossiga). Alguns dos pontos são mencionados abaixo. Você pode ou não receber todas as perguntas, dependendo da configuração e se você já ativou APIs específicas no seu projeto do Google Cloud.
- Nome do serviço (python-flask-api): use esse padrão ou escolha algo como my-inventory-api.
- A API [run.googleapis.com] não está ativada no projeto [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 de sua preferência informando um número.
- A API [artifactregistry.googleapis.com] não está ativada no projeto [project-number]. Deseja ativar e tentar novamente (isso levará alguns minutos)? (y/N)? S
- A implantação da origem requer um repositório 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
- Permitir invocações não autenticadas para [my-inventory-api] (y/N)? S
Isso vai iniciar o processo de contêinerização do código-fonte, envio para o Artifact Registry e implantação do serviço e da revisão do Cloud Run. Tenha paciência durante esse processo (pode levar de 3 a 4 minutos) e confira o processo sendo concluído com o URL do serviço mostrado.
Confira abaixo um exemplo de execução:
teste o aplicativo
Agora que implantamos o aplicativo no Cloud Run, você pode acessar o aplicativo da 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 abaixo para os endpoints da API:
- <SERVICE_URL>/inventário
- <SERVICE_URL>/inventory/I-1
- <URL_DO_SERVIÇO>/inventário/I-100
Ele precisa ser conforme as especificações que fornecemos em uma seção anterior com um exemplo 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 parecido com isto:
Clique no nome do serviço para conferir os detalhes. Confira abaixo os detalhes do exemplo:
Observe o URL, que nada mais é do que o URL de serviço que você pode inserir no navegador e acessar a API Inventory que acabamos de implantar. Fique à vontade para conferir métricas e outros detalhes.
Vamos começar com o pacote de operações do Google Cloud.
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 conferir como fazer isso para o serviço de API que acabamos de implantar no Cloud Run.
Painel personalizado para nosso serviço
Como já implantamos nosso serviço de API no Cloud Run, vamos conferir como configurar painéis que podem ajudar a visualizar várias métricas, algumas das quais incluem a latência do serviço.
Primeiro, no console, acesse Monitoramento → 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 SAMPLE LIBRARY . Isso vai mostrar a lista de painéis prontos para uso (OOTB) 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. Estamos interessados nisso desde que implantamos nosso serviço no Cloud Run.
Você verá um painel para o monitoramento do Cloud Run. Clique no link VISUALIZAR para conferir a lista de gráficos padrão (métricas) disponíveis para o Cloud Run Monitoring. Basta clicar em IMPORTAR PAINEL DE EXEMPLO para importar todos esses gráficos em um painel personalizado. Isso vai apresentar uma tela de painel com um nome preenchido, como mostrado abaixo:
Para voltar, clique na seta para a esquerda, que fica à esquerda do nome do painel, no canto superior esquerdo. Isso levará à lista de dashboards, e nela você poderá ver o novo painel que acabou de criar.
Clique no link do painel 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, selecionando o ícone de estrela, conforme mostrado abaixo:
Isso vai adicionar o painel à tela "Visão geral" do Monitoring e se tornar uma maneira fácil de navegar 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 de tempo de atividade pública pode enviar solicitações de vários locais do mundo para URLs ou recursos do Google Cloud disponíveis publicamente e conferir se o recurso responde.
O recurso, neste caso, será o serviço de API implantado 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 código de exemplo do serviço de API, expomos um endpoint /healthy que retorna um valor de string "All Izz Well". Então, tudo o que precisamos fazer é definir uma verificação de tempo de atividade 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 alertas 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 notificações em caso de alertas que nosso sistema vai gerar e configurar.
Para criar um canal de notificação, siga estas etapas:
Acesse Monitoramento → Alertas no menu principal do Console do Google Cloud, conforme mostrado abaixo:
Uma página com alertas, políticas e muito mais vai aparecer. Por enquanto, você vai encontrar um link na parte de cima com o título EDITAR CANAIS DE NOTIFICAÇÃO. 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 na linha. Isso vai mostrar os detalhes da configuração de e-mail, conforme mostrado abaixo:
Insira seu endereço de e-mail e um Nome de exibição, conforme 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.
Como criar uma verificação do tempo de atividade
Acesse Monitoramento → 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 mostra 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. Um formulário preenchido é mostrado abaixo:
Os diferentes valores podem ser selecionados da seguinte forma:
- Protocolo : HTTPS
- Tipo de recurso : selecione "Serviço do Cloud Run". Observe os outros recursos aos quais ele oferece suporte e que você também pode definir verificações de tempo de atividade neles.
- 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 passar para a próxima etapa. A próxima etapa é a Validação de resposta, conforme mostrado abaixo:
Observe que estamos ativando a verificação de "Correspondência de conteúdo" e definindo 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 o alerta será enviado, 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 seu nome. O importante aqui é selecionar o canal de notificação correto na lista que você configurou anteriormente.
Clique em REVISAR na etapa final para revisar a 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 a verificação está configurada corretamente. Clique no botão TEST para isso.
Continue e conclua o processo (clique no botão CREATE à esquerda). O Google Cloud instrui as sondas de verificação de tempo de atividade configuradas em diferentes regiões a fazer um ping no URL, e essas respostas são coletadas. Acesse a seção Monitoramento → Verificações de tempo de atividade após alguns minutos. Você verá todos os indicadores verdes que indicam que o URL foi acessado pelas diferentes sondas.
Se alguma das sondas falhar por um período de tempo (configurável), você vai receber uma notificação de alerta no canal de e-mail que configuramos.
Esta é a 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, ativar alertas e muito mais.
Nosso objetivo nesta seção é:
- Entenda como analisar várias métricas e 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.
Conheça a métrica de latência do serviço da API Inventory
Acesse Monitoramento → 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 os serviços do Cloud Run, clique em "Revisão do Cloud Run", depois selecione a categoria e a métrica específica intituladas Latência da 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, conforme 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 conferir os detalhes.
Isso conclui a seção sobre como investigar várias métricas usando o Metrics Explorer e como criar nossos painéis personalizados.
7. Cloud Logging
Nesta seção, vamos conhecer o Cloud Logging. O Cloud Logging vem com uma interface do Logs Explorer que ajuda 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 o Logs Explorer 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 onde é possível marcar/desmarcar vários recursos (projeto, recurso do Google Cloud, nomes de serviço etc.) junto com níveis de registro para filtrar as mensagens conforme necessário.
A lista de registros acima mostra a revisão do Cloud Run, ou seja, os serviços do Cloud Run que implantamos. Várias solicitações de verificação de disponibilidade vão atingir o endpoint /healthy que configuramos.
Pesquisar avisos
Simular 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 procurar todos os avisos gerados pela nossa API quando um ID de produto incorreto for fornecido na consulta.
Na caixa de consulta, insira os seguintes parâmetros:
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 foram recebidas e que têm esse problema.
Métricas com base em registros
Vamos criar uma métrica de registro personalizada para acompanhar esses erros. Queremos entender se há um número significativo de chamadas com IDs de produto incorretos.
Para converter o exemplo acima em uma métrica de erro, clique no botão Criar métrica que aparece no Explorer de registros.
O formulário para criar a definição da métrica será exibido. Escolha uma métrica de contador e insira os detalhes do nome (inventory_lookup_errors) e da descrição, conforme mostrado abaixo, e clique em Criar métrica.
Isso vai criar a métrica de contador, e você vai receber uma mensagem como a mostrada abaixo:
Acesse Logging → Logs-based Metrics no menu principal e a métrica personalizada que definimos na lista de métricas definidas pelo usuário, conforme mostrado abaixo:
No final da 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 deve ser semelhante à mostrada abaixo. Clique na opção Ver no Metrics Explorer.
Isso vai levar você ao Metrics Explorer que aprendemos na seção anterior, exceto que agora ele 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 conferir os erros de pesquisa de inventário, e ele vai estar disponível na lista de painéis.
Ótimo! Você criou uma métrica personalizada com base nos seus registros e a converteu em um gráfico em um painel personalizado. Isso vai nos ajudar a rastrear o número de chamadas que estão usando IDs de produtos 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, ou seja, 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 mostrar o gráfico que criamos para registrar os erros de pesquisa de inventário, conforme mostrado abaixo:
Isso vai mostrar os dados de métrica atuais. Primeiro, edite a métrica conforme mostrado abaixo (clique no botão "Editar"):
Isso vai mostrar os detalhes da métrica. Vamos converter o gráfico que mostra a taxa de erros em uma soma, ou seja, o número de erros. O campo a ser alterado é mostrado abaixo:
Clique em APLICAR no canto superior direito e vamos voltar à tela "Métricas", mas desta vez vamos poder conferir o número total de erros no período de alinhamento em relação à 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.
Uma tela como esta vai aparecer:
Clique em Próxima para mostrar 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ÓXIMO 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 outros detalhes, como documentação (que será fornecida como parte do alerta gerado). Clique em PRÓXIMO para conferir o resumo e concluir o processo.
Depois de criar essa política de alertas, ela ficará visível na lista de políticas de alertas, conforme mostrado abaixo. Acesse a lista de políticas de alertas em Monitoramento → Alertas. Procure a seção Políticas na página para ver a lista de políticas que configuramos até agora.
Ótimo! Você configurou uma política de alerta personalizada que vai notificar você em caso de aumento da 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 de sites (SRE). Você vai perceber que o Cloud Monitoring facilita a descoberta automática dos serviços implantados no Cloud Run e pode calcular automaticamente os principais SLIs, como disponibilidade e latência, além dos cálculos de margem de erro.
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 → Services no menu principal do Console do Cloud. Isso vai mostrar a lista de serviços que foram configurados para o monitoramento de serviço.
No momento, não temos serviços configurados para o monitoramento de SLI/SLO, então 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 pode 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 exibido pode ser diferente e depende do que você escolheu no momento da implantação do serviço no Cloud Run. Clique no botão ENVIAR. Isso vai abrir a tela mostrada abaixo:
Clique em CRIAR SLO. Assim, você pode selecionar entre os SLIs calculados automaticamente.
Para começar, escolhemos o SL de latência. Clique em CONTINUAR. Em seguida, você vai ver uma tela que mostra a performance atual desse serviço e qual é a latência típica.
Colocamos 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 o orçamento de erros definido. Clique em CONTINUAR.
Agora definimos o SLO (janela de destino e medição) conforme mostrado abaixo:
Isso significa que estamos selecionando a janela de medição como uma janela contínua e medindo em sete dias. Da mesma forma, escolhemos uma meta de 90% para a meta. O que estamos tentando dizer aqui é que 90% das solicitações ao serviço da API precisam ser concluídas em 300 ms e isso precisa ser medido em 7 dias.
Clique em Continuar. Isso abrirá a tela de resumo, que você pode confirmar clicando no botão ATUALIZAR SLO.
Isso salva sua definição de SLO, e a margem de erro é calculada automaticamente.
Confira algumas sugestões:
- Teste a API com várias chamadas, veja o desempenho do serviço e como ele afeta a margem de erro restante.
- Modifique o código-fonte para introduzir um atraso adicional (tempo de inatividade) aleatoriamente em algumas chamadas. Isso vai aumentar a latência de várias chamadas e afetar negativamente o orçamento de erros.
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
- Implantar um serviço no Google Cloud Run.
- Configurar um painel para o serviço do Google Cloud Run.
- Verificações de tempo de atividade.
- Configurar métricas de registro personalizadas e o painel/gráfico com base nelas.
- explorar o Metrics Explorer e configurar o painel/gráfico
- Como configurar políticas de alertas.
- Como configurar o SLI/SLO para o monitoramento de serviços no Google Cloud.
Observação:se você executou o codelab usando sua própria conta e um projeto do Google Cloud, os recursos alocados podem continuar sendo cobrados. Portanto, exclua o projeto e os recursos quando terminar o laboratório.
Qual é a próxima etapa?
Confira esta Quest do Google Cloud Ensina para saber mais sobre o pacote de operações do Google Cloud.