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 qui peuvent affecter une règle d'alerte (par exemple, le choix de la période de nouveau test), consultez Comportement des règles d'alerte basées sur les métriques.

La règle d'utilisation du disque crée des alertes inattendues

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. Toutefois, cette règle crée des alertes lorsque l'utilisation du disque de chaque disque physique est inférieure au seuil.

La cause de ces alertes inattendues 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'une alerte pour 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.*.

Causes courantes des alertes d'anomalies

Vous avez créé une règle d'alerte, mais elle semble créer des alertes prématurément ou de manière incorrecte.

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

  • En cas de manque de données, en particulier pour les règles d'alerte avec des conditions d'absence de métrique ou de seuil "inférieur à", une alerte peut être créée et sembler anormale. Parfois, l'alerte n'indique pas le manque de données, et parfois, il est corrigé automatiquement :

    • 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 à déclencher une alerte.

    • 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 fossé dans une métrique basée sur les journaux qui ne peut plus être vue pourra être la cause de la création d'une alerte 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ù elle est évaluée et celui où l'alerte correspondante est visible dans Monitoring.

  • Les conditions configurées pour créer une alerte sur une seule mesure peuvent entraîner des alertes qui semblent prématurées ou incorrectes. Pour éviter cette situation, vous devez vérifier que plusieurs mesures sont requises avant la création d'une alerte. Pour ce faire, définissez la période de nouveau test 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 fenêtre de retest sur au moins trois minutes. Si vous définissez la période de nouveau test sur la valeur la plus récente, ou l'équivalent de 0 seconde, une seule mesure peut entraîner la création d'une alerte.

  • 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'alertes qui remplissent les conditions d'origine de la règle d'alerte.

  • Lorsque des données de série temporelle arrivent, il peut s'écouler jusqu'à une minute avant qu'elles ne se propagent dans toute l'infrastructure d'alerte. Au cours de ce processus, une règle d'alerte peut évaluer une condition comme étant remplie, même si les données de série temporelle ne se sont pas propagées au graphique de série temporelle. Par conséquent, vous pouvez recevoir une notification même si le graphique n'indique pas que la condition est remplie. Pour réduire ce risque, utilisez une période d'alignement d'au moins cinq minutes.

  • Le changement de nom du libellé App Hub metadata.system_labels.apphub_host_project_id en metadata.system_labels.apphub_application_container peut entraîner la génération de nouvelles alertes et la non-fermeture de certaines alertes ouvertes.

    Aucune action n'est requise. Les alertes se ferment automatiquement lorsque les données cessent d'arriver, une fois la durée de fermeture automatique expirée. Pour en savoir plus, consultez Données de métrique partielles.

L'alerte n'est pas fermée lorsque les données cessent d'arriver

Vous suivez les conseils de la section Données de métriques partielles et configurez une règle d'alerte pour fermer les alertes lorsque les données cessent d'arriver. Dans certains cas, les données cessent d'arriver, mais une alerte ouverte n'est pas fermée automatiquement.

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. Si l'état d'une ressource est connu comme étant désactivé, Monitoring ne ferme pas automatiquement les alertes lorsque les données cessent d'arriver. Toutefois, vous pouvez fermer manuellement ces alertes.

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

Accédez à la page des alertes dans la console Google Cloud et sélectionnez une alerte à 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 alertes, à l'exception des données de métriques, vérifiez que vous disposez des rôles IAM (Identity and Access Management) Lecteur des incidents de la console Cloud Monitoring (roles/monitoring.cloudConsoleIncidentViewer) et Lecteur de comptes Stackdriver (roles/stackdriver.accounts.viewer).

Pour afficher tous les détails des alertes, y compris les données de métriques, et pour pouvoir accuser réception des alertes ou les fermer, vérifiez que vous disposez des rôles IAM Lecteur Monitoring (roles/monitoring.viewer) et Éditeur d'incidents de la console Cloud Monitoring (roles/monitoring.cloudConsoleIncidentEditor).

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

L'alerte n'est pas créée lorsque la condition est remplie

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

Si l'un des critères suivants est rempli après que la condition de la règle d'alerte est satisfaite, Monitoring n'ouvre pas l'alerte.

  • La règle d'alerte est mise en veille.
  • La règle d'alerte est désactivée.
  • La règle d'alerte a atteint le nombre maximal d'alertes qu'elle peut ouvrir simultanément.

  • L'état de la ressource que la règle d'alerte surveille est connu pour être désactivé. La surveillance peut déterminer l'état d'une ressource lorsque celle-ci contient le libellé metadata.system_labels.state et que la règle d'alerte n'est pas rédigée avec le langage de requête Monitoring.

La liste des détails de l'alerte indique un projet incorrect

Vous recevez une notification et le récapitulatif des conditions indique le projetGoogle Cloud dans lequel l'alerte a été créée, c'est-à-dire le projet de définition du champ d'application. Toutefois, vous vous attendez à ce que l'alerte liste le nom du projet Google Cloud qui stocke la série temporelle à l'origine de la création de l'alerte par Monitoring.

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 éliminent le libellé qui stocke l'ID du projet, les informations sur l'alerte listent le projet de champ d'application. Par exemple, si vous regroupez les données uniquement par zone, le libellé qui stocke l'ID du projet est supprimé après le regroupement.

  • Lorsque les options d'agrégation conservent le libellé qui stocke l'ID du projet, les notifications d'alerte incluent le nom du projet Google Cloud qui stocke la série temporelle à l'origine de l'alerte. Pour conserver le libellé de l'ID de projet, incluez le libellé project_id dans le champ de regroupement ou ne regroupez pas les séries temporelles.

Impossible de fermer manuellement une alerte

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

Unable to close alert with active conditions.

Vous ne pouvez fermer une alerte que si aucune observation n'est reçue au cours de 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'une alerte ne peut pas être fermée en raison d'une erreur interne :

Unable to close alert. 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'alerte.

Pour en savoir plus, consultez Gérer les alertes.

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 et à ce qu'une alerte soit créée lorsque toutes les conditions sont remplies. Toutefois, vous recevez plusieurs notifications et constatez que plusieurs alertes sont créées.

Monitoring envoie une notification et crée une alerte pour chaque série temporelle qui entraîne le respect d'une condition. Par conséquent, lorsque vous avez des règles d'alerte avec plusieurs conditions, vous pouvez potentiellement recevoir une notification et une alerte pour chaque série temporelle qui entraîne le respect des conditions associées.

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

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

Pour en savoir plus, consultez Quand Monitoring envoie-t-il des notifications et crée-t-il des alertes ?.

La variable d'une étiquette de métrique a une valeur 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 du libellé auquel la variable fait référence. Toutefois, la valeur de la variable est définie sur null.

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

  • Vérifiez que les paramètres d'agrégation de la règle d'alerte conservent le libellé que vous souhaitez afficher.

    Par exemple, supposons que vous créiez une règle d'alerte qui surveille les octets de disque écrits par les instances de VM. Vous souhaitez que la documentation liste l'appareil à l'origine de la notification. Vous ajoutez donc le texte suivant au champ de documentation : device: ${metric.label.device}.

    Vous devez également vérifier que vos paramètres d'agrégation conservent la valeur du libellé device. Vous pouvez conserver ce libellé en définissant la fonction d'agrégation sur none ou en vérifiant 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 les notifications avec une documentation définie par l'utilisateur.

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

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, et la règle d'alerte ne reflète pas la modification 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.

Échec de la création d'une règle d'alerte dans l'API en raison d'une métrique manquante

Vous avez récemment créé une métrique, puis vous y avez fait référence lorsque vous avez essayé de créer une règle d'alerte dans l'API Cloud Monitoring. Toutefois, la commande d'API échoue et affiche l'erreur suivante :

Error 404: Cannot find metric(s) that match type = "METRIC_NAME".
If a metric was created recently, it could take up to 10 minutes to become
available. Please try again soon.

Pour résoudre ce problème, attendez au moins dix minutes, puis renvoyez la requête API.

Le graphique de la règle d'alerte n'affiche pas le seuil dépassé

Vous avez reçu une notification indiquant qu'une alerte a été ouverte pour votre règle d'alerte. Toutefois, lorsque vous accédez à la page d'informations sur la règle, le graphique n'indique pas que le seuil a été dépassé.

Pour résoudre ce problème, essayez de raccourcir la période du graphique. Vous pouvez raccourcir la période à l'aide du sélecteur de période dans la barre d'outils ou en mettant en surbrillance des périodes sur le graphique avec votre pointeur.

La résolution des graphiques est limitée. Il est donc possible que toutes les mesures ne s'affichent pas pour certaines périodes.