Cette page a été traduite par l'API Cloud Translation.

Résoudre les problèmes de notifications manquantes

Cette page explique pourquoi vous ne recevez peut-être pas les notifications comme prévu et présente les solutions possibles pour ces situations.

Les notifications ne sont pas reçues

Vous configurez des canaux de notification et vous attendez à recevoir une notification en cas d'incidents. Or, vous ne recevez aucune notification.

Pour obtenir des informations sur la cause de l'échec, procédez comme suit:

Dans la console Google Cloud, accédez à la page Explorateur de journaux.
Accéder à l'explorateur de journaux

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.
Sélectionnez le projet Google Cloud approprié.
Interrogez les journaux pour les événements de canal de notification:
1. Développez le menu Log name (Nom du journal), puis sélectionnez notification_channel_events.
2. Développez le menu Gravité, puis sélectionnez Erreur.
3. Facultatif: Pour sélectionner une période personnalisée, utilisez le sélecteur de période.
4. Cliquez sur Exécuter la requête.
Les étapes précédentes créent la requête suivante:
```
resource.type:"stackdriver_notification_channel"
logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR
```
La ligne de résumé et le champ jsonPayload contiennent généralement des informations sur les échecs. Par exemple, lorsqu'une erreur de passerelle se produit, la ligne récapitulative inclut "failed with 502 Bad Gateway" (Échec avec 502 Bad Gateway).

Les notifications du webhook ne sont pas reçues

Vous configurez un canal de notification Webhook et vous attendez à recevoir une notification en cas d'incidents. Or, vous ne recevez aucune notification.

Point de terminaison privé

Vous ne pouvez pas utiliser de webhooks pour les notifications, sauf si le point de terminaison est public.

Pour résoudre ce problème, utilisez des notifications Pub/Sub combinées à un abonnement pull à ce sujet de notification.

Lorsque vous configurez un canal de notification Pub/Sub, les notifications d'incident sont envoyées à une file d'attente Pub/Sub dotée de contrôles Identity and Access Management. Tout service autorisé à interroger ou à écouter un sujet Pub/Sub peut utiliser ces notifications. Par exemple, les applications exécutées sur des machines virtuelles App Engine, Cloud Run ou Compute Engine peuvent utiliser ces notifications.

Si vous utilisez un abonnement pull, une requête est envoyée à Google, et attend la réception d'un message. Ces abonnements nécessitent un accès à Google mais ne nécessitent pas de règles pour les pare-feu ou l'accès entrant.

Point de terminaison public

Pour identifier la raison de l'échec de distribution, examinez les entrées de journal Cloud Logging pour obtenir des informations sur les échecs.

Par exemple, vous pouvez rechercher des entrées de journal correspondant à la ressource du canal de notification à l'aide de l'explorateur de journaux et d'un filtre semblable à celui-ci :

resource.type="stackdriver_notification_channel"

Les notifications Pub/Sub ne sont pas reçues

Vous configurez un canal de notification Pub/Sub, mais vous ne recevez aucune notification.

Pour résoudre cette condition, procédez comme suit :

Assurez-vous que le compte de service des notifications existe. Les notifications ne sont pas envoyées lorsque le compte de service a été supprimé.

Pour vérifier que le compte de service existe, procédez comme suit :
1. Dans la console Google Cloud, accédez à la page IAM :
  Accéder à IAM
  
  Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.
2. Recherchez un compte de service qui suit la convention d'attribution de noms suivante:
```
service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
```
  Si ce compte de service n'est pas répertorié, sélectionnez Inclure les attributions de rôles fournies par Google.
Si le compte de service de notifications n'existe pas, vous devez commencer à créer le canal de notification Pub/Sub pour que Monitoring crée le compte de service:
1. Dans la console Google Cloud, accédez à la page Alertes :
  Accéder à l'interface des alertes
  
  Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
2. Cliquez sur Modifier les canaux de notification.
3. Dans la section Pub/Sub, cliquez sur Nouveau.
  
  La surveillance crée le compte de service des notifications lorsqu'il n'existe pas. La boîte de dialogue Créer un canal Pub/Sub affiche le nom du compte de service de notification.
  
  Remarque :Vous n'avez pas besoin de terminer la création du canal de notification Pub/Sub pour que Monitoring crée le compte de service de notification.
4. Si vous ne souhaitez pas ajouter de canal de notification, cliquez sur Annuler. Sinon, terminez de créer le canal de notification, puis cliquez sur Ajouter un canal.
5. Accordez au compte de service les autorisations nécessaires pour publier vos sujets Pub/Sub:
  1. Dans un nouvel onglet de navigateur, ouvrez le document Créer un canal de notification.
  2. Sélectionnez l'onglet Pub/Sub, puis suivez les étapes de la section Autoriser un compte de service de la page.
Assurez-vous que le compte de service des notifications a été autorisé à envoyer des notifications pour les sujets Pub/Sub qui vous intéressent.

Pour afficher les autorisations d'un compte de service, vous pouvez utiliser la console Google Cloud ou la commande Google Cloud CLI:
- La page IAM dans la console Google Cloud répertorie les rôles de chaque compte de service.
- La page Sujets Pub/Sub dans la console Google Cloud répertorie chaque sujet. Lorsque vous sélectionnez un sujet, l'onglet Autorisations répertorie les rôles attribués aux comptes de service.
- Pour répertorier tous les comptes de service et leurs rôles, exécutez la commande Google Cloud CLI suivante:
```
gcloud projects get-iam-policy PROJECT_ID
```
  Voici une réponse partielle de cette commande :
```
    serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/monitoring.notificationServiceAgent
     - members:
       [...]
       role: roles/owner
     - members:
       - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/pubsub.publisher
```
  La réponse de la commande n'inclut que les rôles, elle n'inclut pas l'autorisation par sujet.
- Pour répertorier les liaisons IAM d'un sujet spécifique, exécutez la commande suivante :
```
gcloud pubsub topics get-iam-policy TOPIC
```
  Voici un exemple de réponse pour cette commande :
```
    bindings:
    - members:
      - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
      role: roles/pubsub.publisher
    etag: BwXPRb5WDPI=
    version: 1
```
Pour en savoir plus sur l'autorisation du compte de service des notifications, consultez la section Autoriser le compte de service.

Les notifications pour les règles d'alerte des tests de disponibilité ne sont pas reçues

Vous souhaitez être averti si une machine virtuelle (VM) redémarre ou s'arrête. Vous créez donc une règle d'alerte qui surveille la métrique compute.googleapis.com/instance/uptime. Vous créez et configurez la condition pour générer un incident en l'absence de données de métriques. Vous ne définissez pas la condition à l'aide du langage de requête Monitoring (MQL)¹. Vous ne recevez pas de notification lorsque la machine virtuelle (VM) redémarre ou s'arrête.

Cette règle d'alerte ne surveille que les séries temporelles des instances de VM Compute Engine à l'état RUNNING. Les séries temporelles des VM qui se trouvent dont l'état est tel que STOPPED ou DELETED, sont exclues avant l'évaluation de la condition En raison de ce comportement, vous ne pouvez pas utiliser de règle d'alerte avec une condition d'alerte d'absence de métrique pour déterminer si une instance de VM est en cours d'exécution. Pour en savoir plus sur les états des instances de VM, consultez la section Cycle de vie des instances de VM.

Pour résoudre ce problème, créez un test de disponibilité surveillé par une règle d'alerte. Pour les points de terminaison privés, utilisez des vérifications de l'état de disponibilité privées.

Une alternative aux alertes sur les tests de disponibilité consiste à utiliser des règles d'alerte qui surveillent l'absence de données. Nous vous recommandons vivement de définir des alertes sur les vérifications de disponibilité plutôt que sur l'absence de données. Les règles d'alerte en cas d'absence de métrique peuvent générer des faux positifs en cas de problèmes temporaires de disponibilité des données de surveillance.

Toutefois, si l'utilisation de tests de disponibilité n'est pas possible, vous pouvez créer une règle d'alerte avec MQL qui vous avertit si la VM a été arrêtée. Les conditions définies par MQL ne préfiltrent pas les données de séries temporelles en fonction de l'état de l'instance de VM. Comme MQL ne filtre pas les données par état des VM, vous pouvez l'utiliser pour détecter l'absence de données des VM arrêtées.

Prenons la condition MQL suivante qui surveille le champ compute.googleapis.com/instance/cpu/utilization :

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m

Si une VM surveillée par cette condition est arrêtée, trois minutes plus tard, un incident est généré et des notifications sont envoyées. La valeur absent_for doit être d'au moins trois minutes.

Pour en savoir plus sur MQL, consultez la page Règles d'alerte avec MQL.

¹: MQL est un langage expressif textuellement qui peut être utilisé avec les appels d'API Cloud Monitoring et dans la console Google Cloud. Pour configurer une condition avec MQL lorsque vous utilisez la console Google Cloud, vous devez utiliser l'éditeur de code.

Les notifications pour les règles d'alerte basées sur le nombre de requêtes ne sont pas reçues

Vous souhaitez surveiller le nombre de requêtes terminées. Vous avez créé une règle d'alerte qui surveille la métrique serviceruntime.googleapis.com/api/request_count, mais vous n'êtes pas averti lorsque le nombre de requêtes dépasse le seuil que vous avez configuré.

La période d'alignement maximale pour la métrique "Nombre de requêtes" est de 7 heures et 30 minutes.

Pour résoudre ce problème, vérifiez la valeur de la période d'alignement dans votre règle d'alerte. Si la valeur est supérieure à la valeur maximale pour cette métrique, réduisez la période d'alignement afin qu'elle ne dépasse pas 7 heures et 30 minutes.