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 le choix de la fenêtre de nouveau test, par exemple, consultez 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 Ajoutez 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 ne montre pas le manque de données, et parfois le manque de données est automatiquement corrigé:

    • Dans les graphiques, par exemple, il est possible que les écarts ne s'affichent pas, car les valeurs les 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 des métriques basées sur les journaux peuvent arriver en retard et être remplis. datant de moins de 10 minutes. 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 ne peut plus être vue une règle d'alerte pour créer un incident.

  • 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, s'assurer que plusieurs mesures sont requises l'incident est créé en définissant la fenêtre de nouveau test d'une condition soit plus du double du taux d'échantillonnage de la métrique.

    Par exemple, si une métrique est échantillonnée 60 secondes, puis définissez la fenêtre de nouveau test sur au moins 3 minutes. Si vous définissez la fenêtre de nouveau test à la valeur la plus récente, ou à une valeur équivalente à 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 cette une règle d'alerte peut évaluer si une condition est remplie bien que les données de série temporelle n'aient pas été propagées dans le graphique de série temporelle. Par conséquent, il se peut que vous receviez une notification même si le graphique indiquent que la condition est remplie. Pour réduire les risques de cette situation, utilisez une période d'alignement d'au moins cinq minutes.

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

Vous suivez les conseils de Données de métriques partielles et configurer une règle d'alerte pour fermer les incidents lorsque les données cessent d'arriver. Dans certains cas, les données n’arrivent plus, mais un incident ouvert n’est pas automatiquement fermé.

Si la ressource sous-jacente surveillée par une règle d'alerte contient l'étiquette metadata.system_labels.state, et si cette stratégie n'est pas écrite avec Monitoring Query Language, Monitoring peut déterminer l'état de la ressource. Si on sait que l'état d'une ressource est désactivé, alors Monitoring ne ferme pas automatiquement les incidents n'arrive plus. 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 "Incidents" de la console Google Cloud et sélectionnez une de l'incident. 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 de l'incident, à l'exception des données de métriques, assurez-vous de disposer les rôles IAM (Identity and Access Management) des Lecteur d'incidents Monitoring (via la console Cloud) (roles/monitoring.cloudConsoleIncidentViewer) et Lecteur de comptes Stackdriver (roles/stackdriver.accounts.viewer).

Pour afficher tous les détails de l'incident, y compris les données de métriques, et pour pouvoir confirmer ou fermer les incidents, vérifier que vous disposez les rôles de lecteur Monitoring (roles/monitoring.viewer) et Éditeur d'incidents Monitoring (via la console Cloud) (roles/monitoring.cloudConsoleIncidentEditor).

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 affiche que les données surveillées ne respectent pas la condition, mais que vous n'avez pas reçu de notification notification et qu’aucun incident n’a été créé.

Si l'un des critères suivants est vrai après la condition de la règle d'alerte est satisfaite, 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 le nombre maximal d'incidents pouvant être ouverts simultanément.

  • État de la ressource surveillée par la règle d'alerte est désactivé. La surveillance déterminer l'état d'une ressource lorsque celle-ci contient le metadata.system_labels.state et quand la règle d'alerte n'est pas écrit dans le langage MQL (Monitoring Query Language).

Le projet indiqué dans les détails de l'incident est incorrect

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

Les options d'agrégation spécifiées dans la condition d'une règle d'alerte déterminez 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 répertorient le projet effectuant une surveillance. Par exemple, si vous ne regroupez les données que par zone, les valeurs qui stocke l'ID du projet est supprimé.

  • 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 stocke la série temporelle à l'origine de l'incident. Pour conserver le libellé de l'ID du projet, incluez le paramètre 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.

Monitoring envoie une notification et crée un incident pour chaque série temporelle qui entraîne la satisfaction d'une condition. Par conséquent, lorsque vous avez des règles d'alerte avec plusieurs conditions, vous pouvez recevoir une notification et un incident pour chaque série temporelle à l'origine de doivent être remplies.

Prenons l'exemple d'une règle d'alerte avec deux conditions : chaque condition surveille trois séries temporelles. La règle envoie une notification uniquement lorsque les deux conditions sont remplies. Lorsque les conditions de votre règle sont remplies, que vous pourriez recevoir entre 2 (une série temporelle est remplie dans chaque condition). et six notifications et incidents (toutes les séries temporelles sont remplies dans chaque condition).

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

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

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

Vous créez une règle d'alerte Ajoutez une variable pour une étiquette de métrique dans la section "Documentation". Les notifications devraient indiquer 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 que vous souhaitez afficher.

    Par exemple, supposons que vous ayez créé une règle d'alerte qui surveille des octets de disque écrits par les instances de VM. Vous voulez que la documentation répertorie l'appareil à l'origine de la notification. Vous devez donc l'ajouter le champ suivant: 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 le la fonction d'agrégation sur none ou en vous assurant que les sélections de regroupement inclure device.

  • Vérifiez la syntaxe et l'applicabilité de la variable. Pour en savoir plus sur la syntaxe, consultez Annoter des notifications avec de la documentation définie par l'utilisateur.

    Par exemple, la variable log.extracted_label.KEY n'est acceptée pour les règles d'alerte basées sur les journaux. Cette variable s'affiche toujours sous la forme null lorsque 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 pouvez changer la définition d'une métrique définie par l'utilisateur, par exemple le filtre que vous avez utilisé dans une métrique basée sur les journaux, et que la règle d'alerte n'est pas reflétant 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 le nom à afficher de la règle.