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, par exemple en choisissant une fenêtre de nouveau test, consultez Comportement des règles d'alerte basées sur des 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. Cependant, cette règle crée des alertes lorsque l'utilisation de chaque disque physique est inférieure au seuil.

Une cause connue d'alertes inattendues pour ces règles 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 manière à ce que son utilisation soit de 100 %, une alerte est créée 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 l'étiquette device ne correspond pas à l'expression régulière ^/dev/loop.*.

Causes courantes des alertes d'anomalie

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

Plusieurs raisons peuvent expliquer pourquoi vous recevez des notifications d'alertes qui semblent incorrectes :

  • S'il existe un écart dans les 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'affiche pas l'écart de données, et parfois l'écart de données 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 écart dans les données sous-jacentes peut suffire à une règle d'alerte pour créer une alerte.

    • Les points des métriques basées sur les journaux peuvent arriver en retard et être renseignés rétroactivement, jusqu'à 10 minutes dans le passé. 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 amené une règle d'alerte à créer une 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 le moment 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, vérifiez que plusieurs mesures sont requises avant la création d'une alerte en définissant la fenêtre 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 nouveau test sur au moins trois minutes. Si vous définissez la fenêtre de nouveau test sur valeur la plus récente, ou de manière équivalente sur 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. Pendant cette période, vous pouvez recevoir des notifications d'alertes qui remplissent les conditions de la règle d'alerte d'origine.

  • Lorsque des données de séries temporelles arrivent, leur propagation dans l'ensemble de l'infrastructure d'alerte peut prendre jusqu'à une minute. Au cours de ce processus, une règle d'alerte peut évaluer une condition comme étant remplie, même si les données de la série temporelle n'ont pas été propagées au graphique de la 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 le risque de rencontrer cette situation, 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 empêcher la fermeture de certaines alertes ouvertes.

    Aucune action n'est requise. Les alertes se ferment automatiquement lorsque les données cessent d'arriver, après l'expiration de la durée de fermeture automatique. Pour en savoir plus, consultez Données de métriques partielles.

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

Vous 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 reste ouverte. Par exemple, si vous surveillez des charges de travail éphémères telles que des pods Google Kubernetes Engine, des jobs ou des révisions Cloud Run, ou des tâches par lot, une alerte peut rester ouverte une fois la charge de travail terminée et l'arrivée des données de métriques interrompue.

Si la ressource sous-jacente surveillée par une règle d'alerte contient l'étiquette 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 désactivé, Monitoring ne ferme pas automatiquement les alertes lorsque les données cessent d'arriver.

Pour résoudre ce problème, utilisez l'une des approches suivantes :

  • Modifiez la règle d'alerte et apportez les modifications suivantes :

    1. Dans la console Google Cloud , modifiez la règle d'alerte.

    2. Sur la page Configurer le déclencheur, développez Options avancées, puis définissez le menu Évaluation des données manquantes sur Les points de données manquants sont traités comme des valeurs qui n'enfreignent pas la condition de la règle. Ce choix correspond à l'énumération EVALUATION_MISSING_DATA_INACTIVE.

    3. Sur la page Notifications et nom, définissez le menu Délai pour la fermeture automatique de l'alerte sur 30 minutes.

    Une fois que vous avez mis à jour votre règle d'alerte, Monitoring ferme l'alerte lorsque les observations cessent d'arriver et que la condition évalue les données manquantes, ou lorsque la durée de fermeture automatique expire.

  • Fermez l'alerte manuellement. Pour en savoir plus, consultez Impossible de fermer manuellement une alerte. La fermeture manuelle d'une alerte peut être disponible en fonction de l'état de la ressource.

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

Vous accédez à la page des alertes dans la console Google Cloud , puis vous 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 d'incidents de la console Cloud Monitoring" (roles/monitoring.cloudConsoleIncidentViewer) et "Lecteur de comptes Stackdriver" (roles/stackdriver.accounts.viewer).

Pour afficher tous les détails d'une alerte, 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 de lecteur Monitoring (roles/monitoring.viewer) et d'éditeur d'incidents Monitoring Cloud Console (roles/monitoring.cloudConsoleIncidentEditor).

Les rôles personnalisés ne peuvent pas accorder 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 une fois que la condition de la règle d'alerte est remplie, Monitoring n'ouvre pas l'alerte.

  • 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'alertes qu'elle peut ouvrir simultanément.

  • L'état de la ressource surveillée par la règle d'alerte est désactivé. Monitoring peut déterminer l'état d'une ressource lorsque celle-ci contient l'étiquette metadata.system_labels.state et que la règle d'alerte n'est pas écrite avec le langage de requête Monitoring.

Les détails de l'alerte indiquent un projet incorrect

Vous recevez une notification et le récapitulatif de la condition liste le projetGoogle Cloud dans lequel l'alerte a été créée, c'est-à-dire le projet de champ d'application. Toutefois, vous vous attendez à ce que l'alerte indique le nom du projet Google Cloud qui stocke la série temporelle ayant entraîné 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 l'étiquette qui stocke l'ID du projet, les informations d'alerte répertorient le projet de champ d'application. Par exemple, si vous regroupez les données uniquement 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'alerte incluent le nom du projet Google Cloud qui stocke la série temporelle à l'origine de l'alerte. Pour conserver l'ID du projet, incluez l'étiquette 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. Vous accédez à la page d'informations de l'alerte, puis vous 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'arrive 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 réessayer l'opération de fermeture 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. Cependant, 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 disposez de 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 jointes.

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 une 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 des notifications et crée 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 une étiquette de métrique à la section de documentation. Vous vous attendez à ce que les notifications affichent la valeur de l'étiquette à laquelle 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 l'étiquette 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 répertorie 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 de l'étiquette 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 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.

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 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.

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

Vous avez récemment créé une métrique, puis vous l'avez référencée lorsque vous avez essayé de créer une règle d'alerte dans l'API Cloud Monitoring. Cependant, la commande 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 10 minutes, puis renvoyez la requête API.

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

Vous avez reçu une notification indiquant qu'un incident a été ouvert pour votre règle d'alerte. Toutefois, lorsque vous accédez à la page d'informations de 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 de la barre d'outils ou en mettant en surbrillance des périodes sur le graphique avec votre pointeur.

Les graphiques ont une résolution limitée et peuvent ne pas afficher toutes les mesures pour certaines périodes.