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

Ce document explique comment les paramètres de durée et d'alignement déterminent le moment où une condition se déclenche, comment les règles d'alerte combinent plusieurs conditions et comment les règles d'alerte 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.

Paramètres de durée et de durée de l'alignement

La période d'alignement et l'intervalle de temps sont deux champs que vous définissez lorsque vous spécifiez une condition pour une règle d'alerte. Cette section décrit brièvement la signification de ces champs.

Période d'alignement

Les conditions des règles d'alerte comparent les valeurs alignées aux seuils. La période d'alignement est un intervalle d'analyse à partir d'un moment précis. L'aligneur est la fonction qui combine les points dans l'intervalle d'analyse en une valeur alignée. 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.

console

Vous pouvez configurer les champs d'alignement à l'aide des menus Fenêtre glissante et Fenêtrage glissant qui font partie de la boîte de dialogue Nouvelle condition.

API

Pour configurer les champs d'alignement, définissez les champs aggregations.alignmentPeriod et aggregations.perSeriesAligner dans les structures MetricThreshold et MetricAbsence.

Pour illustrer l'effet de la période d'alignement sur une condition de règle d'alerte, prenons l’exemple d’une condition 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 (somme). Lorsque la valeur alignée de la série temporelle est supérieure à deux pendant au moins trois minutes, la condition est décrite comme étant met ou active. Pour cet exemple, supposons que la condition est évaluée toutes les minutes.

La figure suivante illustre plusieurs évaluations séquentielles de la condition :

Figure illustrant l'effet de la période d'alignement

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 de la période d'alignement sont représentés par des points bleus. Tous les points plus anciens sont noirs. Chaque ligne affiche la valeur alignée et si cette valeur est supérieure au seuil de deux. Pour la ligne étiquetée start, la valeur alignée est égale à un, inférieure au seuil. Lors de la prochaine évaluation, la somme des échantillons dans la période d'alignement est de deux. Lors de la troisième évaluation, la somme est de trois et est supérieure au seuil. L'évaluateur de condition démarre alors le minuteur de l'intervalle de temps.

Intervalle de temps

Vous utilisez la durée, ou intervalle de temps, pour éviter qu'une condition ne soit remplie en raison d'une seule mesure. Par exemple, lorsque la durée d'une condition de seuil de métrique est de cinq minutes, la condition n'est remplie que lorsque chaque mesure alignée dans un intervalle de cinq minutes ne respecte pas le seuil. Si une règle comporte une condition, un incident est ouvert et des notifications sont envoyées lorsque la condition est remplie.

console

Vous pouvez configurer la fenêtre de durée à l'aide du champ Période de test à l'étape Configurer le déclencheur.

API

Pour configurer l'intervalle de temps, définissez le champ duration dans les structures MetricThreshold et MetricAbsence.

La figure précédente montre trois évaluations de la condition. Au start + 2 minutes, la valeur alignée est supérieure au seuil. Toutefois, la condition n'est pas remplie, car l'intervalle de temps est défini sur trois minutes. La figure suivante illustre les résultats des évaluations suivantes de la condition:

Figure illustrant l'effet de l'intervalle de temps

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

Pour plus de clarté, l'exemple précédent a omis la possibilité de combiner les points de données alignés de plusieurs séries temporelles en une seule mesure. C'est cette mesure qui est comparée au seuil pour déterminer si la condition est remplie.

Une condition réinitialise son intervalle de temps chaque fois qu'une mesure enfreint la condition. Ce comportement est illustré dans l'exemple suivant :

Exemple : Cette règle d'alerte contient une condition spécifiant un intervalle de temps de cinq minutes.

Si la latence de réponse HTTP est supérieure à deux secondes,
et que la latence est supérieure à 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 sur l'évaluation de la condition :

  1. La latence HTTP est inférieure à deux secondes.
  2. Pendant les trois prochaines minutes, la latence HTTP est supérieure à deux secondes.
  3. Dans la mesure suivante, la latence est inférieure à deux secondes. La condition réinitialise donc l'intervalle de temps.
  4. Pendant les cinq prochaines minutes consécutives, la latence HTTP est supérieure à deux secondes. La condition est donc remplie.

    Étant donné que la règle comporte une condition, un incident est ouvert et les notifications sont envoyées lorsque la 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.

Sélectionnez la période d'alignement et la durée

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

La figure précédente montre que la période d'alignement détermine le nombre d'échantillons de données combinés ensemble dans l'aligneur. Pour combiner de nombreux échantillons, choisissez une période longue. Pour limiter l'intervalle à un seul échantillon, choisissez une courte période. En revanche, l'intervalle de temps spécifie la durée pendant laquelle les valeurs alignées doivent être supérieures au seuil avant que la condition ne soit remplie. Pour que la condition soit remplie lorsqu'une seule valeur alignée est supérieure au seuil, définissez l'intervalle de temps sur zéro.

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 à quel moment un incident est ouvert. Pour configurer la façon dont plusieurs conditions sont combinées, effectuez l'une des opérations suivantes :

console Google Cloud

Vous configurez les options du compilateur à l'étape Déclencheur multicondition.

API

Vous pouvez configurer les options du modificateur à l'aide du champ combiner de la structure AlertPolicy.

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

console
Valeur de la règle
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 signifie que la configuration de la condition renvoie la valeur true. Par exemple, si la configuration est Any time series is greater than 10 for 5 minutes, la condition est remplie lorsque cette instruction prend la valeur true.

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 d'une instance est supérieure à 100 ms/s pendant 1 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 est supérieure à 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. Comme 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 maintenant 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 1 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, un incident est également créé. Un incident est créé, car vm1 et vm2 entraînant la réponse à 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éries temporelles cessent d'arriver ou que les données sont retardées, Monitoring les classe comme manquantes. Les données manquantes peuvent empêcher les alertes de se déclencher et les incidents ne se ferment pas. Les retards de données provenant de fournisseurs cloud tiers peuvent atteindre 30 minutes, tandis que les retards de 5 à 15 minutes sont les plus courants. 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, Monitoring a peut-être 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.

console

Vous pouvez configurer la manière dont Monitoring évalue une condition de seuil de métrique à l'arrêt de l'arrivée des données. Par exemple, lorsqu'un incident est ouvert et qu'une mesure attendue n'arrive pas, souhaitez-vous que Monitoring l'ouvre ou le ferme immédiatement ? De même, lorsque l'arrivée de données cesse et qu'aucun incident n'est ouvert, souhaitez-vous qu'un incident soit ouvert ? Enfin, combien de temps un incident doit-il rester ouvert après l'arrêt des données ?

Deux champs configurables spécifient comment Monitoring évalue les conditions des seuils de métriques à l'arrivée des données:

  • Pour configurer la manière dont Monitoring détermine la valeur de remplacement pour les données manquantes, utilisez le champ Évaluer les données manquantes que vous avez défini à l'étape Déclencheur de condition. Ce champ est désactivé lorsque la période de test est définie sur Aucun nouveau test.

  • Pour configurer le délai d'attente de Monitoring avant la fermeture d'un incident ouvert après l'arrêt des données, utilisez le champ Durée de la fermeture automatique de l'incident. Vous définissez la durée de fermeture automatique à l'étape Notification. Par défaut, la durée de la fermeture automatique est de sept jours.

Vous trouverez ci-dessous les différentes options disponibles pour le champ de données manquant:

console
Champ "Données d'évaluation manquantes"
Résumé Détails
Données manquantes Les incidents ouverts restent ouverts.
Les nouveaux incidents ne sont pas ouverts.

Pour les conditions remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive, le minuteur de fermeture automatique démarre après un délai d'au moins 15 minutes. Si le minuteur expire, l'incident est clos.

Lorsque les données ne sont plus reçues, les conditions ne sont toujours pas remplies.

Points de données manquants traités comme des valeurs qui ne respectent pas la condition de la règle Les incidents ouverts restent ouverts.
Vous pouvez ouvrir de nouveaux incidents.

Pour les conditions remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive pendant la durée de la fermeture automatique plus 24 heures, l'incident est clos.

Pour les conditions qui ne sont pas remplies, ce paramètre entraîne le comportement de la condition de seuil de métrique en tant que metric-absence condition. Si les données n'arrivent pas dans le délai spécifié par la fenêtre de nouveau test, la condition est évaluée comme remplie. Pour une règle d'alerte avec une condition, la condition remplie entraîne l'ouverture d'un incident.

Points de données manquants traités comme valeurs qui n'enfreignent pas le règlement Les incidents ouverts sont fermés.
Les nouveaux incidents ne sont pas ouverts.

Lorsque les conditions ne sont plus remplies, elles cessent d'être remplies. Si un incident est ouvert pour cette condition, il est fermé.

Lorsque les données ne sont plus reçues, les conditions ne sont toujours pas remplies.

API

Vous pouvez configurer la manière dont Monitoring évalue une condition de seuil de métrique à l'arrêt de l'arrivée des données. Par exemple, lorsqu'un incident est ouvert et qu'une mesure attendue n'arrive pas, souhaitez-vous que Monitoring l'ouvre ou le ferme immédiatement ? De même, lorsque l'arrivée de données cesse et qu'aucun incident n'est ouvert, souhaitez-vous qu'un incident soit ouvert ? Enfin, combien de temps un incident doit-il rester ouvert après l'arrêt des données ?

Deux champs configurables spécifient comment Monitoring évalue les conditions des seuils de métriques à l'arrivée des données:

  • Pour configurer la manière dont Monitoring détermine la valeur de remplacement des données manquantes, utilisez le champ evaluationMissingData de la structure MetricThreshold. Ce champ est ignoré lorsque la valeur du champ duration est égale à zéro.

  • Pour configurer le délai d'attente de Monitoring avant la fermeture d'un incident ouvert après l'arrêt des données, utilisez le champ autoClose dans la structure AlertStrategy.

Vous trouverez ci-dessous les différentes options disponibles pour le champ de données manquant:

Champ
evaluationMissingData de l'API
Résumé Détails
EVALUATION_MISSING_DATA_UNSPECIFIED Les incidents ouverts restent ouverts.
Les nouveaux incidents ne sont pas ouverts.

Pour les conditions remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive, le minuteur de fermeture automatique démarre après un délai d'au moins 15 minutes. Si le minuteur expire, l'incident est clos.

Lorsque les données ne sont plus reçues, les conditions ne sont toujours pas remplies.

EVALUATION_MISSING_DATA_ACTIVE Les incidents ouverts restent ouverts.
Vous pouvez ouvrir de nouveaux incidents.

Pour les conditions remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive pendant la durée de la fermeture automatique plus 24 heures, l'incident est clos.

Pour les conditions qui ne sont pas remplies, ce paramètre entraîne le comportement de la condition de seuil de métrique en tant que metric-absence condition. Si les données n'arrivent pas dans le délai spécifié par le champ "duration", la condition est évaluée comme remplie. Pour une règle d'alerte avec une condition, la condition remplie entraîne l'ouverture d'un incident.

EVALUATION_MISSING_DATA_INACTIVE Les incidents ouverts sont fermés.
Les nouveaux incidents ne sont pas ouverts.

Lorsque les conditions ne sont plus remplies, elles cessent d'être remplies. Si un incident est ouvert pour cette condition, il est fermé.

Lorsque les données ne sont plus reçues, les conditions ne sont toujours pas remplies.

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

  • Contactez votre fournisseur cloud tiers pour trouver des moyens de réduire la latence de collecte des métriques.
  • Utilisez des intervalles de temps plus longs dans vos conditions. L'utilisation d'un intervalle de temps plus long a pour inconvénient de réduire 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 Cloud Monitoring.
    • Les métriques basées sur les journaux, si la collecte des journaux n'est pas retardée.

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

Notifications et incidents par règle

Pour empêcher Monitoring Create de créer des incidents et d'envoyer des notifications pour une règle d'alerte, vous pouvez désactiver la règle. Vous pouvez également créer une mise en pause et inclure la règle dans les critères de mise en pause. Lorsque la répétition est active, la règle ne crée pas d'incidents ni n'envoie de notifications.

Lorsque les règles sont activées et qu'elles ne correspondent pas aux critères d'une mise en pause active, des incidents peuvent être créés et des notifications peuvent être envoyées. Cette section décrit le nombre maximal d'incidents ouverts par règle et le nombre de notifications pouvant s'afficher pour le même incident.

Nombre d'incidents ouverts par règle

Une règle d'alerte peut s'appliquer à de nombreuses ressources, et un problème affectant toutes les ressources peut déclencher la règle et ouvrir des 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é à 5 000.

Par exemple, considérons une règle qui s'applique à 2 000 (ou 20 000) instances Compute Engine, et chaque instance entraîne le respect des conditions d'alerte. Monitoring limite le nombre d'incidents ouverts à 5 000. Toutes les conditions restantes remplies sont ignorées jusqu'à la fermeture de certains incidents ouverts pour cette règle.

Nombre de notifications par incident

Par défaut, une notification est envoyée lorsqu'une série temporelle entraîne le respect d'une condition. Vous pouvez recevoir plusieurs notifications dans les cas suivants:

  • Une condition surveille plusieurs séries temporelles.

  • Une stratégie contient plusieurs conditions:

    • 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 envoie une notification et crée un incident. Par exemple, supposons que vous disposiez d'une stratégie comportant deux conditions et que chaque condition surveille une série temporelle. Lorsque cette règle est déclenchée, vous recevez deux notifications et deux incidents.

    • Une condition est remplie: la stratégie envoie une notification à chaque fois qu'une nouvelle combinaison de conditions est remplie. Supposons par exemple que la condition A soit remplie, qu'un incident s'ouvre et qu'une notification soit envoyée. Si l'incident est toujours ouvert lorsqu'une mesure ultérieure remplit à la fois la condition A et la condition B, une autre notification est envoyée.

Les règles d'alerte créées à l'aide de l'API Cloud Monitoring vous avertissent lorsque la condition est remplie et lorsqu'elle cesse d'être remplie. Par défaut, les règles d'alerte créées à l'aide de Google Cloud Console vous avertissent lorsqu'un incident est ouvert. Ils ne vous avertissent pas lorsqu'un incident est fermé. Vous pouvez activer les notifications sur la fermeture des incidents.

Notifications en cas de désactivation des règles d'alerte

Lorsque vous désactivez une règle d'alerte, elle continue à évaluer ses conditions. Toutefois, les incidents ne sont pas créés et les notifications ne sont pas envoyées.

Lorsque vous activez une règle désactivée, Monitoring examine les valeurs de toutes les conditions au cours de la période la plus récente. La durée la plus récente peut inclure les données collectées avant, pendant et après l'activation de la règle. Les règles peuvent se déclencher immédiatement après leur réactivation, même avec des fenêtres de longue durée.

Par exemple, supposons que vous ayez une règle d'alerte qui surveille un processus spécifique et que vous désactivez cette règle. La semaine suivante, le processus s'interrompt et, comme la stratégie est désactivée, vous n'êtes pas averti. Si vous redémarrez le processus et activez la règle d'alerte immédiatement, Monitoring détecte que le processus n'a pas été activé depuis cinq minutes et ouvre un incident.

Pour fermer les problèmes en cours après avoir désactivé une règle d'alerte, mettez en sourdine les incidents correspondants. Pour en savoir plus sur ce processus, consultez la page Couper le son des incidents.

Notifications de règles correspondant aux critères d'une mise en pause active

Si vous souhaitez empêcher une règle d'alerte d'envoyer des notifications pendant de courts intervalles, nous vous recommandons de créer une mise en pause plutôt que de la désactiver. Par exemple, avant d'effectuer une maintenance sur une machine virtuelle (VM), vous pouvez créer une mise en pause et ajouter aux critères de mise en pause les règles d'alerte qui surveillent l'instance.

Lorsqu'une condition d'une règle d'alerte se déclenche et que cette règle correspond aux critères d'une mise en pause active, aucun incident n'est créé et aucune notification n'est envoyée. Lorsque la mise en pause arrive à expiration, la règle peut créer des incidents et envoyer des notifications.

Latence de notification

La latence de notification correspond au délai qui s'écoule entre le moment où un problème survient et le moment où une règle est déclenchée.

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

  • Le délai de collecte des métriques : temps nécessaire à Cloud 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 nécessitent un délai supplémentaire de 60 à 90 secondes. Pour les métriques AWS CloudWatch, le délai de visibilité peut être de plusieurs minutes. Pour les tests de disponibilité, cela peut prendre en moyenne deux minutes (depuis la fin de l'intervalle de temps).

  • L'intervalle de temps : la période configurée pour la condition. Les conditions ne sont remplies que lorsqu'une condition est vraie pendant toute la durée de l'intervalle. Par exemple, un intervalle de temps de cinq minutes entraîne un retard dans la notification d'au moins cinq minutes à partir du moment où l'événement se produit pour la première fois.

  • Le délai de notification : les canaux de notification, tels que les e-mails et les SMS peuvent eux-mêmes 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.

Étapes suivantes