Esta página se ha traducido con Cloud Translation API.

Ruta de aprendizaje: aplicaciones escalables - Monitorizar con Prometheus

Autopilot

Este conjunto de tutoriales está dirigido a administradores de TI y operadores que quieran desplegar, ejecutar y gestionar entornos de aplicaciones modernas que se ejecuten en Google Kubernetes Engine (GKE). A lo largo de esta serie de tutoriales, aprenderás a configurar la monitorización y las alertas, a escalar cargas de trabajo y a simular errores. Todo ello con la aplicación de microservicios de ejemplo Cymbal Bank:

Crear un clúster y desplegar una aplicación de ejemplo
Monitorizar con Google Cloud Managed Service para Prometheus (este tutorial)
Escalar cargas de trabajo
Simular un fallo
Centralizar la gestión de cambios

Descripción general y objetivos

La aplicación de ejemplo Cymbal Bank que se usa en este conjunto de tutoriales se compone de varios microservicios que se ejecutan en el clúster de GKE. Si hay problemas con alguno de estos servicios, los clientes del banco podrían tener una mala experiencia, por ejemplo, no poder acceder a la aplicación del banco. Si conoces los problemas de los servicios lo antes posible, podrás empezar a solucionarlos rápidamente.

En este tutorial, aprenderás a monitorizar 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.
Configura Prometheus para monitorizar el estado de una aplicación de microservicios de ejemplo.
Simula una interrupción y revisa las alertas enviadas mediante el webhook de Slack.

Costes

Si habilitas GKE y despliegas la aplicación de ejemplo Cymbal Bank para esta serie de tutoriales, se te aplicarán cargos por clúster de GKE en Google Cloud , tal como se indica en nuestra página de precios, hasta que inhabilites GKE o elimines el proyecto.

También eres responsable de otros Google Cloud costes que se generen al ejecutar la aplicación de ejemplo de Cymbal Bank, como los cargos de las máquinas virtuales de Compute Engine y Cloud Monitoring.

Antes de empezar

Para aprender a monitorizar tus cargas de trabajo, debes completar el primer tutorial para crear un clúster de GKE que use Autopilot y desplegar la aplicación de microservicios de ejemplo Cymbal Bank.

Te recomendamos que completes este conjunto de tutoriales para aplicaciones escalables en orden. A medida que avances en el conjunto de tutoriales, adquirirás nuevas habilidades y usarás más Google Cloud productos y servicios.

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

Únete a un espacio de trabajo de Slack, registrándote con tu correo o usando una invitación enviada por un administrador del espacio de trabajo.

Nota: Si no eres administrador de tu espacio de trabajo de Slack, es posible que necesites la aprobación de un administrador del espacio de trabajo para que tu aplicación se implemente en él.

Crear una aplicación de Slack

Una parte importante de la configuración de la monitorización es asegurarse de que se le notifique cuando se produzcan eventos que requieran una acción, como interrupciones. Una práctica habitual es enviar notificaciones a una herramienta de comunicación como Slack, que es la que vas a usar en este tutorial. Slack ofrece una función de webhooks que permite que aplicaciones externas, como tus implementaciones de producción, generen mensajes. Puedes usar otras herramientas de comunicación de tu organización para procesar y enviar mensajes cuando tu 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 ocurre algo en tus aplicaciones. Estas alertas pueden usar un webhook de Slack para enviar un mensaje a tu espacio de trabajo de Slack, de forma que recibas notificaciones rápidas cuando haya un problema.

Para configurar notificaciones de Slack basadas en alertas generadas por Prometheus, debes crear una aplicación de Slack, activar los webhooks entrantes de la aplicación e instalar la aplicación en un espacio de trabajo de Slack.

Inicia sesión en Slack con el nombre de tu espacio de trabajo y las credenciales de tu cuenta de Slack.
Crear una aplicación de Slack
1. En el cuadro de diálogo Crear una aplicación, haz clic en Desde cero.
2. Especifica un nombre de aplicación y elige tu espacio de trabajo de Slack.
3. Haz clic en Create App (Crear aplicación).
4. En Añadir características y funciones, haz clic en Webhooks entrantes.
5. Haz clic en el botón Activar webhooks entrantes.
6. En la sección URLs de webhook de tu espacio de trabajo, haz clic en Añadir nuevo webhook al espacio de trabajo.
7. En la página de autorización que se abre, selecciona un canal para recibir notificaciones.
8. Haz clic en Permitir.
9. Se muestra un webhook de tu aplicación de Slack en la sección URLs de webhook de tu espacio de trabajo. Guarda la URL para más adelante.

Configurar Alertmanager

En Prometheus, Alertmanager procesa los eventos de monitorización que generan tus implementaciones. Alertmanager puede omitir eventos duplicados, agrupar eventos relacionados y enviar notificaciones, como usar un webhook de Slack. En esta sección se explica cómo configurar Alertmanager para usar el nuevo webhook de Slack. En la siguiente sección del tutorial, Configurar Prometheus, se explica cómo especificar cómo quieres que Alertmanager procese los eventos que se van a enviar.

Para configurar Alertmanager de forma que use tu webhook de Slack, sigue estos pasos:

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

Crea un secreto de Kubernetes para Alertmanager con el manifiesto YAML de ejemplo que contiene la URL del 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 las aplicaciones sin tener que modificar el código. El exportador de Blackbox de Prometheus te permite sondear endpoints como HTTP o HTTPS. Este exportador funciona bien cuando no quieres o no puedes exponer el funcionamiento interno de tu aplicación a Prometheus. El exportador de caja negra de Prometheus puede funcionar sin que tengas que modificar el código de tu aplicación para exponer métricas a Prometheus.

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

Configurar Prometheus

Una vez que hayas configurado Alertmanager para que use tu webhook de Slack, debes indicar a Prometheus qué debe monitorizar en Cymbal Bank y qué tipos de eventos quieres que te notifique Alertmanager mediante el webhook de Slack.

En la aplicación de ejemplo Cymbal Bank que usas en estos tutoriales, hay varios microservicios que se ejecutan en el clúster de GKE. Un problema que probablemente quieras conocer lo antes posible es si uno de los servicios de Cymbal Bank ha dejado de responder con normalidad a las solicitudes, lo que podría significar que tus clientes no pueden acceder a la aplicación. Puede configurar Prometheus para que responda a eventos en función de las políticas de su organización.

Comprobaciones

Puedes configurar las sondas de Prometheus para los recursos que quieras monitorizar. Estas sondas pueden generar alertas en función de la respuesta que reciban. En la aplicación de ejemplo Cymbal Bank, puedes usar sondas HTTP que comprueben los códigos de respuesta de nivel 200 de los servicios. Una respuesta de nivel HTTP 200 indica que el servicio funciona correctamente y puede responder a las solicitudes. Si hay un problema y la sonda no recibe la respuesta esperada, puedes definir reglas de Prometheus que generen alertas para que Alertmanager las procese y realice acciones adicionales.

Crea algunas comprobaciones de Prometheus para monitorizar el estado HTTP de los distintos microservicios de la aplicación de ejemplo Cymbal Bank. Consulta el siguiente archivo de manifiesto de ejemplo:

# 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, es una práctica recomendada que cada PodMonitoring sonda de actividad de Prometheus monitorice cada Deployment por separado.

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

Reglas

Prometheus necesita saber qué quieres hacer en función de la respuesta que reciban las sondas que has creado en los pasos anteriores. Esta respuesta se define mediante reglas de Prometheus.

En este tutorial, crearás reglas de Prometheus para generar alertas en función de la respuesta a la comprobación de actividad. A continuación, Alertmanager procesa el resultado de estas reglas para generar notificaciones mediante el webhook de Slack.

Crea reglas que generen eventos en función de la respuesta a las comprobaciones de actividad. Consulta el siguiente archivo de manifiesto de ejemplo:

# 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 manifiesto describe un PrometheusRule e incluye los siguientes campos:

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

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

Simular una interrupción del servicio

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

Para simular una interrupción de uno de los microservicios, reduce la contacts implementación a cero. Si no hay ninguna instancia del servicio, la aplicación de ejemplo Cymbal Bank no puede leer la información de contacto de los clientes:
```
kubectl scale deployment contacts --replicas 0
```
GKE puede tardar hasta 5 minutos en reducir la escala de la implementación.

Comprueba el estado de las implementaciones de tu clúster y verifica que la contacts implementación se reduce correctamente:

kubectl get deployments

En el siguiente ejemplo de salida, el despliegue de contacts se ha reducido correctamente a 0 instancias:

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

Una vez que la implementación de contacts se ha reducido a cero, la sonda de Prometheus informa de un código de error HTTP. Este error HTTP genera una alerta para que Alertmanager la procese.

Comprueba si en el canal de tu espacio de trabajo de Slack 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 caso de interrupción real, después de recibir la notificación en Slack, empezarías a solucionar el problema y a restaurar los servicios. En este tutorial, simula este proceso y restaura la implementación de contacts aumentando el número de réplicas:
```
kubectl scale deployment contacts --replicas 1
```
El escalado de la implementación puede tardar hasta 5 minutos y la sonda de Prometheus en recibir una respuesta HTTP 200. Puedes comprobar el estado de las implementaciones con el comando kubectl get deployments.

Cuando se recibe una respuesta correcta a la sonda de Prometheus, Alertmanager borra el evento. Deberías ver un mensaje de notificación de resolución de alerta en el canal de tu espacio 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
```

Limpieza

Te recomendamos que completes este conjunto de tutoriales de Cymbal Bank en orden. A medida que avances en el conjunto de tutoriales, adquirirás nuevas habilidades y usarás más Google Cloud productos y servicios.

Si quieres hacer un descanso antes de pasar al siguiente tutorial y evitar que se te cobren los recursos utilizados en este tutorial en tu cuenta, elimina el proyecto que has creado. Google Cloud

Precaución: Eliminar un proyecto tiene los siguientes efectos:

Se elimina todo el contenido del proyecto. Si has usado un proyecto que ya existía para las tareas de este documento, cuando lo elimines, también se eliminará cualquier otro trabajo que hayas realizado en él.
Se pierden los IDs de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID de proyecto personalizado que quieras usar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, elimina los recursos seleccionados dentro del proyecto en lugar de eliminar todo el proyecto.

Si tienes previsto consultar varias arquitecturas, tutoriales o guías de inicio rápido, reutilizar los proyectos puede ayudarte a no superar los límites de cuota de proyectos.

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.

Siguientes pasos

Consulta cómo escalar tus implementaciones en GKE en el siguiente tutorial.