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, en choisissant une fenêtre de nouveau test, consultez par exemple 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'indique pas le manque de données et il est parfois 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 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 écart dans une métrique basée sur les journaux qui ne peut plus être visible peut avoir entraîné 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 afin qu'elle soit plus que le 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 3 minutes. Si vous définissez la fenêtre de nouveau test sur la valeur la plus récente ou sur 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 ce processus, une règle d'alerte peut évaluer qu'une condition est remplie, même si les données de série temporelle n'ont pas été 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 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

Suivez les instructions 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 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 que cette règle n'est pas écrite dans le langage Monitoring Query Language, Monitoring peut déterminer l'état de la ressource. S'il est établi que l'état d'une ressource est 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 "Incidents" de la console Google Cloud 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étriques, assurez-vous de disposer des rôles IAM (Identity and Access Management) de lecteur d'incidents 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étriques, et pouvoir confirmer ou fermer les incidents, assurez-vous de disposer des rôles IAM Lecteur Monitoring (roles/monitoring.viewer) et Éditeur d'incidents Monitoring (roles/monitoring.cloudConsoleIncidentEditor) dans la console Cloud Monitoring.

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

Si l'un des critères suivants est vrai une fois que la condition de la règle d'alerte est remplie, 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 nombre maximal d'incidents qu'elle peut ouvrir simultanément.

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

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

Vous recevez une notification, et le résumé des conditions indique le projet Google Cloud dans lequel l'incident a été créé, c'est-à-dire le projet effectuant une surveillance. Cependant, 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éterminent 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 d'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 du projet est supprimé après le regroupement.

  • 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 qui stocke la série temporelle à l'origine de l'incident. Pour conserver le libellé de l'ID du 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 réalisation d'une condition. Par conséquent, lorsque vous disposez de règles d'alerte avec plusieurs conditions, vous pouvez potentiellement recevoir une notification et un incident pour chaque série temporelle entraînant 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 notifications et incidents (une série temporelle est remplie dans chaque condition) et six (toutes les séries temporelles sont remplies dans chaque condition).

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'un libellé de métrique est nulle

Vous allez créer une règle d'alerte et ajouter une variable pour un libellé de métrique dans la section de documentation. Les notifications devraient indiquer la valeur de la variable, mais celle-ci 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. Si vous souhaitez que la documentation répertorie l'appareil à l'origine de la notification, vous devez ajouter le code suivant dans le 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 des 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 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.