Comportement des règles d'alerte

Les règles d'alerte sont utilisées dans des environnements dynamiques et complexes, il convient donc de bien comprendre certaines des variables pouvant affecter leur comportement. Ces variables incluent les métriques et les ressources surveillées par des conditions, les intervalles de temps des conditions et les canaux de notification.

Ce document fournit des informations supplémentaires pour vous aider à comprendre le comportement des règles d'alerte basées sur des métriques. 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ériode d'alignement et durée

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

La période d'alignement est un intervalle d'analyse à partir d'un moment donné. Par exemple, si la période d'alignement est de cinq minutes, alors à 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.

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). Enfin, supposons que la condition soit évaluée toutes les minutes et que la condition soit remplie lorsque la valeur alignée de la série temporelle est supérieure à deux pendant une durée de 3 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 pris en compte dans la période d'alignement sont en bleu. Les points plus anciens sont en gris. 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, le calcul de la valeur alignée donne 1, ce qui est inférieur au seuil. Lors de l'évaluation suivante, la somme des échantillons sur la période d'alignement vaut 2. Lors de la troisième évaluation, la somme vaut 3, ce qui est supérieur au seuil. L'évaluateur de condition démarre alors le minuteur de l'intervalle de temps.

Intervalle de temps

La durée, ou intervalle de temps, sert à éviter qu'une mesure unique suffise à remplir la condition. Dans Google Cloud Console, utilisez les champs suivants pour configurer la durée :

  • Ancienne interface : le champ For (Pour) du volet Configuration de la règle d'alerte.
  • Interface bêta: le champ Time above threshold (Durée supérieure au seuil) (ou Time below threshold (Durée inférieure au seuil)) de l'étape Configurer le déclencheur.

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

Figure illustrant l'effet de l'intervalle de temps

Comme illustré, même si la valeur alignée dépasse le seuil à l'instant start + 2m, la condition n'est pas remplie tant que la valeur alignée dépasse le seuil pendant trois minutes. Cela se produit à l'instant start + 5m.

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. Cette mesure 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 spécifie un intervalle de temps 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,
ouvrir un incident et envoyer un e-mail à l'é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 minutes consécutives suivante, la latence HTTP est supérieure à deux secondes.
  3. Dans la mesure suivante, la latence tombe en dessous des deux secondes. La condition réinitialise l'intervalle de temps.
  4. Pendant les cinq minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes, ce qui signifie que la condition est remplie et que la règle est déclenchée.

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électionner la période d'alignement et l'intervalle de temps.

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 l'intervalle de temps n'ont aucune incidence sur 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. Si vous choisissez une longue période, de nombreux échantillons sont combinés ensemble. Si vous choisissez une période courte, il se peut qu'elle ne contienne qu'un seul point de données. De son côté, 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. Si l'intervalle de temps est défini sur 0, un dépassement de seuil unique suffit pour remplir 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 vos règles d'alerte comportent plusieurs conditions, vous devez spécifier le moment où les conditions individuelles sont remplies. Lorsqu'une condition est remplie, un événement est créé et un incident est susceptible d'être ouvert. Pour configurer la façon dont plusieurs conditions sont combinées, effectuez l'une des opérations suivantes :

  • Dans Google Cloud Console, utilisez l'une des options suivantes :

    • Ancienne interface : champ Déclencheurs de règle.
    • Interface bêta: Déclencheur multicondition.
  • Dans l'API Cloud Monitoring, utilisez le champ combiner.

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

Valeur des déclencheurs de règles
dans Cloud Console
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 par au moins une ressource, même si la condition est remplie par une ressource différente.
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 above 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. Résultat : 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 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.

    Notez que si vm2 a entraîné le respect de la condition CPU usage is too high, cela entraîne également la création d'un incident. Cela s'explique par le fait que, vm1, qui entraîne le respect de la condition CPU usage is too high et vm2, qui entraîne 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.

Règles d'alerte désactivées

Vous pouvez activer et désactiver une règle pour suspendre temporairement les règles d'alerte, puis les redémarrer. Par exemple, si une règle d'alerte est configurée pour vous avertir lorsqu'un processus est interrompu pendant plus de 5 minutes, vous pouvez la désactiver lorsque vous interrompez vous-même le processus pour effectuer une mise à jour ou toute autre activité de maintenance.

Même si la désactivation d'une règle d'alerte empêche la règle de se déclencher ou de fermer les incidents, Monitoring continue d'évaluer les conditions de la règle et d'enregistrer les résultats. Si vous désactivez une règle d'alerte et que vous souhaitez que les problèmes ouverts passent à l'état fermé, mettez l'incident sous silence. Pour en savoir plus sur ce processus, consultez la section Mise sous silence des incidents.

Supposons que le processus surveillé est interrompu pendant 20 minutes à des fins de maintenance. Si vous redémarrez le processus et réactivez la règle d'alerte immédiatement, le processus est reconnu comme inactif pendant les 5 dernières minutes et un incident est ouvert.

Lorsqu'une règle désactivée est réactivée, Monitoring examine les valeurs de toutes les conditions sur l'intervalle de temps le plus récent, pouvant inclure des données prises avant, pendant et après l'intervalle de pause. Les règles peuvent se déclencher immédiatement après leur réactivation, même avec des intervalles de temps plus longs.

Données de métriques partielles

Si des mesures sont manquantes (par exemple, si aucune requête HTTP n'est formulée pendant quelques minutes), la règle utilise la dernière valeur enregistrée pour évaluer les conditions.

Exemple

  1. Une condition spécifie une latence HTTP supérieure ou égale à deux secondes pendant cinq minutes consécutives.
  2. Pendant trois minutes consécutives, la latence HTTP dure trois secondes.
  3. Pendant deux minutes consécutives, aucune requête HTTP n'est formulée. Dans ce cas, une condition reporte la dernière mesure (trois secondes) pendant ces deux minutes.
  4. Après un total de cinq minutes, la règle se déclenche, même si aucune donnée n'a été enregistrée pendant les deux dernières minutes.

Les données métriques manquantes ou différées peuvent empêcher le déclenchement de règles d'alerte et la fermeture d'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 Cloud 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 ces problèmes à l'aide de l'une des opérations suivantes :

  • Contactez votre fournisseur cloud tiers pour savoir s'il existe un moyen de réduire la latence de collecte des métriques.
  • Utilisez des intervalles de temps plus longs dans vos conditions. Cette méthode a pour inconvénient d'affecter la réactivité des 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.

Incidents 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, si une règle s'applique à 2 000 (ou 20 000) instances Compute Engine et que chaque instance entraîne le respect des conditions d'alerte, seuls 5 000 incidents sont ouverts. Toutes les conditions restantes remplies sont ignorées jusqu'à ce que certains des incidents ouverts pour cette règle soient fermés.

Notifications par incident

Par défaut, une notification est envoyée lorsqu'une série temporelle entraîne le respect d'une condition. Il se peut que vous receviez 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, si vous avez une stratégie avec deux conditions et que chaque condition surveille une série temporelle, vous recevez deux notifications lorsque la règle est déclenchée et vous verrez 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.

Si vous créez une règle d'alerte à l'aide de l'API Cloud Monitoring, vous êtes averti lorsque la condition est remplie et lorsque la condition cesse d'être remplie. Si vous créez la règle à l'aide de Google Cloud Console, le comportement par défaut consiste à envoyer une notification uniquement lorsque la condition est remplie. Si vous souhaitez recevoir une notification lorsque la condition cesse d'être remplie, sélectionnez Notifier lors de la fermeture de l'incident dans la section 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 leur collecte. Cependant, 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 l'intervalle de temps).

  • L'intervalle de temps : la période configurée pour la condition. Veuillez prendre en compte que les conditions ne sont remplies que si une condition est vérifiée pendant tout l'intervalle de temps. Par exemple, si vous spécifiez un intervalle de cinq minutes, la notification est différée d'au moins cinq minutes à compter de la première occurrence de l'événement.

  • 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.

Étape suivante