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.

Cette page fournit des informations supplémentaires pour vous aider à comprendre le comportement des règles d'alerte.

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. Si vous utilisez Google Cloud Console, le champ For du volet Configuration correspond à cet intervalle de temps.

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.

La figure 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.

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.

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 :

  • Si vous utilisez Google Cloud Console, utilisez le champ Policy Triggers (Déclenchements de règle).
  • Si vous utilisez 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 résoudre 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 souhaitez que les problèmes ouverts passent à l'état "Résolu", vous devez résoudre ces incidents manuellement. Pour en savoir plus sur ce processus, consultez la section Incidents clos.

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.

Incidents inhabituels

Les règles d'alerte, en particulier celles avec des conditions d'absence de métrique ou de seuil "inférieur à", peuvent s'afficher dans le volet Incidents de la fenêtre Alertes et sembler s'être déclenchées de façon prématurée ou incorrecte.

Cela se produit lorsqu'il y a un fossé dans les données. Ces fossés ne sont pas toujours faciles à identifier. Le fossé peut être masqué ou corrigé.

Dans les graphiques, par exemple, les fossés présents dans les données sont interpolés. Même s'il manque plusieurs minutes de données, le graphique va relier les points manquants pour la contiguïté visuelle. Un tel fossé dans les données sous-jacentes peut suffire à déclencher une règle d'alerte.

Les points dans les métriques basées sur les journaux peuvent arriver en retard et être remplis, jusqu'à 10 minutes en arrière. Ce procédé permet de corriger 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 du déclenchement d'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.

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 résolus.

Notifications par incident

Une notification est envoyée pour chaque série temporelle qui remplit une condition. Une autre notification est envoyée lorsque cette série temporelle n'entraîne plus le respect de la condition. Lorsque la condition n'est plus remplie, l'incident est résolu.

Si une règle contient plusieurs conditions, elle peut envoyer plusieurs notifications selon sa configuration :

  • Si une règle ne se déclenche que lorsque toutes les conditions sont remplies, elle n'envoie de notification qu'à l'ouverture initiale d'un incident.

  • Si une règle se déclenche lorsqu'une condition est remplie, elle envoie une notification à chaque fois qu'une nouvelle combinaison de conditions est remplie. Exemple :

    1. La condition A est remplie, un incident est ouvert et une notification est envoyée.
    2. Lorsqu'une mesure ultérieure remplit les deux conditions A et B, l'incident reste ouvert et une autre notification est envoyée.

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, cette composante est généralement négligeable. Pour les métriques AWS CloudWatch, cela peut prendre plusieurs minutes. Pour les tests de disponibilité, ce delai peut être estimé à deux minutes en moyenne (à 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.

Étapes suivantes