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 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 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, 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, 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 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 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 manuellement ces incidents.

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 d'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 clôturer, 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.

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

Vous avez créé une règle d'alerte avec une seule 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 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 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 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écapitulatif des conditions indique le projet Google Cloud dans lequel l'incident a été créé, c'est-à-dire de surveillance. Toutefois, vous vous attendez à ce que l'incident liste 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é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, 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.

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 potentiellement recevoir une notification et un incident pour chaque série temporelle qui remplit les conditions associées.

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, 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 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 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 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 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 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 pour refléter 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.