Programa de aprendizado: aplicativos escalonáveis - monitorar com o Prometheus

Este conjunto de tutoriais é destinado a administradores e operadores de TI que querem implantar, executar e gerenciar ambientes de aplicativos modernos executados no Google Kubernetes Engine (GKE) edição Enterprise. À medida que avança neste conjunto de tutoriais, você aprende a configurar o monitoramento e alertas, escalonar cargas de trabalho e simular falhas. Tudo isso usando o aplicativo de microsserviços de amostra Cymbal Bank:

Criar um cluster e implantar um aplicativo de exemplo
Monitorar com o Google Cloud Managed Service para Prometheus (este tutorial)
Escalonar cargas de trabalho
Simular uma falha
Centralizar a gestão da mudança

Visão geral e objetivos

O aplicativo de exemplo Cymbal Bank usado neste conjunto de tutoriais é composto por vários microsserviços que são executados no cluster do GKE. Problemas com qualquer um desses serviços podem resultar em uma experiência ruim para os clientes do banco, como não conseguir acessar o aplicativo bancário. Aprender sobre problemas com os serviços o mais rápido possível significa que você pode começar rapidamente a resolver problemas.

Neste tutorial, você vai aprender a monitorar cargas de trabalho em um cluster do GKE usando o Google Cloud Managed Service para Prometheus e o Cloud Monitoring. Você aprenderá a concluir as seguintes tarefas:

Criar um webhook do Slack para o Alertmanager.
Configurar o Prometheus para monitorar o status de um aplicativo de exemplo baseado em microsserviços.
Simular uma falha temporária e analisar os alertas enviados usando o webhook do Slack.

Custos

Ao ativar o GKE Enterprise e implantar o aplicativo de amostra Cymbal Bank para esta série de tutoriais, você receberá cobranças por cluster do GKE Enterprise no Google Cloud, conforme listado na nossa página de preços, até desativar o GKE Enterprise ou excluir o projeto.

Você também é responsável por outros custos do Google Cloud gerados ao executar o aplicativo de exemplo Cymbal Bank, como cobranças por VMs do Compute Engine e Cloud Monitoring.

Antes de começar

Para saber como monitorar suas cargas de trabalho, complete o primeiro tutorial para criar um cluster do GKE que use o Autopilot e implantar o aplicativo baseado em microsserviços de exemplo Cymbal Bank.

Recomendamos que você conclua este conjunto de tutoriais para o Cymbal Bank em ordem. À medida que avança no conjunto de tutoriais, você aprende novas habilidades e usa outros produtos e serviços do Google Cloud.

Para mostrar um exemplo de como um cluster do Autopilot do GKE pode usar o Google Cloud Managed Service para Prometheus a fim de gerar mensagens para uma plataforma de comunicação, este tutorial usa o Slack. Nas implantações de produção, é possível usar a ferramenta de comunicação preferida da sua organização para processar e enviar mensagens quando o cluster do GKE tiver um problema.

Participe de um espaço de trabalho do Slack registrando-se com seu e-mail ou usando um convite enviado por um administrador do espaço de trabalho.

Observação: se você não for um administrador do espaço de trabalho do Slack, talvez precise da aprovação de um a fim de conseguir implantar o aplicativo no espaço de trabalho.

Criar um aplicativo Slack

Uma parte importante da configuração do monitoramento é garantir que você seja notificado quando ocorrerem eventos acionáveis, como falhas. Um padrão comum para isso é enviar notificações para uma ferramenta de comunicação, como o Slack, que é o que você usa neste tutorial. O Slack oferece um recurso de webhooks que permite que aplicativos externos, como implantações de produção, gerem mensagens. Você pode usar outras ferramentas de comunicação na 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 Google Cloud Managed Service para Prometheus. Essa instância pode gerar alertas quando algo acontece com seus aplicativos. Esses alertas podem usar um webhook do Slack para enviar uma mensagem ao espaço de trabalho do Slack e você receber notificações imediatas quando houver um problema.

Para configurar notificações do Slack com base em alertas gerados pelo Prometheus, é preciso criar um aplicativo do Slack, ativar os Webhooks de entrada para o aplicativo e instalar o aplicativo em um espaço de trabalho do Slack.

Faça login no Slack usando o nome do seu espaço de trabalho e as credenciais da sua conta do Slack.
Criar um novo aplicativo do Slack
1. Na caixa de diálogo Criar um aplicativo, clique em Do zero.
2. Especifique o campo App Name e escolha seu espaço de trabalho do Slack.
3. Clique em Create App.
4. Em Adicionar recursos e funcionalidades, clique em Webhooks de entrada.
5. Clique no botão Ativar Webhooks de entrada.
6. Na seção URLs de webhook para espaço de trabalho, clique em Adicionar novo webhook ao espaço de trabalho.
7. Na página de autorização, selecione um canal para receber notificações.
8. Clique em Permitir.
9. Um webhook do aplicativo Slack é exibido na seção URLs de webhook para seu espaço de trabalho. Salve o URL para mais tarde.

Configurar o Alertmanager

No Prometheus, o Alertmanager processa eventos de monitoramento que suas implantações geram. O Alertmanager pode pular eventos duplicados, agrupar eventos relacionados e enviar notificações, como usar um webhook do Slack. Esta seção mostra como configurar o Alertmanager para usar seu novo webhook do Slack. Na próxima seção do tutorial, Configurar o Prometheus, você vai especificar como o Alertmanager vai processar os eventos que serão enviados.

Para configurar o Alertmanager para usar o webhook do Slack, conclua as seguintes etapas:

Mude os diretórios para o repositório Git que inclui todos os manifestos de exemplo para o Cymbal Bank do tutorial anterior:
```
cd ~/bank-of-anthos/
```
Se necessário, mude o local do diretório para onde você clonou anteriormente o repositório.
Atualize o manifesto YAML de exemplo do Alertmanager com o URL do webhook do seu aplicativo 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 seção anterior.
Para usar dinamicamente seu URL de webhook exclusivo do Slack sem alterações no código do aplicativo, é possível usar um secret do Kubernetes. O código do aplicativo lê o valor desse secret. Em aplicativos mais complexos, essa capacidade permite alterar ou alternar valores por motivos de segurança ou compliance.

Crie um secret do Kubernetes para o Alertmanager usando o exemplo de manifesto YAML que contém o URL de webhook do Slack:
```
kubectl create secret generic alertmanager \
  -n gmp-public \
  --from-file=extras/prometheus/gmp/alertmanager.yaml
```
O Prometheus pode usar exportadores para conseguir métricas de aplicativos sem mudanças de código. O exportador de caixa preta do Prometheus permite que você teste endpoints como HTTP ou HTTPS. Esse exportador funciona bem quando você não quer ou não pode expor o funcionamento interno do seu aplicativo para o Prometheus. O exportador de caixa preta do Prometheus pode funcionar sem alterações no código do aplicativo para expor métricas ao Prometheus.

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

Configurar o Prometheus

Depois de configurar o Alertmanager para usar o webhook do Slack, é necessário informar ao Prometheus o que monitorar no Cymbal Bank e quais tipos de evento você quer que o Alertmanager notifique usando o webhook do Slack.

No aplicativo de exemplo do Cymbal Bank usado nestes tutoriais, há vários microsserviços que são executados no cluster do GKE. Um problema que você provavelmente quer saber o mais rápido possível é se um dos serviços do Cymbal Bank deixaram de responder normalmente a solicitações, o que pode significar que seus clientes não possam acessar o aplicativo. É possível configurar o Prometheus para responder a eventos com base nas políticas da sua organização.

Sondagens

É possível configurar sondagens do Prometheus para os recursos que você quer monitorar. Essas sondagens podem gerar alertas com base na resposta recebida. No aplicativo de exemplo do Cymbal Bank, é possível usar sondagens HTTP que verificam códigos de resposta de nível 200 dos serviços. Uma resposta de nível HTTP 200 indica se o serviço está sendo executado corretamente e se pode responder às solicitações. Se houver um problema e a sondagem não receber a resposta esperada, você poderá definir regras do Prometheus que geram alertas para o Alertmanager processar e realizar outras ações.

Crie algumas sondagens do Prometheus para monitorar o status HTTP dos vários microsserviços do aplicativo de exemplo Cymbal Bank. Analise o exemplo de manifesto a seguir:

# 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

Como mostrado neste arquivo de manifesto, é recomendável que cada sondagem de atividade PodMonitoring do Prometheus monitore cada implantação separadamente.

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

Regras

O Prometheus precisa saber o que você quer fazer com base na resposta que as sondagens que você criou nas etapas anteriores recebem. Você define essa resposta usando regras do Prometheus.

Neste tutorial, você vai criar regras do Prometheus para gerar alertas dependendo da resposta à sondagem de atividade. O Alertmanager processa a saída dessas regras para gerar notificações usando o webhook do Slack.

Crie regras que geram eventos com base na resposta às sondagens de atividade. Analise o exemplo de manifesto a seguir:

# 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'

Esse 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 ser avaliada.
spec.groups.[*].rules[*].for: a quantidade de vezes que os alertas são emitidos antes de serem considerados disparados.
spec.groups.[*].rules[*].annotations: uma lista de anotações para adicionar a cada alerta. Válido apenas para regras de alerta.
spec.groups.[*].rules[*].labels: os rótulos que serão adicionados ou substituídos.

Para criar as regras, aplique o manifesto ao cluster:

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

Simular uma interrupção

Para garantir que as sondagens, as regras e a configuração do Alertmanager do Prometheus estejam corretas, verifique se os alertas e as notificações são enviados quando há um problema. Se você não testar esse fluxo, talvez não perceba que houve uma interrupção dos seus serviços de produção quando algo dá errado.

Para simular uma interrupção de um dos microsserviços, escalone a implantação contacts para zero. Sem instâncias do serviço, o aplicativo de exemplo Cymbal Bank não consegue ler os dados de contato dos clientes:
```
kubectl scale deployment contacts --replicas 0
```
O GKE pode levar até cinco minutos para reduzir a escala vertical da implantação.

Verifique o status das implantações no cluster e confirme se a implantação contacts está sendo reduzida corretamente:

kubectl get deployments

No exemplo de saída a seguir, a implantação contacts foi reduzida para instâncias 0:

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 que a implantação contacts for reduzida a zero, a sondagem do Prometheus informa um código de erro HTTP. Esse erro HTTP gera um alerta para o Alertmanager processar em seguida.

Verifique se há uma mensagem de notificação de interrupção no canal do espaço de trabalho do Slack com um texto semelhante ao exemplo abaixo:
```
[FIRING:1] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```
Em um cenário de interrupção real, depois de receber a notificação no Slack, você começaria a resolver problemas e restaurar serviços. Para este tutorial, simule esse processo e restaure a implantação de contacts escalonando o número de réplicas:
```
kubectl scale deployment contacts --replicas 1
```
Pode levar até 5 minutos para escalonar a implantação e para a sondagem do Prometheus receber uma resposta HTTP 200. Você verifica o status das implantações usando o comando kubectl get deployments.

Quando uma resposta íntegra para a sondagem do Prometheus é recebida, o Alertmanager limpa o evento. Uma mensagem de notificação de resolução de alerta vai aparecer no canal do espaço de trabalho do Slack semelhante ao exemplo a seguir:
```
[RESOLVED] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```

Limpar

Se você quiser fazer uma pausa antes de avançar para o próximo tutorial e evitar cobranças na sua conta do Google Cloud pelos recursos usados neste tutorial, exclua o projeto criado.

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

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.

A seguir

Saiba como escalonar suas implantações no GKE no próximo tutorial.