Résoudre les problèmes liés aux règles d'alerte

Cette page explique pourquoi certaines règles d'alerte peuvent se comporter différemment que la manière prévue et présente les solutions possibles pour ces situations.

Pour en savoir plus sur les variables pouvant affecter une règle d'alerte, en fonction de l'intervalle de temps choisi, consultez la section Comportement des règles d'alerte basées sur les métriques.

La variable d'un libellé de métrique est nulle

Vous créez une règle d'alerte et ajoutez une variable pour un libellé de métrique à la section de documentation. Vous vous attendez à ce que les notifications affichent la valeur de la variable. Toutefois, cette valeur est définie sur null.

Pour résoudre ce problème, procédez comme suit :

Assurez-vous que les paramètres d'agrégation de la règle d'alerte préservent le libellé que vous souhaitez afficher.

Par exemple, supposons que vous créez une règle d'alerte qui surveille les octets de disque écrits par les instances de VM. Si vous souhaitez que la documentation répertorie l'appareil à l'origine de la notification, vous devez ajouter le code suivant dans le champ de documentation: device: ${metric.label.device}.

Vous devez également vous assurer que vos paramètres d'agrégation préservent la valeur du libellé device. Vous pouvez conserver cette étiquette en définissant la fonction d'agrégation sur none ou en vous assurant que les sélections de regroupement incluent device.
Vérifiez la syntaxe et l'applicabilité de la variable. Pour en savoir plus sur la syntaxe, consultez Annoter des alertes avec la documentation définie par l'utilisateur.

Par exemple, la variable log.extracted_label.KEY n'est compatible qu'avec les alertes basées sur les journaux. Cette variable s'affiche toujours sous la forme null lorsqu'une règle d'alerte surveille une métrique, même une métrique basée sur les journaux.

La règle d'utilisation du disque crée des incidents inattendus

Vous avez créé une règle d'alerte pour surveiller la capacité "utilisée" des disques de votre système. Cette règle surveille la métrique agent.googleapis.com/disk/percent_used. Vous vous attendez à recevoir une notification que lorsque l'utilisation d'un disque physique dépasse le seuil que vous avez défini dans la condition. Or, cette règle crée des incidents lorsque l'utilisation de tous les disques physiques est inférieure au seuil.

La cause de cet incident inattendu est que les conditions ne sont pas limitées à la surveillance des disques physiques. À la place, ces règles surveillent tous les disques, y compris les disques virtuels, tels que les appareils de rebouclage. Si un disque virtuel est construit de sorte que son utilisation est de 100%, cela entraîne la création d'un incident de la règle.

Par exemple, considérons le résultat suivant de la commande Linux df, qui indique l'espace disque disponible sur les systèmes de fichiers installés, pour un système :

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

Pour ce système, une règle d'alerte d'utilisation du disque doit être configurée pour filtrer les séries temporelles des appareils de rebouclage /dev/loop0 et /dev/loop1. Par exemple, vous pouvez ajouter le filtre device !=~ ^/dev/loop.*, qui exclut toutes les séries temporelles dont le libellé device ne correspond pas à l'expression régulière ^/dev/loop.*.

La règle de disponibilité ne crée pas d'alerte attendue

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 tests de disponibilité privés.

Plutôt que d'envoyer des alertes sur les tests de disponibilité, vous pouvez utiliser des règles d'alerte qui surveillent l'absence de données. Nous vous recommandons vivement d'alerter sur les tests de disponibilité plutôt que d'absence de données: les alertes d'absence peuvent générer des faux positifs en cas de problèmes temporaires de disponibilité des données Monitoring.

Toutefois, s'il n'est pas possible d'utiliser des tests de disponibilité, vous pouvez créer une règle d'alerte avec MQL qui vous informe que 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 textuel expressif 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.

La règle de nombre de requêtes ne crée pas d'alertes attendues

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 durée d'alignement maximale pour la métrique de 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 de cette métrique, réduisez la période d'alignement pour qu'elle ne dépasse pas 7 heures 30 minutes.

Causes courantes d'incidents anormaux

Vous avez créé une règle d'alerte, et celle-ci semble créer des incidents de manière prématurée ou incorrecte.

Plusieurs raisons peuvent expliquer pourquoi vous recevez une notification d'incident qui semble incorrecte :

S'il existe un écart dans les données, en particulier pour ces règles d'alerte avec des conditions d'absence de métrique ou de seuil "inférieur à", un incident peut être créé qui semble anormal. Parfois, l'incident n'indique pas l'écart de données et parfois celui-ci est automatiquement corrigé:
- Dans les graphiques, par exemple, les écarts peuvent ne pas apparaître, car les valeurs des données manquantes sont interpolées. Même lorsque plusieurs minutes de données sont manquantes, le graphique connecte les points manquants pour des raisons de continuité visuelle. Un tel fossé dans les données sous-jacentes peut suffire pour qu'une règle d'alerte crée un incident.
- Les points dans les métriques basées sur les journaux peuvent arriver en retard et être remplis, jusqu'à 10 minutes en arrière. Le comportement du remplissage corrige efficacement le fossé, qui est rempli lorsque les données arrivent enfin. Ainsi, un écart dans une métrique basée sur les journaux qui n'est plus visible peut avoir entraîné la création d'un incident par une règle d'alerte.
Les conditions d'absence de métrique ou de seuil "inférieur à" sont évaluées en temps réel, avec un délai de requête réduit. L'état de la condition peut changer entre le moment où il est évalué et le moment où l'incident correspondant s'affiche dans Monitoring.
Les conditions configurées pour créer un incident sur une seule mesure peuvent entraîner des incidents qui semblent prématurés ou incorrects. Pour éviter cette situation, assurez-vous que plusieurs mesures sont requises avant la création d'un incident en définissant le champ de durée d'une condition sur une valeur supérieure au double du taux d'échantillonnage de la métrique.

Par exemple, si une métrique est échantillonnée toutes les 60 secondes, définissez la durée sur au moins trois minutes. Si vous définissez le champ de durée sur la valeur la plus récente, ou l'équivalent de 0 seconde, une seule mesure peut entraîner la création d'un incident.
Lorsque la condition d'une règle d'alerte est modifiée, la propagation de la modification dans l'infrastructure d'alerte peut prendre plusieurs minutes. Au cours de cette période, vous pouvez recevoir une notification d'incidents qui remplissent les conditions d'origine de la règle d'alerte.
La propagation des données de séries temporelles dans l'ensemble de l'infrastructure d'alerte peut demander jusqu'à une minute. Lorsque la période d'alignement est définie sur une minute ou sur l'échantillon le plus récent, la latence de propagation peut donner l'impression que la règle d'alerte se déclenche à tort. Pour réduire ce risque, utilisez une période d'alignement d'au moins cinq minutes.

L'incident n'est pas clos lorsque les données cessent d'arriver

Suivez les instructions de la section Données de métriques partielles et configurez une règle d'alerte pour fermer les incidents lorsque les données cessent d'arriver. Dans certains cas, les données cessent d'arriver, mais un incident ouvert n'est pas automatiquement fermé.

Si la ressource sous-jacente surveillée par une règle d'alerte contient le libellé metadata.system_labels.state, et si cette règle n'est pas écrite avec le langage de requête Monitoring, Monitoring peut déterminer l'état de la ressource. S'il est connu que l'état d'une ressource est désactivé, Monitoring ne ferme pas automatiquement les incidents lorsque les données cessent d'arriver. Toutefois, vous pouvez fermer ces incidents manuellement.

La règle à plusieurs conditions crée plusieurs notifications

Vous avez créé une règle d'alerte contenant plusieurs conditions, que vous avez regroupées avec un AND logique. Vous vous attendez à recevoir une notification pour un incident créé lorsque toutes les conditions sont remplies. Cependant, vous recevez plusieurs notifications et vous constatez que plusieurs incidents ont été créés.

Monitoring envoie une notification et crée un incident pour chaque série temporelle qui entraîne le remplissage d'une condition. Par conséquent, lorsque vous disposez de règles d'alerte avec plusieurs conditions, il est possible que vous receviez une notification et un incident pour chaque série temporelle qui entraîne le remplissage des conditions de jointure.

Par exemple, imaginons que vous ayez une règle d'alerte avec deux conditions, chacune d'elles devant surveiller trois séries temporelles. La règle n'envoie une notification que lorsque les deux conditions sont remplies. Lorsque les conditions de votre règle sont remplies, vous pouvez recevoir entre deux notifications et incidents (une série temporelle est remplie dans chaque condition) et six (toutes les séries temporelles sont remplies dans chaque condition).

Vous ne pouvez pas configurer Monitoring pour créer un seul incident et envoyer une seule notification.

Pour en savoir plus, consultez la section Notifications par incident.

Impossible d'afficher les détails de l'incident en raison d'une erreur d'autorisation

Accédez à la page "Incidents" dans la console Google Cloud, puis sélectionnez un incident à afficher. La page d'informations devrait s'ouvrir. Toutefois, la page d'informations ne s'ouvre pas et un message "Autorisation refusée" s'affiche.

Pour afficher tous les détails des incidents, à l'exception des données de métriques, assurez-vous de disposer des rôles Identity and Access Management (IAM) de lecteur des incidents Monitoring dans la console Cloud (roles/monitoring.cloudConsoleIncidentViewer) et de lecteur de comptes Stackdriver (roles/stackdriver.accounts.viewer).

Pour afficher tous les détails des incidents, y compris les données de métriques, et pour pouvoir accuser réception ou fermer les incidents, assurez-vous de disposer des rôles IAM Lecteur Monitoring (roles/monitoring.viewer) et Éditeur d'incidents Monitoring (roles/monitoring.cloudConsoleIncidentEditor) dans Cloud Console.

Les rôles personnalisés n'accordent pas l'autorisation requise pour afficher les détails de l'incident.

L'incident n'est pas créé lorsque la condition est remplie

Vous avez créé une règle d'alerte comportant une condition. Le graphique d'alerte indique que les données surveillées ne respectent pas la condition, mais que vous n'avez pas reçu de notification et qu'aucun incident n'a été créé.

Si l'un des critères suivants est vrai une fois que la condition de la règle d'alerte est remplie, Monitoring n'ouvre pas l'incident.

La règle d'alerte est mise en attente.
La règle d'alerte est désactivée.
La règle d'alerte a atteint le nombre maximal d'incidents qu'elle peut ouvrir simultanément.
L'état de la ressource surveillée par la règle d'alerte est connu comme étant désactivé. Monitoring peut déterminer l'état d'une ressource lorsque celle-ci contient le libellé metadata.system_labels.state et lorsque la règle d'alerte n'est pas écrite avec le langage de requête Monitoring.

Liste des détails de l'incident incorrecte dans le projet

Vous recevez une notification et le résumé des conditions répertorie le projet Google Cloud dans lequel l'incident a été créé, c'est-à-dire le projet effectuant une surveillance. Cependant, vous vous attendez à ce que l'incident indique le nom du projet Google Cloud qui stocke la série temporelle qui a amené Monitoring à créer l'incident.

Les options d'agrégation spécifiées dans la condition d'une règle d'alerte déterminent le projet Google Cloud référencé dans une notification:

Lorsque les options d'agrégation suppriment l'étiquette qui stocke l'ID du projet, les informations sur l'incident indiquent le projet effectuant une surveillance. Par exemple, si vous ne regroupez les données que par zone, l'étiquette qui stocke l'ID du projet est supprimée après le regroupement.
Lorsque les options d'agrégation conservent l'étiquette qui stocke l'ID du projet, les notifications d'incident incluent le nom du projet Google Cloud qui stocke la série temporelle à l'origine de l'incident. Pour conserver le libellé de l'ID du projet, incluez le libellé project_id dans le champ de regroupement ou ne regroupez pas les séries temporelles.

Impossible de fermer manuellement un incident

Vous avez reçu une notification concernant un incident sur votre système. Accédez à la page des détails de l'incident, puis cliquez sur Fermer l'incident. Vous vous attendez à ce que l'incident soit fermé, mais vous recevez le message d'erreur suivant :

Unable to close incident with active conditions.

Vous ne pouvez fermer un incident que lorsqu'aucune observation ne se produit dans la période d'alerte la plus récente. La période d'alerte, dont la valeur par défaut est généralement de cinq minutes, est définie dans la condition de la règle d'alerte et est configurable. Le message d'erreur précédent indique que des données ont été reçues au cours de la période d'alerte.

L'erreur suivante se produit lorsqu'un incident ne peut pas être fermé en raison d'une erreur interne :

Unable to close incident. Please try again in a few minutes.

Lorsque le message d'erreur précédent s'affiche, vous pouvez essayer de fermer l'opération ou laisser Monitoring fermer automatiquement l'incident.

Pour en savoir plus, consultez la page Gérer les incidents.

Aucune notification reçue

Vous configurez des canaux de notification et attendez d'être averti en cas d'incident. Or, vous ne recevez aucune notification.

Pour en savoir plus sur la résolution des problèmes liés aux notifications Webhook et Pub/Sub, consultez les sections suivantes de ce document:

Les notifications de webhook ne sont pas reçues
Les notifications Pub/Sub ne sont pas reçues

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

Dans le panneau de navigation de la console Google Cloud, sélectionnez Logging, puis Explorateur de journaux :
Accéder à l'explorateur de journaux
Sélectionnez le projet Google Cloud approprié.
Interrogez les journaux sur les événements du canal de notification:
1. Développez le menu 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:
```
logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR
```
Les informations d'échec sont généralement incluses dans la ligne récapitulative et dans le champ jsonPayload.

La ligne de résumé et le champ jsonPayload contiennent généralement des informations sur l'échec. Par exemple, lorsqu'une erreur de passerelle se produit, la ligne récapitulative inclut "échec avec l'erreur 502 Passerelle incorrecte".

Aucune nouvelle donnée après la modification des définitions des métriques

Vous modifiez la définition d'une métrique définie par l'utilisateur, par exemple en modifiant le filtre que vous avez utilisé dans une métrique basée sur les journaux. La règle d'alerte ne reflète pas la modification que vous avez apportée à la définition de la métrique.

Pour résoudre ce problème, forcez la mise à jour de la règle d'alerte en modifiant son nom à afficher.

Les notifications de webhook envoyées à Google Chat ne sont pas reçues

Vous allez configurer un canal de notification de webhook dans Monitoring, puis l'envoyer à Google Chat. Cependant, vous ne recevez pas de notifications ou vous recevez des erreurs 400 Bad Request.

Pour résoudre ce problème, configurez un canal de notification Pub/Sub dans Monitoring, puis configurez un service Cloud Run pour convertir les messages Pub/Sub au format attendu par Chat, puis transmettre la notification à Google Chat. Pour obtenir un exemple de cette configuration, consultez la page Créer des notifications personnalisées avec Cloud Monitoring et Cloud Run.

Les notifications de 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 le panneau de navigation de la console Google Cloud, sélectionnez IAM :
  Accéder à IAM
2. Recherchez un compte de service respectant 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 des notifications n'existe pas, vous devez lancer le processus de création du canal de notification Pub/Sub pour permettre à Monitoring de créer le compte de service:
1. Dans le panneau de navigation de la console Google Cloud, sélectionnez Monitoring, puis Alertes :
  Accéder à l'interface des alertes
2. Cliquez sur Modifier les canaux de notification.
3. Dans la section Pub/Sub, cliquez sur Nouveau.
  
  Monitoring crée le compte de service de notifications s'il n'en existe pas. La boîte de dialogue Créer un canal Pub/Sub affiche le nom du compte de service de notifications.
  
  Remarque :Il n'est pas nécessaire de terminer la création du canal de notification Pub/Sub pour que Monitoring crée le compte de service de notifications.
4. Si vous ne souhaitez pas ajouter de canal de notification, cliquez sur Annuler. Sinon, terminez la création du canal de notification et 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 le 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 de la console Google Cloud répertorie les rôles de chaque compte de service.
- La page Sujets de Pub/Sub de 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.