Parcours de formation : applications évolutives – Surveiller avec Prometheus

Cet ensemble de tutoriels est destiné aux administrateurs et aux opérateurs informatiques qui souhaitent déployer, exécuter et gérer des environnements d'applications modernes exécutés sur l'édition Enterprise de Google Kubernetes Engine (GKE). Au fur et à mesure que vous progresserez dans cette série de tutoriels, vous allez apprendre à configurer la surveillance et les alertes, à effectuer le scaling des charges de travail et à simuler des défaillances, le tout en utilisant l'exemple d'application de microservices Cymbal Bank :

Créer un cluster et déployer un exemple d'application
Surveiller avec Google Cloud Managed Service pour Prometheus (ce tutoriel)
Effectuer le scaling des charges de travail
Simuler une défaillance
Centraliser la gestion du changement

Présentation et objectifs

L'exemple d'application Cymbal Bank utilisé dans cet ensemble de tutoriels est composée d'un certain nombre de microservices qui s'exécutent tous dans le cluster GKE. Des problèmes avec l'un de ces services peuvent entraîner une mauvaise expérience pour les clients de la banque, par exemple s'ils ne peuvent pas accéder à l'application de la banque. En apprenant le plus rapidement possible les problèmes liés aux services, vous pouvez commencer rapidement à les résoudre.

Dans ce tutoriel, vous allez apprendre à surveiller les charges de travail d'un cluster GKE à l'aide de Google Cloud Managed Service pour Prometheus et de Cloud Monitoring. Vous allez apprendre à effectuer les tâches suivantes :

Créer un webhook Slack pour Alertmanager
Configurez Prometheus pour surveiller l'état d'un exemple d'application basée sur des microservices.
Simuler une interruption et examinez les alertes envoyées à l'aide du webhook Slack

Coûts

L'activation de GKE Enterprise et le déploiement de l'exemple d'application Cymbal Bank pour cette série de tutoriels entraînent des frais par cluster pour GKE Enterprise sur Google Cloud, comme indiqué sur notre Page des tarifs, jusqu'à ce que vous désactiviez GKE Enterprise ou que vous supprimiez le projet.

Vous êtes également responsable des autres coûts Google Cloud engendrés par l'exécution de l'exemple d'application Cymbal Bank, tels que les frais pour les VM Compute Engine et Cloud Monitoring.

Avant de commencer

Pour apprendre à surveiller vos charges de travail, vous devez suivre le premier tutoriel pour créer un cluster GKE utilisant Autopilot et déployer l'exemple d'application basée sur des microservices Cymbal Bank.

Nous vous recommandons de suivre cette série de tutoriels pour Cymbal Bank dans l'ordre. Au fil de votre progression dans les tutoriels, vous apprendrez de nouvelles compétences et utilisez d'autres produits et services Google Cloud.

Afin de montrer comment un cluster GKE Autopilot peut utiliser Google Cloud Managed Service pour Prometheus afin de générer des messages sur une plate-forme de communication, ce tutoriel utilise Slack. Dans vos propres déploiements de production, vous pouvez utiliser l'outil de communication préféré de votre organisation pour traiter et distribuer les messages lorsque votre cluster GKE rencontre un problème.

Rejoignez un espace de travail Slack en vous inscrivant avec votre adresse e-mail ou en utilisant une invitation envoyée par un administrateur de l'espace de travail.
Remarque : Si vous n'êtes pas administrateur de votre espace de travail Slack, vous devrez peut-être obtenir l'approbation d'un administrateur de l'espace de travail avant d'y déployer votre application.

Créer une application Slack

Un élément important de la configuration de la surveillance consiste à vous assurer d'être averti lorsque des événements exploitables, tels que des pannes, se produisent. Un modèle courant consiste à envoyer des notifications à un outil de communication tel que Slack, qui est celui que vous utilisez dans ce tutoriel. Slack propose une fonctionnalité de webhooks qui permet aux applications externes, comme vos déploiements en production, de générer des messages. Vous pouvez utiliser d'autres outils de communication de votre organisation pour traiter et envoyer des messages en cas de problème dans votre cluster GKE.

Les clusters GKE qui utilisent Autopilot incluent une instance Google Cloud Managed Service pour Prometheus. Cette instance peut générer des alertes lorsqu'un événement se produit pour vos applications. Ces alertes peuvent ensuite utiliser un webhook Slack pour envoyer un message à votre espace de travail Slack afin que vous receviez des notifications rapides en cas de problème.

Pour configurer des notifications Slack en fonction des alertes générées par Prometheus, vous devez créer une application Slack, activer les webhooks entrants pour l'application et installer l'application dans un espace de travail Slack.

Connectez-vous à Slack à l'aide du nom de votre espace de travail et des identifiants de votre compte Slack.
Créer une application Slack
1. Dans la boîte de dialogue Créer une application, cliquez sur À partir de zéro.
2. Spécifiez un Nom d'application et choisissez votre espace de travail Slack.
3. Cliquez sur Create App (Créer l'application).
4. Sous Ajouter des fonctionnalités, cliquez sur Webhooks entrants.
5. Cliquez sur le bouton Activer les webhooks entrants.
6. Dans la section URL de webhook pour votre espace de travail, cliquez sur Ajouter un webhook à l'espace de travail.
7. Sur la page qui s'ouvre, sélectionnez un canal pour recevoir les notifications.
8. Cliquez sur Autoriser.
9. Un webhook pour votre application Slack s'affiche dans la section URL de webhook pour votre espace de travail. Enregistrez l'URL pour plus tard.

Configurer Alertmanager

Dans Prometheus, Alertmanager traite les événements de surveillance générés par vos déploiements. Alertmanager peut ignorer les événements en double, regrouper des événements associés et envoyer des notifications, par exemple en utilisant un webhook Slack. Cette section explique comment configurer Alertmanager pour qu'il utilise votre nouveau webhook Slack. La section suivante du tutoriel, Configurer Prometheus, explique comment spécifier la manière dont Alertmanager doit traiter les événements à envoyer.

Pour configurer Alertmanager afin qu'il utilise votre webhook Slack, procédez comme suit :

Changez de répertoire vers le dépôt Git qui contient tous les exemples de fichiers manifestes pour Cymbal Bank du tutoriel précédent :
```
cd ~/bank-of-anthos/
```
Si nécessaire, remplacez l'emplacement du répertoire par celui où vous avez précédemment cloné le dépôt.
Mettez à jour l'exemple de fichier manifeste YAML Alertmanager avec l'URL de webhook de votre application Slack :
```
sed -i "s@SLACK_WEBHOOK_URL@SLACK_WEBHOOK_URL@g" "extras/prometheus/gmp/alertmanager.yaml"
```
Remplacez SLACK_WEBHOOK_URL par l'URL du webhook obtenue à la section précédente.
Pour utiliser dynamiquement votre URL de webhook Slack unique sans modifier le code de l'application, vous pouvez utiliser un secret Kubernetes. Le code de l'application lit la valeur de ce secret. Dans les applications plus complexes, cette capacité vous permet de modifier ou d'alterner les valeurs pour des raisons de sécurité ou de conformité.

Créez un secret Kubernetes pour Alertmanager à l'aide de l'exemple de fichier manifeste YAML contenant l'URL du webhook Slack :
```
kubectl create secret generic alertmanager \
  -n gmp-public \
  --from-file=extras/prometheus/gmp/alertmanager.yaml
```
Prometheus peut utiliser des exportateurs pour obtenir des métriques à partir d'applications sans modifier le code. L'exportateur de boîte noire Prometheus vous permet d'examiner des points de terminaison tels que HTTP ou HTTPS. Cet exportateur fonctionne bien lorsque vous ne souhaitez pas ou ne pouvez pas exposer le fonctionnement interne de votre application à Prometheus. L'exportateur par boîte noire Prometheus peut fonctionner sans modifier le code de votre application pour exposer des métriques à Prometheus.

Déployez l'exportateur par boîte noire Prometheus sur votre cluster :
```
kubectl apply -f extras/prometheus/gmp/blackbox-exporter.yaml
```

Configurer Prometheus

Une fois que vous avez configuré Alertmanager pour utiliser votre webhook Slack, vous devez indiquer à Prometheus ce qu'il doit surveiller dans Cymbal Bank, ainsi que les types d'événements pour lesquels vous souhaitez qu'Alertmanager vous envoie une notification via le webhook Slack.

Dans l'exemple d'application Cymbal Bank que vous utilisez dans ces tutoriels, différents microservices s'exécutent dans le cluster GKE. Vous souhaiterez probablement être informé dès que possible si l'un des services de Cymbal Bank ne répond plus normalement aux requêtes, ce qui peut signifier que vos clients ne peuvent pas accéder à l'application. Vous pouvez configurer Prometheus pour qu'il réponde aux événements en fonction des règles de votre organisation.

Vérifications

Vous pouvez configurer des vérifications Prometheus pour les ressources que vous souhaitez surveiller. Ces vérifications peuvent générer des alertes en fonction de la réponse qu'elles reçoivent. Dans l'exemple d'application Cymbal Bank, vous pouvez utiliser des vérifications HTTP qui recherchent des codes de réponse de niveau 200 provenant des services. Une réponse HTTP de niveau 200 indique que le service s'exécute correctement et peut répondre aux requêtes. En cas de problème et si la vérification ne reçoit pas la réponse attendue, vous pouvez définir des règles Prometheus qui génèrent des alertes pour qu'Alertmanager les traite et effectue des actions supplémentaires.

Créez des vérifications Prometheus pour surveiller l'état HTTP des différents microservices de l'exemple d'application Cymbal Bank. Consultez l'exemple de fichier manifeste suivant :

# 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

Comme indiqué dans ce fichier manifeste, il est recommandé que chaque vérification de l'activité Prometheus PodMonitoring surveille chaque déploiement séparément.

Pour créer les vérifications de l'activité Prometheus, appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f extras/prometheus/gmp/probes.yaml
```

Règles

Prometheus doit savoir ce que vous souhaitez faire en fonction de la réponse reçue par les vérifications que vous avez créées aux étapes précédentes. Vous définissez cette réponse à l'aide de règles Prometheus.

Dans ce tutoriel, vous allez créer des règles Prometheus pour générer des alertes en fonction de la réponse à la vérification de l'activité. Alertmanager traite ensuite le résultat de ces règles pour générer des notifications à l'aide du webhook Slack.

Créez des règles qui génèrent des événements en fonction de la réponse aux vérifications de l'activité. Consultez l'exemple de fichier manifeste suivant :

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

Ce fichier manifeste décrit une règle PrometheusRule et inclut les champs suivants :

spec.groups.[*].name : nom du groupe de règles.
spec.groups.[*].interval : fréquence à laquelle les règles du groupe sont évaluées.
spec.groups.[*].rules[*].alert : nom de l'alerte.
spec.groups.[*].rules[*].expr : expression PromQL à évaluer.
spec.groups.[*].rules[*].for : durée pendant laquelle les alertes doivent être renvoyées pour être considérées comme déclenchées.
spec.groups.[*].rules[*].annotations : liste d'annotations à ajouter à chaque alerte. Cela n'est valide que pour les règles d'alerte.
spec.groups.[*].rules[*].labels : libellés à ajouter ou à écraser.

Pour créer les règles, appliquez le fichier manifeste à votre cluster :
```
kubectl apply -f extras/prometheus/gmp/rules.yaml
```

Simuler une interruption

Pour vous assurer que vos vérifications, règles et configuration Alertmanager Prometheus sont correctes, vous devez vérifier que des alertes et des notifications sont envoyées en cas de problème. Si vous ne testez pas ce flux, vous ne saurez peut-être pas qu'une interruption de vos services de production survient en cas de problème.

Pour simuler une panne de l'un des microservices, effectuez un scaling à zéro du déploiement contacts. Sans instance du service, l'exemple d'application Cymbal Bank ne peut pas lire les coordonnées des clients :
```
kubectl scale deployment contacts --replicas 0
```
GKE peut prendre jusqu'à cinq minutes pour effectuer le scaling à la baisse du déploiement.

Vérifiez l'état des déploiements dans votre cluster et assurez-vous que le déploiement contacts évolue correctement à la baisse :

kubectl get deployments

Dans l'exemple de résultat suivant, le déploiement contacts a été réduit à 0 instance :

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

Une fois le déploiement contacts réduit à zéro, la vérification Prometheus signale un code d'erreur HTTP. Cette erreur HTTP génère une alerte qu'Alertmanager traitera ensuite.

Consultez le canal de votre espace de travail Slack pour voir si un message de notification d'indisponibilité s'affiche, semblable à l'exemple suivant :
```
[FIRING:1] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```
Dans un scénario de panne réelle, après avoir reçu la notification dans Slack, vous commencez à dépanner et à restaurer les services. Pour ce tutoriel, simulez ce processus et restaurez le déploiement contacts en réduisant le nombre d'instances répliquées :
```
kubectl scale deployment contacts --replicas 1
```
Le scaling du déploiement et la réception d'une réponse HTTP 200 par la vérification Prometheus peuvent prendre jusqu'à cinq minutes. Vous vérifiez l'état des déploiements à l'aide de la commande kubectl get deployments.

Lorsqu'une réponse correcte est reçue pour la vérification Prometheus, Alertmanager efface l'événement. Un message de notification indiquant la résolution de l'alerte doit s'afficher dans le canal de votre espace de travail Slack, semblable à l'exemple suivant :
```
[RESOLVED] ContactsUnavailable
Severity: Warning :warning:
Summary: Contacts Service is unavailable
Namespace: default
Check Contacts pods and it's logs
```

Effectuer un nettoyage

Si vous souhaitez faire une pause avant de passer au tutoriel suivant et éviter que des frais ne soient facturés sur votre compte Google Cloud pour les ressources utilisées dans ce tutoriel, supprimez le projet que vous avez créé.

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

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.

Étape suivante

Découvrez comment effectuer le scaling de vos déploiements dans GKE dans le tutoriel suivant.