Esta página foi traduzida pela API Cloud Translation.

Percurso de aprendizagem: aplicações escaláveis – Monitorize com o Prometheus

Autopilot

Este conjunto de tutoriais destina-se a administradores de TI e operadores que querem implementar, executar e gerir ambientes de aplicações modernos que são executados no Google Kubernetes Engine (GKE). À medida que avança neste conjunto de tutoriais, vai aprender a configurar a monitorização e os alertas, dimensionar cargas de trabalho e simular falhas, tudo isto usando a aplicação de microsserviços de exemplo do Cymbal Bank:

Crie um cluster e implemente uma aplicação de exemplo
Monitorize com o serviço gerido do Google Cloud para o Prometheus (este tutorial)
Dimensione cargas de trabalho
Simule uma falha
Centralize a gestão da mudança

Vista geral e objetivos

A aplicação de exemplo do Cymbal Bank usada neste conjunto de tutoriais é composta por vários microsserviços que são executados no cluster do GKE. Os problemas com qualquer um destes serviços podem resultar numa má experiência para os clientes do banco, como a impossibilidade de aceder à aplicação do banco. A aprendizagem sobre os problemas com os serviços o mais rapidamente possível significa que pode começar rapidamente a resolver os problemas.

Neste tutorial, vai aprender a monitorizar cargas de trabalho num cluster do GKE usando o serviço gerido da Google Cloud para Prometheus e o Cloud Monitoring. Aprende a concluir as seguintes tarefas:

Crie um webhook do Slack para o Alertmanager.
Configure o Prometheus para monitorizar o estado de uma aplicação de exemplo baseada em microsserviços.
Simule uma indisponibilidade e reveja os alertas enviados através do webhook do Slack.

Custos

A ativação do GKE e a implementação da aplicação de exemplo do Cymbal Bank para esta série de tutoriais significa que incorre em custos por cluster para o GKE on Google Cloud , conforme indicado na nossa página de preços, até desativar o GKE ou eliminar o projeto.

Também é responsável por outros Google Cloud custos incorridos durante a execução da aplicação de exemplo do Cymbal Bank, como encargos relativos a VMs do Compute Engine e Cloud Monitoring.

Antes de começar

Para saber como monitorizar as suas cargas de trabalho, tem de concluir o primeiro tutorial para criar um cluster do GKE que use o Autopilot e implementar a aplicação de exemplo baseada em microsserviços do Cymbal Bank.

Recomendamos que conclua este conjunto de tutoriais para apps escaláveis por ordem. À medida que avança no conjunto de tutoriais, aprende novas competências e usa produtos e serviços Google Cloud adicionais.

Para mostrar um exemplo de como um cluster do GKE Autopilot pode usar o serviço gerido do Google Cloud para Prometheus para gerar mensagens para uma plataforma de comunicações, este tutorial usa o Slack. Nas suas implementações de produção, pode usar a ferramenta de comunicação preferida da sua organização para processar e enviar mensagens quando o cluster do GKE tiver um problema.

Aderir a um espaço de trabalho do Slack, através do registo com o seu email ou de um convite enviado por um administrador do Workspace.

Nota: se não tiver a função de administrador do seu espaço de trabalho do Slack, pode precisar da aprovação de um administrador do espaço de trabalho antes de a sua app ser implementada no seu espaço de trabalho.

Crie uma aplicação Slack

Uma parte importante da configuração da monitorização é garantir que recebe notificações quando ocorrem eventos acionáveis, como interrupções. Um padrão comum para isto é enviar notificações para uma ferramenta de comunicação, como o Slack, que é o que usa neste tutorial. O Slack oferece uma funcionalidade de webhooks que permite que aplicações externas, como as suas implementações de produção, gerem mensagens. Pode usar outras ferramentas de comunicação na sua organização para processar e entregar mensagens quando o cluster do GKE tiver um problema.

Os clusters do GKE que usam o Autopilot incluem uma instância do serviço gerido do Google Cloud para o Prometheus. Esta instância pode gerar alertas quando acontece algo às suas aplicações. Em seguida, estes alertas podem usar um webhook do Slack para enviar uma mensagem para o seu espaço de trabalho do Slack, para que receba notificações rápidas quando houver um problema.

Para configurar notificações do Slack com base em alertas gerados pelo Prometheus, tem de criar uma aplicação Slack, ativar os Webhooks recebidos para a aplicação e instalar a aplicação num espaço de trabalho do Slack.

Inicie sessão no Slack com o nome do seu espaço de trabalho e as credenciais da sua conta do Slack.
Crie uma nova app Slack
1. Na caixa de diálogo Criar uma app, clique em Do zero.
2. Especifique um Nome da app e escolha o seu espaço de trabalho do Slack.
3. Clique em Criar app.
4. Em Adicionar funcionalidades, clique em Webhooks recebidos.
5. Clique no botão ativar/desativar Ativar webhooks recebidos.
6. Na secção URLs de webhook para o seu espaço de trabalho, clique em Adicionar novo webhook ao espaço de trabalho.
7. Na página de autorização apresentada, selecione um canal para receber notificações.
8. Clique em Permitir.
9. É apresentado um webhook para a sua aplicação Slack na secção URLs de webhook para o seu espaço de trabalho. Guarde o URL para mais tarde.

Configure o Alertmanager

No Prometheus, o Alertmanager processa eventos de monitorização gerados pelas suas implementações. O Alertmanager pode ignorar eventos duplicados, agrupar eventos relacionados e enviar notificações, como usar um webhook do Slack. Esta secção mostra como configurar o Alertmanager para usar o seu novo webhook do Slack. A especificação de como quer que o Alertmanager processe os eventos a enviar é abordada na secção seguinte do tutorial, Configure o Prometheus.

Para configurar o Alertmanager de modo a usar o seu webhook do Slack, conclua os seguintes passos:

Altere os diretórios para o repositório Git que inclui todos os manifestos de exemplo do Cymbal Bank do tutorial anterior:
```
cd ~/bank-of-anthos/
```
Se necessário, altere a localização do diretório para onde clonou anteriormente o repositório.
Atualize o manifesto YAML de exemplo do Alertmanager com o URL do webhook da sua aplicação Slack:
```
sed -i "s@SLACK_WEBHOOK_URL@SLACK_WEBHOOK_URL@g" "extras/prometheus/gmp/alertmanager.yaml"
```
Substitua SLACK_WEBHOOK_URL pelo URL do webhook da secção anterior.
Para usar dinamicamente o URL do webhook exclusivo do Slack sem alterações ao código da aplicação, pode usar um segredo do Kubernetes. O código da aplicação lê o valor deste segredo. Em aplicações mais complexas, esta capacidade permite-lhe alterar ou rodar valores por motivos de segurança ou conformidade.

Crie um segredo do Kubernetes para o Alertmanager através do manifesto YAML de exemplo que contém o URL do webhook do Slack:
```
kubectl create secret generic alertmanager \
  -n gmp-public \
  --from-file=extras/prometheus/gmp/alertmanager.yaml
```
O Prometheus pode usar exportadores para obter métricas de aplicações sem alterações de código. O exportador de caixa negra do Prometheus permite-lhe sondar pontos finais como HTTP ou HTTPS. Este exportador funciona bem quando não quer ou não pode expor o funcionamento interno da sua aplicação ao Prometheus. O exportador de caixa negra do Prometheus pode funcionar sem alterações ao código da sua aplicação para expor métricas ao Prometheus.

Implemente o exportador de caixa negra do Prometheus no seu cluster:
```
kubectl apply -f extras/prometheus/gmp/blackbox-exporter.yaml
```

Configure o Prometheus

Depois de configurar o Alertmanager para usar o seu webhook do Slack, tem de indicar ao Prometheus o que monitorizar no Cymbal Bank e que tipos de eventos quer que o Alertmanager lhe envie notificações através do webhook do Slack.

Na aplicação de exemplo Cymbal Bank que usa nestes tutoriais, existem vários microsserviços que são executados no cluster do GKE. Um problema que provavelmente quer saber o mais rapidamente possível é se um dos serviços do Cymbal Bank deixou de responder normalmente aos pedidos, o que pode significar que os seus clientes não conseguem aceder à aplicação. Pode configurar o Prometheus para responder a eventos com base nas políticas da sua organização.

Sondas

Pode configurar sondas do Prometheus para os recursos que quer monitorizar. Estas sondagens podem gerar alertas com base na resposta que recebem. Na aplicação de exemplo do Cymbal Bank, pode usar sondas HTTP que verificam os códigos de resposta de nível 200 dos serviços. Uma resposta de nível HTTP 200 indica que o serviço está a ser executado corretamente e pode responder a pedidos. Se houver um problema e a sondagem não receber a resposta esperada, pode definir regras do Prometheus que geram alertas para o Alertmanager processar e realizar ações adicionais.

Crie algumas sondas Prometheus para monitorizar o estado HTTP dos vários microsserviços da aplicação de exemplo do Cymbal Bank. Reveja o seguinte manifesto de exemplo:

# Copyright 2023 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: frontend-probe
  labels:
    app.kubernetes.io/name: frontend-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [frontend:80]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: userservice-probe
  labels:
    app.kubernetes.io/name: userservice-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [userservice:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: balancereader-probe
  labels:
    app.kubernetes.io/name: balancereader-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [balancereader:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: contacts-probe
  labels:
    app.kubernetes.io/name: contacts-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [contacts:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: ledgerwriter-probe
  labels:
    app.kubernetes.io/name: ledgerwriter-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [ledgerwriter:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s
---
apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: transactionhistory-probe
  labels:
    app.kubernetes.io/name: transactionhistory-probe
spec:
  selector:
    matchLabels:
      app: blackbox-exporter
  endpoints:
  - port: metrics
    path: /probe
    params:
      target: [transactionhistory:8080/ready]
      module: [http_2xx]
    timeout: 30s
    interval: 60s

Conforme mostrado neste ficheiro de manifesto, é uma prática recomendada que cada PodMonitoring sonda de atividade do Prometheus monitorize cada implementação separadamente.

Para criar as sondas de atividade do Prometheus, aplique o manifesto ao seu cluster:
```
kubectl apply -f extras/prometheus/gmp/probes.yaml
```

Regras

O Prometheus precisa de saber o que quer fazer com base na resposta que as sondas criadas nos passos anteriores recebem. Define esta resposta através de regras do Prometheus.

Neste tutorial, cria regras do Prometheus para gerar alertas consoante a resposta à sondagem de atividade. Em seguida, o Alertmanager processa o resultado destas regras para gerar notificações através do webhook do Slack.

Crie regras que gerem eventos com base na resposta às sondagens de atividade. Reveja o seguinte manifesto de exemplo:

# Copyright 2023 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
---
apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  name: uptime-rule
spec:
  groups:
  - name: Micro services uptime
    interval: 60s
    rules:
    - alert: BalancereaderUnavailable
      expr: probe_success{job="balancereader-probe"} == 0
      for: 1m
      annotations:
        summary: Balance Reader Service is unavailable
        description: Check Balance Reader pods and its logs
      labels:
        severity: 'critical'
    - alert: ContactsUnavailable
      expr: probe_success{job="contacts-probe"} == 0
      for: 1m
      annotations:
        summary: Contacts Service is unavailable
        description: Check Contacts pods and its logs
      labels:
        severity: 'warning'
    - alert: FrontendUnavailable
      expr: probe_success{job="frontend-probe"} == 0
      for: 1m
      annotations:
        summary: Frontend Service is unavailable
        description: Check Frontend pods and its logs
      labels:
        severity: 'critical'
    - alert: LedgerwriterUnavailable
      expr: probe_success{job="ledgerwriter-probe"} == 0
      for: 1m
      annotations:
        summary: Ledger Writer Service is unavailable
        description: Check Ledger Writer pods and its logs
      labels:
        severity: 'critical'
    - alert: TransactionhistoryUnavailable
      expr: probe_success{job="transactionhistory-probe"} == 0
      for: 1m
      annotations:
        summary: Transaction History Service is unavailable
        description: Check Transaction History pods and its logs
      labels:
        severity: 'critical'
    - alert: UserserviceUnavailable
      expr: probe_success{job="userservice-probe"} == 0
      for: 1m
      annotations:
        summary: User Service is unavailable
        description: Check User Service pods and its logs
      labels:
        severity: 'critical'

Este manifesto descreve um PrometheusRule e inclui os seguintes campos:

spec.groups.[*].name: o nome do grupo de regras.
spec.groups.[*].interval: a frequência com que as regras no grupo são avaliadas.
spec.groups.[*].rules[*].alert: o nome do alerta.
spec.groups.[*].rules[*].expr: a expressão PromQL a avaliar.
spec.groups.[*].rules[*].for: o período durante o qual os alertas têm de ser devolvidos antes de serem considerados acionados.
spec.groups.[*].rules[*].annotations: uma lista de anotações a adicionar a cada alerta. Isto só é válido para regras de alerta.
spec.groups.[*].rules[*].labels: as etiquetas a adicionar ou substituir.

Para criar as regras, aplique o manifesto ao cluster:

kubectl apply -f extras/prometheus/gmp/rules.yaml

Simule uma indisponibilidade

Para se certificar de que as sondas, as regras e a configuração do Alertmanager do Prometheus estão corretas, deve testar se os alertas e as notificações são enviados quando existe um problema. Se não testar este fluxo, pode não se aperceber de que existe uma indisponibilidade dos seus serviços de produção quando algo corre mal.

Para simular uma indisponibilidade de um dos microserviços, reduza a escala da implementação contacts para zero. Com zero instâncias do serviço, a aplicação de exemplo do Cymbal Bank não consegue ler as informações de contacto dos clientes:
```
kubectl scale deployment contacts --replicas 0
```
O GKE pode demorar até 5 minutos a reduzir a escala da implementação.

Verifique o estado das implementações no cluster e confirme que a contacts implementação é reduzida corretamente:

kubectl get deployments

No resultado do exemplo seguinte, a implementação contacts foi reduzida com êxito para 0 instâncias:

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
balancereader        1/1     1            1           17m
blackbox-exporter    1/1     1            1           5m7s
contacts             0/0     0            0           17m
frontend             1/1     1            1           17m
ledgerwriter         1/1     1            1           17m
loadgenerator        1/1     1            1           17m
transactionhistory   1/1     1            1           17m
userservice          1/1     1            1           17m

Depois de a contactsimplementação ser reduzida a zero, a sonda do Prometheus comunica um código de erro HTTP. Este erro HTTP gera um alerta para o Alertmanager para processamento posterior.

Procure no canal do espaço de trabalho do Slack uma mensagem de notificação de interrupção com texto semelhante ao seguinte exemplo:
```
[FIRING:1] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```
Num cenário de indisponibilidade real, depois de receber a notificação no Slack, começaria a resolver problemas e a restaurar os serviços. Para este tutorial, simule este processo e restaure a contactsimplementação ao aumentar novamente o número de réplicas:
```
kubectl scale deployment contacts --replicas 1
```
O dimensionamento da implementação e a receção de uma resposta HTTP 200 pela sonda do Prometheus podem demorar até 5 minutos. Verifica o estado das implementações com o comando kubectl get deployments.

Quando é recebida uma resposta válida à sondagem do Prometheus, o Alertmanager limpa o evento. Deve ver uma mensagem de notificação de resolução de alerta no canal do espaço de trabalho do Slack semelhante ao seguinte exemplo:
```
[RESOLVED] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```

Limpar

Recomendamos que conclua este conjunto de tutoriais para o Cymbal Bank pela ordem indicada. À medida que avança no conjunto de tutoriais, aprende novas competências e usa produtos e serviços Google Cloud adicionais.

Se quiser fazer uma pausa antes de avançar para o tutorial seguinte e evitar incorrer em custos na sua Google Cloud conta pelos recursos usados neste tutorial Google Cloud , elimine o projeto que criou.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

O que se segue?

Saiba como dimensionar as suas implementações no GKE no próximo tutorial.