Ruta de aprendizaje: Aplicaciones escalables - Supervisa con Prometheus

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.

1. Accede a Slack con el nombre de tu espacio de trabajo y tus credenciales de la cuenta de Slack.

2. 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:

1. 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.

2. 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.

3. 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
   

4. 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.

Sondeos

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.

1. 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
   

   Como se muestra en este archivo de manifiesto, se recomienda que cada sondeo de funcionamiento de Prometheus PodMonitoring supervise cada Deployment por separado.

2. 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.

1. 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: 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'
   

   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.

2. 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.

1. 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.

2. 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
   

3. 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
   

4. 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