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, selon le choix de la période de nouvelle analyse, par exemple, consultez la section Comportement des règles d'alerte basées sur les métriques.

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

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'affiche pas la lacune de données, et parfois, la lacune de données est automatiquement corrigée:

    • 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 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'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 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 période de nouvelle analyse sur au moins trois minutes. Si vous définissez la période de nouvelle analyse 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. 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 ne se sont pas 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 ce risque, utilisez une période d'alignement d'au moins cinq minutes.

L'incident n'est pas fermé lorsque les données ne sont plus reçues

Vous suivez les conseils de la section Données de métriques partielles et configurez une règle d'alerte pour fermer les incidents lorsque les données ne sont plus reçues. 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 de surveillance, la surveillance 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 incidents lorsque les données cessent d'arriver. Toutefois, vous pouvez fermer ces incidents manuellement.

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

Accédez à la page des incidents dans Google Cloud Console et 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étrique, assurez-vous de disposer des rôles IAM de lecteur dIdentity and Access Management#39;incidents de la console Cloud Monitoring (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étrique, et pour pouvoir les confirmer ou les fermer, assurez-vous de disposer 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 de l'incident.

Incident non créé lorsque la condition est remplie

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

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

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

  • L'état de la ressource que la règle d'alerte surveille est connu comme étant désactivé. La surveillance 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 de surveillance.

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

Vous recevez une notification et le résumé de la condition indique le projet Google Cloud dans lequel l'incident a été créé, c'est-à-dire le projet de champ d'application. Toutefois, vous vous attendez à ce que l'incident indique le nom du projet Google Cloud qui stocke la série temporelle ayant entraîné la création de l'incident 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'incident indiquent le projet de surveillance. Par exemple, si vous ne regroupez les données que par zone, le libellé qui stocke l'ID de 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'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 de projet, incluez le libellé project_id dans le champ de regroupement ou ne regroupez pas la série temporelle.

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.

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.

La surveillance envoie une notification et crée un incident pour chaque série temporelle qui remplit une condition. Par conséquent, lorsque vous avez des règles d'alerte avec plusieurs conditions, vous pouvez potentiellement recevoir une notification et un incident pour chaque série temporelle qui remplit les 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 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 incidents.

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.

La variable d'une étiquette 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, la 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 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 code suivant au champ de documentation: device: ${metric.label.device}.

    Vous devez également vous assurer 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 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 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 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 de l'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.