Comportement des règles d'alerte basées sur les métriques

Ce document explique comment les périodes d'alignement et les périodes de nouvelle analyse déterminent quand une condition est remplie, comment les règles d'alerte combinent plusieurs conditions et comment elles remplacent les points de données manquants. Il décrit également le nombre maximal d'incidents ouverts pour une règle, le nombre de notifications par incident et les causes des retards de notification.

Ce contenu ne concerne pas les règles d'alerte basées sur les journaux. Pour en savoir plus sur les règles d'alerte basées sur les journaux, consultez la page Surveiller vos journaux.

Périodes d'alignement et périodes de nouvelle analyse

Cloud Monitoring évalue la période d'alignement et la période de nouvelle analyse pour déterminer si la condition d'une règle d'alerte est remplie.

Période d'alignement

Avant d'être surveillées par une règle d'alerte, les données de séries temporelles doivent être régularisées afin que la règle d'alerte dispose de données régulièrement espacées à évaluer. Le processus de régularisation est appelé alignement.

L'alignement comprend deux étapes :

• Diviser la série temporelle en intervalles de temps réguliers, également appelés "binning" des données. L'intervalle correspond à la période d'alignement.

• Calculer une seule valeur pour les points de la période d'alignement. Vous choisissez le mode de calcul de ce point unique, en additionnant toutes les valeurs, en calculant la moyenne ou en utilisant la valeur maximale. La fonction qui combine les points de données est appelée aligneur. Le résultat de la combinaison est appelé valeur alignée.

  Pour en savoir plus sur l'alignement, consultez la section Alignement: régularisation au sein de la série.

Par exemple, lorsque la période d'alignement est de cinq minutes, à 13h, la période d'alignement contient les échantillons reçus entre 12h55 et 13h. À 13h01, la période d'alignement est décalée d'une minute et contient les échantillons reçus entre 12h56 et 13h01.

La surveillance configure une période d'alignement comme suit:

Pour illustrer l'effet de la période d'alignement sur une condition de règle d'alerte, prenons l'exemple d'une condition de seuil de métrique qui surveille une métrique avec une période d'échantillonnage d'une minute. Supposons que la période d'alignement soit définie sur cinq minutes et que l'aligneur soit défini sur sum. Supposons également que la condition soit remplie lorsque la valeur alignée de la série temporelle est supérieure à deux pendant au moins trois minutes et que la condition soit évaluée toutes les minutes. Dans cet exemple, la période d'alignement est de deux minutes, et la période de nouvelle analyse, décrite dans la section suivante, est de trois minutes. La figure suivante illustre plusieurs évaluations séquentielles de la condition :

Chacune des trois lignes représente une évaluation singulière de la condition. Les données de séries temporelles sont affichées à gauche. Les points pris en compte dans la période d'alignement sont en bleu. Les points plus anciens sont en noir. Chaque ligne affiche la valeur alignée et indique si cette valeur est supérieure au seuil de deux. Sur la ligne intitulée start, la valeur alignée est égale à un, ce qui est inférieur au seuil. Lors de l'évaluation suivante, la somme des échantillons sur la période d'alignement vaut deux. Lors de la troisième évaluation, la somme est de trois. Étant donné que cette valeur est supérieure au seuil, un minuteur est lancé pour la période de nouvelle analyse.

Fenêtres de nouveau test

La condition d'une règle d'alerte comporte un intervalle de réessai, qui empêche la condition d'être remplie en raison d'une seule mesure ou prévision. Par exemple, supposons que la période de nouvelle analyse d'une condition soit définie sur 15 minutes. La section suivante décrit le comportement de la condition en fonction de son type:

• Les conditions de seuil de métrique sont remplies lorsque, pour une seule série temporelle, chaque mesure alignée sur un intervalle de 15 minutes ne respecte pas le seuil.
• Les conditions d'absence de métrique sont remplies lorsqu'aucune donnée n'arrive pour une série temporelle dans un intervalle de 15 minutes.
• Les conditions de prévision sont remplies lorsque chaque prévision produite au cours d'une période de 15 minutes indique que la série temporelle dépassera le seuil au cours de cette période.

Pour les règles comportant une seule condition, un incident est ouvert et des notifications sont envoyées lorsque la condition est remplie. Ces incidents restent ouverts tant que la condition est remplie.

La figure précédente montre trois évaluations d'une condition de seuil de métrique. À l'instant start + 2 minutes, la valeur alignée est supérieure au seuil. Cependant, la condition n'est pas remplie, car la période de nouvelle analyse est définie sur trois minutes. La figure suivante montre les évaluations suivantes de la condition, et leur conséquence:

Même si la valeur alignée est supérieure au seuil à l'instant start + 2 minutes, la condition n'est pas remplie tant que la valeur alignée est supérieure au seuil pendant trois minutes. Cet événement se produit à l'instant start + 5 minutes.

Une condition réinitialise son intervalle de nouvelle analyse chaque fois qu'une mesure ou une prévision ne remplit pas la condition. Ce comportement est illustré dans l'exemple suivant:

Exemple: Cette règle d'alerte contient une condition de seuil de métrique qui spécifie un intervalle de réessai de cinq minutes.

Si la latence de réponse HTTP est supérieure à deux secondes,
et si cette latence dépasse ce seuil pendant cinq minutes,
ouvrez un incident et envoyez un e-mail à votre équipe d'assistance.

La séquence suivante illustre l'importance de l'intervalle de temps pour le nouveau test sur l'évaluation de la condition:

1. La latence HTTP est inférieure à deux secondes.
2. Pendant les trois minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes.
3. Dans la mesure suivante, la latence est inférieure à deux secondes. La condition réinitialise la période de nouvelle tentative.

4. Pendant les cinq minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes, ce qui signifie que la condition est remplie.

   Étant donné que la règle d'alerte comporte une seule condition, Monitoring envoie des notifications lorsque cette condition est remplie.

Définissez un intervalle de temps suffisamment long pour réduire les faux positifs, mais suffisamment court pour vous assurer que les incidents sont ouverts en temps opportun.

Bonnes pratiques pour définir la période d'alignement et la période de nouveau test

La période d'alignement détermine le nombre d'échantillons combinés avec l'aligneur:

• La valeur minimale de la période d'alignement pour un type de métrique correspond à la période d'échantillonnage de ce type de métrique. Par exemple, si le type de métrique est échantillonné toutes les 300 secondes, la période d'alignement doit être d'au moins 300 secondes. Toutefois, si vous souhaitez combiner cinq échantillons, définissez la période d'alignement sur 5 * 300 s, soit 1 500 s.

• La valeur maximale de la période d'alignement est de 24 heures moins le délai d'ingestion du type de métrique. Par exemple, si le délai d'ingestion d'une métrique est de six heures, la valeur maximale de la période d'alignement est de 18 heures.

Utilisez la période de nouveau test pour spécifier la réactivité de l'alerte. Par exemple, si vous définissez la période de nouvelle analyse sur 20 minutes pour une condition d'absence de métrique, aucune donnée ne doit être disponible pendant 20 minutes avant que la condition ne soit remplie. Pour une règle d'alerte plus réactive, définissez la période de nouvelle analyse sur une valeur plus faible. Pour les conditions basées sur un seuil de métrique, définissez la période de nouvelle analyse sur zéro afin d'obtenir la règle d'alerte la plus réactive. Une seule valeur alignée permet de remplir ces types de conditions.

Les conditions des règles d'alerte sont évaluées à une fréquence fixe. Les choix que vous ferez pour la période d'alignement et la période de nouvelle analyse ne déterminent pas la fréquence d'évaluation de la condition.

Règles avec plusieurs conditions

Une règle d'alerte peut contenir jusqu'à six conditions.

Si vous utilisez l'API Cloud Monitoring ou si votre règle d'alerte comporte plusieurs conditions, vous devez spécifier le moment où un incident est ouvert. Pour configurer la façon dont plusieurs conditions sont combinées, effectuez l'une des opérations suivantes :

Ce tableau répertorie les paramètres dans la console Google Cloud, la valeur équivalente dans l'API Cloud Monitoring et une description de chaque paramètre:

Valeur des déclencheurs de règles dans la console Google Cloud	Valeur combinée dans l'API Cloud Monitoring	Signification
Une condition est remplie	OR	Un incident est ouvert si une ressource entraîne le respect des conditions.
Toutes les conditions sont remplies , même pour des ressources différentes pour chaque condition (par défaut)	AND	Un incident est ouvert si chaque condition est remplie, même si une ressource différente entraîne le respect de ces conditions.
All conditions are met (Toutes les conditions sont remplies)	AND_WITH_MATCHING_RESOURCE	Un incident est ouvert si chaque condition est remplie par la même ressource. Ce paramètre est le plus contraignant.

Dans ce contexte, le terme met (condition remplie) signifie que la configuration de la condition prend la valeur true. Par exemple, si la configuration est Any time series is greater than 10 for 5 minutes, lorsque l'instruction prend la valeur true, la condition est remplie.

Exemple

Prenons l'exemple d'un projet Google Cloud contenant deux instances de VM, vm1 et v2. Supposons également que vous créez une règle d'alerte avec deux conditions :

• La condition nommée CPU usage is too high surveille l'utilisation du processeur liée aux instances. Cette condition est remplie lorsque l'utilisation du processeur par une instance dépasse 100 ms/s pendant une minute.
• La condition nommée Excessive utilization surveille l'utilisation du processeur liée aux instances. Cette condition est remplie lorsque l'utilisation du processeur d'une instance dépasse 60% pendant une minute.

Au départ, supposons que les deux conditions prennent la valeur false.

Ensuite, supposons que l'utilisation du processeur de vm1 dépasse 100 ms/s pendant une minute. Étant donné que l'utilisation du processeur est supérieure au seuil pendant une minute, la condition CPU usage is too high est remplie. Si les conditions sont combinées avec Any condition is met (N'importe quelle condition est remplie), un incident est créé, car une condition est remplie. Si les conditions sont combinées avec All conditions are met (Toutes les conditions sont remplies) ou All conditions are met even for different resources for each condition (Toutes les conditions sont remplies même pour différentes ressources pour chaque condition), un incident n'est pas créé. Ces choix de combinaison nécessitent que les deux conditions soient remplies.

Supposons ensuite que l'utilisation du processeur de vm1 reste supérieure à 100 ms/s et que l'utilisation du processeur de vm2 dépasse 60% pendant une minute. Résultat : les deux conditions sont remplies. Ce qui suit se produit en fonction de la combinaison des conditions :

• Any condition is met (N'importe quelle condition est remplie) : un incident est créé lorsqu'une ressource entraîne le respect d'une condition. Dans cet exemple, vm2 entraîne le respect de la condition Excessive utilization.

  Si vm2 entraîne le respect de la condition CPU usage is too high, cela entraîne également la création d'un incident. Un incident est créé, car vm1 et vm2, qui entraînent le respect de la condition CPU usage is too high, sont des événements distincts.

• All conditions are met even for different resources for each condition (Toutes les conditions sont remplies même pour différentes ressources pour chaque condition) : un incident est créé, car les deux conditions sont remplies.

• Toutes les conditions sont remplies : un incident n'est pas créé, car cette combinaison nécessite que la même ressource entraîne le respect de toutes les conditions. Dans cet exemple, aucun incident n'est créé, car vm1 entraîne le respect de CPU usage is too high, tandis que vm2 entraîne le respect de Excessive utilization.

Données de métriques partielles

Lorsque les données de série temporelle ne sont plus reçues ou qu'elles sont retardées, la surveillance les classe comme manquantes. Les données manquantes peuvent empêcher la clôture des incidents. Les retards de données provenant de fournisseurs cloud tiers peuvent atteindre 30 minutes, les délais les plus courants étant compris entre 5 et 15 minutes. Un long délai (plus long que l'intervalle de temps) peut provoquer un état "inconnu" pour les conditions. Lorsque les données arrivent enfin, il est possible que Monitoring ait perdu une partie de l'historique récent des conditions. Une inspection ultérieure des données de la série temporelle pourrait ne pas révéler ce problème, car il n'y a plus aucune preuve des délais après l'arrivée des données.

Vous pouvez minimiser les problèmes liés aux données manquantes en procédant comme suit:

• Contactez votre fournisseur cloud tiers pour identifier des moyens de réduire la latence de collecte des métriques.
• Utilisez des périodes de nouvelle analyse plus longues dans vos conditions. Utiliser une période de nouvelle analyse plus longue a pour inconvénient d'affecter la réactivité de vos règles d'alerte.

• Choisissez des métriques avec un délai de collecte inférieur :

  • Les métriques d'agent de surveillance, en particulier lorsque l'agent est exécuté sur des instances de VM dans des clouds tiers.
  • Les métriques personnalisées, lorsque vous écrivez leurs données directement dans Monitoring.
  • Les métriques basées sur les journaux, si la collecte des entrées de journal n'est pas retardée.

Pour en savoir plus, consultez les pages Présentation de l'agent de surveillance, Présentation des métriques définies par l'utilisateur et Métriques basées sur les journaux.

Lorsque Monitoring envoie des notifications et crée des incidents

Cloud Monitoring envoie une notification lorsqu'une série temporelle entraîne le respect d'une condition. La notification est envoyée à tous les canaux de notification. Vous ne pouvez pas limiter une notification à un canal spécifique ni à un sous-ensemble des canaux de votre règle.

Si vous configurez des notifications répétées, la même notification est renvoyée vers des canaux de notification spécifiques pour votre règle d'alerte.

Vous pouvez recevoir plusieurs notifications uniques liées à une règle d'alerte dans les cas suivants:

• Une condition surveille plusieurs séries temporelles.

• Une règle contient plusieurs conditions. Dans ce cas, les notifications que vous recevez dépendent de la valeur du déclencheur à plusieurs conditions de la règle d'alerte:

  • Toutes les conditions sont remplies: lorsque toutes les conditions sont remplies, pour chaque série temporelle qui génère le respect d'une condition, la règle d'alerte envoie une notification et crée un incident.

    Vous ne pouvez pas configurer Cloud Monitoring pour créer un seul incident et envoyer une seule notification lorsque la règle d'alerte contient plusieurs conditions.

  • Any condition is met (N'importe quelle condition est remplie) : la règle d'alerte envoie une notification lorsqu'une série temporelle remplit une condition.

  Pour plus d'informations, consultez la section Règles comportant plusieurs conditions.

Les règles d'alerte créées à l'aide de l'API Cloud Monitoring vous avertissent également lorsque la condition est remplie et lorsque la condition cesse d'être remplie. Les règles d'alerte créées à l'aide de la console Google Cloud n'envoient pas de notification lorsque la condition cesse d'être remplie, sauf si vous avez activé ce comportement.

Lorsque Monitoring n'envoie pas de notifications ni ne crée pas d'incidents

Dans les situations suivantes, Monitoring ne crée pas d'incidents ni n'envoie de notifications lorsque les conditions d'une règle d'alerte sont remplies:

• La règle d'alerte est désactivée.
• La règle d'alerte est mise en veille.
• La surveillance a atteint la limite du nombre maximal d'incidents ouverts.

Règles d'alerte désactivées

Monitoring n'envoie pas d'incidents ni de notifications pour les règles d'alerte désactivées. Toutefois, Monitoring continue d'évaluer les conditions d'une règle d'alerte désactivée.

Lorsque vous activez une règle désactivée, Monitoring évalue les valeurs de toutes les conditions sur l'intervalle de réessai le plus récent. La période de nouvelle analyse la plus récente peut inclure des données collectées avant, pendant et après l'activation de la règle. Les conditions d'une règle désactivée peuvent être remplies immédiatement après sa réactivation, même avec des intervalles de réessai plus longs.

Par exemple, supposons que vous disposiez d'une règle d'alerte qui surveille un processus spécifique et que vous la désactiviez. La semaine suivante, le processus s'arrête et, comme la règle d'alerte est désactivée, vous ne recevez aucune notification. Si vous redémarrez le processus et activez immédiatement la règle d'alerte, Monitoring reconnaît que le processus n'a pas été actif au cours des cinq dernières minutes et ouvre un incident.

Les incidents liés à une règle d'alerte désactivée restent ouverts jusqu'à l'expiration de la durée de fermeture automatique de la règle.

Règles d'alerte différées

Monitoring n'envoie pas de notifications ni ne crée d'incidents pour une règle d'alerte mise en veille. Nous vous recommandons de suspendre les règles d'alerte lorsque vous souhaitez empêcher une règle d'alerte d'envoyer des notifications que pendant de courtes périodes. Par exemple, avant d'effectuer la maintenance d'une machine virtuelle (VM), vous pouvez créer un délai avant expiration et ajouter aux critères de délai avant expiration les règles d'alerte qui surveillent l'instance.

Lorsque vous mettez en veille une règle d'alerte, Monitoring ferme tous les incidents ouverts associés à la règle. Monitoring peut ouvrir de nouveaux incidents une fois la mise en veille terminée. Pour en savoir plus, consultez la section Mettre en veille les notifications et les alertes.

Limites des notifications et des incidents ouverts

Une règle d'alerte peut s'appliquer à de nombreuses ressources, et un problème affectant toutes les ressources peut entraîner l'ouverture d'incidents pour chaque ressource. Un incident est ouvert pour chaque série temporelle qui génère le respect d'une condition.

Pour éviter de surcharger le système, le nombre d'incidents qu'une seule règle peut ouvrir simultanément est limité à 1 000.

Prenons l'exemple d'une règle qui s'applique à 2 000 instances Compute Engine et que chaque instance entraîne le respect des conditions d'alerte. La surveillance limite le nombre d'incidents ouverts à 1 000. Toutes les conditions restantes remplies sont ignorées jusqu'à ce que certains des incidents ouverts pour cette règle soient fermés.

En raison de cette limite, un seul canal de notification peut recevoir jusqu'à 1 000 notifications à la fois. Si votre règle d'alerte comporte plusieurs canaux de notification, cette limite s'applique à chacun d'entre eux indépendamment.

Latence

La latence fait référence au délai entre le moment où Monitoring échantillonne une métrique et celui où le point de données de la métrique devient visible en tant que données de série temporelle. La latence affecte le moment où les notifications sont envoyées. Par exemple, si une métrique surveillée a une latence maximale de 180 secondes, la surveillance ne créera pas d'incident pendant 180 secondes après que la condition de la règle d'alerte aura été évaluée à "true". Pour en savoir plus, consultez la section Latence des données de métriques.

Les événements et paramètres suivants contribuent à la latence:

• Délai de collecte des métriques: temps nécessaire à Monitoring pour collecter les valeurs des métriques. Pour les valeurs Google Cloud, la plupart des métriques ne sont pas visibles pendant 60 secondes après la collecte. Toutefois, le délai dépend de la métrique. Les calculs des règles d'alerte prennent un délai supplémentaire de 60 à 90 secondes. Pour les métriques AWS CloudWatch, le délai de visibilité peut prendre plusieurs minutes. Pour les tests de disponibilité, ce délai peut être en moyenne de deux minutes (à partir de la fin de la période de nouveau test).

• Fenêtre de nouveau test: période configurée pour la condition. Les conditions ne sont remplies que si une condition est vérifiée pendant toute la période de nouvelle analyse. Par exemple, un paramètre de période de nouvelle tentative de cinq minutes entraîne un retard de notification d'au moins cinq minutes à compter de la première occurrence de l'événement.

• Délai de notification: les canaux de notification, tels que les e-mails et les SMS, peuvent subir des latences réseau ou d'autres types de latence (sans rapport avec les éléments distribués), pouvant atteindre plusieurs minutes. Sur certains canaux, tels que les SMS et Slack, il n'y a aucune garantie que les messages soient distribués.

Étape suivante

• Pour savoir comment créer une règle d'alerte, consultez les documents suivants:

  • Créer des règles d'alerte basées sur un seuil de métrique
  • Créer des règles d'alerte en cas d'absence de métrique
  • Créer des règles d'alerte pour les valeurs prévues des métriques
  • Créer des règles d'alerte à l'aide de l'API Monitoring

• Pour consulter un ensemble de règles d'alerte, consultez la section Exemples de règles.