Ruta de aprendizaje: Aplicaciones escalables - Supervisa con Prometheus

Este conjunto de instructivos es para administradores y operadores de TI que deseen implementar, ejecutar y administrar entornos de aplicaciones modernos que se ejecutan en la edición Enterprise de Google Kubernetes Engine (GKE). A medida que avanzas con este conjunto de instructivos, aprenderás a configurar la supervisión y las alertas, escalar cargas de trabajo y simular fallas, todo con la aplicación de microservicios de muestra de Cymbal Bank:

Crea un clúster y, luego, implementa una app de ejemplo
Supervisa con Google Cloud Managed Service para Prometheus (este instructivo)
Escala las cargas de trabajo
Simula una falla

Descripción general y objetivos

La aplicación de muestra de Cymbal Bank que se usa en este conjunto de instructivos está compuesta por una serie de microservicios que se ejecutan en el clúster de GKE. Los problemas con cualquiera de estos servicios pueden provocar una mala experiencia para los clientes del banco, como no poder acceder a la aplicación del banco. Aprender sobre los problemas con los servicios lo antes posible significa que puedes comenzar a solucionar los problemas y resolverlos con rapidez.

En este instructivo, aprenderás a supervisar cargas de trabajo en un clúster de GKE con Google Cloud Managed Service para Prometheus y Cloud Monitoring. Aprenderás a completar las siguientes tareas:

Crea un webhook de Slack para Alertmanager.
Configurar Prometheus para supervisar el estado de una aplicación basada en microservicios de muestra
Simula una interrupción y revisa las alertas enviadas mediante el webhook de Slack.

Costos

Habilitar GKE Enterprise e implementar la aplicación de ejemplo Cymbal Bank para esta serie de instructivos significa que se generan cargos por clúster para GKE Enterprise en Google Cloud, como se indica en nuestra página de precios hasta que inhabilites GKE Enterprise o borres el proyecto.

También eres responsable de otros costos de Google Cloud generados mientras ejecutas la aplicación de muestra de Cymbal Bank, como los cargos por las VMs de Compute Engine y Cloud Monitoring.

Antes de comenzar

Si quieres aprender a supervisar tus cargas de trabajo, debes completar el primer instructivo para crear un clúster de GKE que use Autopilot e implementar la aplicación basada en microservicios de muestra de Cymbal Bank.

Te recomendamos que completes este conjunto de instructivos para Cymbal Bank en orden. A medida que avanzas en el conjunto de instructivos, adquieres habilidades nuevas y usas productos y servicios adicionales de Google Cloud.

Para mostrar un ejemplo de cómo un clúster de GKE Autopilot puede usar Google Cloud Managed Service para Prometheus a fin de generar mensajes en una plataforma de comunicación, en este instructivo, se usa Slack. En tus propias implementaciones de producción, puedes usar la herramienta de comunicación preferida de tu organización para procesar y entregar mensajes cuando el clúster de GKE tenga un problema.

Únete a un lugar de trabajo de Slack. Para hacerlo, regístrate con tu correo electrónico o usa una invitación que te haya enviado un administrador del espacio de trabajo.

Nota: Si no eres administrador del espacio de trabajo de Slack, tal vez necesites aprobación de uno para que tu app se implemente en el espacio de trabajo.

Crea una aplicación de Slack

Una parte importante de la configuración de la supervisión es asegurarse de que se te notifique cuando ocurran eventos prácticos, como interrupciones. Un patrón común para esto es enviar notificaciones a una herramienta de comunicación como Slack, que es lo que usarás en este instructivo. Slack proporciona una función de webhook que permite que las aplicaciones externas, como las implementaciones de producción, generen mensajes. Puedes usar otras herramientas de comunicación en tu organización para procesar y entregar mensajes cuando el clúster de GKE tenga un problema.

Los clústeres de GKE que usan Autopilot incluyen una instancia de Google Cloud Managed Service para Prometheus. Esta instancia puede generar alertas cuando algo le sucede a tus aplicaciones. Estas alertas pueden usar un webhook de Slack para enviar un mensaje a tu lugar de trabajo de Slack a fin de que recibas notificaciones de mensajes cuando haya un problema.

Si deseas configurar las notificaciones de Slack basadas en alertas generadas por Prometheus, debes crear una aplicación de Slack, activar los webhooks entrantes de la aplicación y, luego, instalarla en un lugar de trabajo de Slack.

Accede a Slack con el nombre de tu espacio de trabajo y tus credenciales de la cuenta de Slack.
Cree una aplicación de Slack nueva
1. En el cuadro de diálogo Create an app (Crear una aplicación), haz clic en From scratch (Desde cero).
2. Especifica un nombre de aplicación y elige tu lugar de trabajo de Slack.
3. Haz clic en Crear aplicación (Create App).
4. En Add features and functionality (Agregar características y funciones), haz clic en Incoming Webhooks (Webhooks entrantes).
5. Haz clic en el botón de activación Activate Incoming Webhooks (Activar webhooks entrantes).
6. En la sección Webhook URLs for Your Workspace (URLs de webhook para tu lugar de trabajo), haz clic en Add New Webhook to Workspace (Agregar webhook nuevo al lugar de trabajo).
7. En la página de autorización que se abrirá, selecciona un canal para recibir notificaciones.
8. Haz clic en Permitir.
9. Se mostrará un webhook para tu aplicación de Slack en la sección Webhook URLs for Your Workspace (URLs de webhook para tu lugar de trabajo). Guarda la URL para usarla más adelante.

Configura Alertmanager

En Prometheus, Alertmanager procesa los eventos de supervisión que generan tus implementaciones. Alertmanager puede omitir eventos duplicados, agrupar eventos relacionados y enviar notificaciones, como el uso de un webhook de Slack. En esta sección, se muestra cómo configurar Alertmanager para que use tu webhook de Slack nuevo. En la siguiente sección del instructivo, Configura Prometheus, se explica cómo quieres que Alertmanager procese los eventos que se enviarán.

Si deseas configurar Alertmanager para que use tu webhook de Slack, completa los siguientes pasos:

Cambia los directorios al repositorio de Git que incluye todos los manifiestos de muestra de Cymbal Bank del instructivo anterior:
```
cd ~/bank-of-anthos/
```
Si es necesario, cambia la ubicación del directorio a la ubicación en la que clonaste el repositorio con anterioridad.
Actualiza el manifiesto YAML de muestra de Alertmanager con la URL de webhook de tu aplicación de Slack:
```
sed -i "s@SLACK_WEBHOOK_URL@SLACK_WEBHOOK_URL@g" "extras/prometheus/gmp/alertmanager.yaml"
```
Reemplaza SLACK_WEBHOOK_URL por la URL del webhook de la sección anterior.
Para usar de forma dinámica la URL de webhook única de Slack sin cambios en el código de la aplicación, puedes usar un Secret de Kubernetes. El código de la aplicación lee el valor de este Secret. En aplicaciones más complejas, esta capacidad te permite cambiar o rotar los valores por razones de seguridad o cumplimiento.

Crea un secreto de Kubernetes para Alertmanager mediante el manifiesto YAML de muestra que contiene la URL de webhook de Slack:
```
kubectl create secret generic alertmanager \
  -n gmp-public \
  --from-file=extras/prometheus/gmp/alertmanager.yaml
```
Prometheus puede usar exportadores para obtener métricas de aplicaciones sin cambios de código. El exportador de la caja negra de Prometheus te permite sondear los extremos como HTTP o HTTPS. Este exportador funciona bien cuando no deseas o no puedes exponer el funcionamiento interno de tu aplicación a Prometheus. El exportador de la caja negra de Prometheus puede funcionar sin cambios en el código de la aplicación para exponer las métricas a Prometheus.

Implementa el exportador de la caja negra de Prometheus en tu clúster:
```
kubectl apply -f extras/prometheus/gmp/blackbox-exporter.yaml
```

Configura Prometheus

Después de configurar Alertmanager para que use tu webhook de Slack, debes indicarle a Prometheus qué supervisar en Cymbal Bank y qué tipos de eventos deseas que Alertmanager te notifique sobre el uso del webhook de Slack.

En la aplicación de muestra de Cymbal Bank que usas en estos instructivos, hay varios microservicios que se ejecutan en el clúster de GKE. Un problema que es probable que quieras conocer lo antes posible es si uno de los servicios de Cymbal Bank dejó de responder normalmente a las solicitudes, lo que podría significar que tus clientes no pueden acceder a la aplicación. Puedes configurar Prometheus para que responda a eventos según las políticas de tu organización.

Probes

Puedes configurar sondeos de Prometheus para los recursos que deseas supervisar. Estos sondeos pueden generar alertas basadas en la respuesta que reciben los sondeos. En la aplicación de muestra de Cymbal Bank, puedes usar sondeos HTTP que verifican códigos de respuesta de nivel 200 de los servicios. Una respuesta de nivel HTTP 200 indica que el servicio se ejecuta de forma correcta y puede responder a las solicitudes. Si hay un problema y el sondeo no recibe la respuesta esperada, puedes definir reglas de Prometheus que generen alertas para que Alertmanager procese y realice acciones adicionales.

Crea algunos sondeos de Prometheus para supervisar el estado HTTP de los diversos microservicios de la aplicación de muestra de Cymbal Bank. Revisa el siguiente manifiesto de muestra:

# 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

En este manifiesto, se describen los sondeos de funcionamiento de Prometheus y se incluyen los siguientes campos:

spec.jobName: el nombre del trabajo asignado a las métricas recopiladas.
spec.prober.url: la URL del servicio del exportador de la caja negra. Esto incluye el puerto predeterminado para el exportador de la caja negra.
spec.prober.path: la ruta de recopilación de métricas.
spec.targets.staticConfig.labels: las etiquetas asignadas a todas las métricas recopiladas de los destinos.
spec.targets.staticConfig.static: la lista de hosts que se sondearán.

Para crear los sondeos de funcionamiento de Prometheus, aplica el manifiesto a tu clúster:
```
kubectl apply -f extras/prometheus/gmp/probes.yaml
```

Reglas

Prometheus necesita saber lo que deseas hacer en función de la respuesta que reciben los sondeos que creaste en los pasos anteriores. Esta respuesta se define mediante las reglas de Prometheus.

En este instructivo, crearás reglas de Prometheus para generar alertas según la respuesta al sondeo de funcionamiento. Luego, Alertmanager procesa el resultado de estas reglas para generar notificaciones mediante el webhook de Slack.

Crea reglas que generen eventos basados en la respuesta a los sondeos de funcionamiento. Revisa el siguiente manifiesto de muestra:

# 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: BalancereaderUnavaiable
      expr: probe_success{job="balancereader-probe"} == 0
      for: 1m
      annotations:
        summary: Balance Reader Service is unavailable
        description: Check Balance Reader pods and it's logs
      labels:
        severity: 'critical'
    - alert: ContactsUnavaiable
      expr: probe_success{job="contacts-probe"} == 0
      for: 1m
      annotations:
        summary: Contacs Service is unavailable
        description: Check Contacs pods and it's logs
      labels:
        severity: 'warning'
    - alert: FrontendUnavaiable
      expr: probe_success{job="frontend-probe"} == 0
      for: 1m
      annotations:
        summary: Frontend Service is unavailable
        description: Check Frontend pods and it's logs
      labels:
        severity: 'critical'
    - alert: LedgerwriterUnavaiable
      expr: probe_success{job="ledgerwriter-probe"} == 0
      for: 1m
      annotations:
        summary: Ledger Writer Service is unavailable
        description: Check Ledger Writer pods and it's logs
      labels:
        severity: 'critical'
    - alert: TransactionhistoryUnavaiable
      expr: probe_success{job="transactionhistory-probe"} == 0
      for: 1m
      annotations:
        summary: Transaction History Service is unavailable
        description: Check Transaction History pods and it's logs
      labels:
        severity: 'critical'
    - alert: UserserviceUnavaiable
      expr: probe_success{job="userservice-probe"} == 0
      for: 1m
      annotations:
        summary: User Service is unavailable
        description: Check User Service pods and it's logs
      labels:
        severity: 'critical'

En este manifiesto, se describe un PrometheusRule y se incluyen los siguientes campos:

spec.groups.[*].name: el nombre del grupo de reglas.
spec.groups.[*].interval: con qué frecuencia se evalúan las reglas del grupo.
spec.groups.[*].rules[*].alert: el nombre de la alerta.
spec.groups.[*].rules[*].expr: la expresión PromQL que se evaluará.
spec.groups.[*].rules[*].for: la cantidad de tiempo que deben aparecer las alertas antes de que se consideren activadas.
spec.groups.[*].rules[*].annotations: una lista de anotaciones que se agregará a cada alerta. Esto solo es válido para las reglas de alerta.
spec.groups.[*].rules[*].labels: las etiquetas que se agregarán o reemplazarán.

Para crear las reglas, aplica el manifiesto a tu clúster:
```
kubectl apply -f extras/prometheus/gmp/rules.yaml
```

Simula una interrupción

Para asegurarte de que los sondeos, las reglas y la configuración de Alertmanager de Prometheus sean correctos, debes probar que las alertas y las notificaciones se envíen cuando haya un problema. Si no pruebas este flujo, es posible que no te des cuenta de que hay una interrupción en los servicios de producción cuando algo sale mal.

Para simular una interrupción de uno de los microservicios, escala la implementación contacts a cero. Con cero instancias del servicio, la aplicación de muestra de Cymbal Bank no puede leer la información de contacto para los clientes:
```
kubectl scale deployment contacts --replicas 0
```
GKE puede tardar hasta 5 minutos en escalar el Deployment.

Comprueba el estado de los objetos Deployment en tu clúster y verifica que el Deployment de contacts reduzca la escala de forma correcta:

kubectl get deployments

En el siguiente resultado de ejemplo, la implementación de contacts redujo correctamente la escala verticalmente a instancias 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

Después de que la implementación de contacts disminuyó a cero, el sondeo de Prometheus informa un código de error HTTP. Este error HTTP genera una alerta para que Alertmanager se procese.

Revisa el canal de tu lugar de trabajo de Slack para ver si hay un mensaje de notificación de interrupción con un texto similar al siguiente ejemplo:
```
[FIRING:1] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```
En una situación de interrupción real, después de recibir la notificación en Slack, comienzas a solucionar problemas y restablecer servicios. Para este instructivo, simula este proceso y restablece el Deployment contacts mediante el escalamiento vertical de la cantidad de réplicas:
```
kubectl scale deployment contacts --replicas 1
```
El escalamiento del Deployment y el sondeo de Prometheus puede tardar hasta 5 minutos en recibir una respuesta HTTP 200. Verifica el estado de los objetos Deployment mediante el comando kubectl get deployments.

Cuando se recibe una respuesta en buen estado al sondeo de Prometheus, Alertmanager borra el evento. Deberías ver un mensaje de notificación de resolución de alertas en el canal del lugar de trabajo de Slack similar al siguiente ejemplo:
```
[RESOLVED] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```

Limpia

Si deseas tomar un descanso antes de continuar con el siguiente instructivo y evitar que se generen cargos en tu cuenta de Google Cloud por los recursos que se usaron en este instructivo, borra el proyecto que creaste.

Precaución: Borrar un proyecto tiene estas consecuencias:

Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

En la consola de Google Cloud, ve a la página Administrar recursos.
Ir a Administrar recursos
En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

Aprende a escalar tus implementaciones en GKE Enterprise en el siguiente instructivo.