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

Ce document décrit comment les périodes d'alignement et les fenêtres de nouveau test déterminer quand une condition est remplie, comment les règles d'alerte combinent plusieurs 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 stratégie, le nombre de notifications par incident, et ce qui cause 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 Surveiller vos journaux

Périodes d'alignement et fenêtres de nouveau test

Cloud Monitoring évalue la période d'alignement et la fenêtre de nouveau test pour déterminer si la condition d'une règle d'alerte est remplie.

Période d'alignement

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

L'alignement comprend deux étapes :

• La division de la série temporelle en intervalles de temps réguliers, également appelés binning les données. L'intervalle correspond à la durée de l'alignement.

• Calculer une seule valeur pour les points de la période d'alignement. Vous choisissez le mode de calcul de ce point unique ; vous pouvez additionner toutes les valeurs ou calculer leur moyenne ou utiliser le maximum. Fonction qui combine les points de données s'appelle l'aligneur. Le résultat de cette combinaison est appelée valeur alignée.

  Pour en savoir plus sur l'alignement, consultez 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 inclut les échantillons reçus entre 12h55 et 13h00. À 13h01, la période d'alignement est décalée d'une minute et contient les échantillons reçus entre 12h56 et 13h01.

Monitoring configure une période d'alignement comme suit:

console Google Cloud

Vous configurez la période d'alignement Choisissez une valeur pour les champs suivants sur la page Conditions d'alerte:

• Fenêtre glissante: spécifie la période à évaluer.
• Fenêtrage glissant: spécifie la fonction mathématique à sur la fenêtre des points de données.

Pour en savoir plus sur les fonctions disponibles, consultez Aligner dans la documentation de référence de l'API. Une partie de l'aligneur permettent à la fois d'aligner les données et le convertir d'un genre ou d'un type de métrique à un autre. Pour obtenir consultez l'article Genres, types et conversions.

API

Pour configurer la période d'alignement, Champs aggregations.alignmentPeriod et aggregations.perSeriesAligner dans les MetricThreshold et MetricAbsence structures.

Pour en savoir plus sur les fonctions disponibles, consultez Aligner dans la documentation de référence de l'API. Une partie de l'aligneur permettent à la fois d'aligner les données et le convertir d'un genre ou d'un type de métrique à un autre. Pour obtenir consultez l'article Genres, types et conversions.

Pour illustrer l'effet de la période d'alignement sur une condition dans une alerte Considérons une condition de seuil de métrique Surveiller une métrique avec une période d'échantillonnage d'une minute. Supposons que la période d'alignement est définie sur cinq minutes l'aligneur est défini sur sum. Supposons également que la condition est remplie lorsque la valeur alignée de la série temporelle est supérieure à deux pour à trois minutes minimum, et que la condition est évaluée toutes les minutes. Dans cet exemple, la période d'alignement est de deux minutes, et la fenêtre de nouveau test, décrit dans la section suivante, dure 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 de la période d'alignement sont indiqués par points bleus ; les plus anciens points sont noirs. Chaque ligne affiche la valeur alignée et si cette valeur est supérieure au seuil de deux. Pour 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 dans la période d'alignement est de deux. Lors de la troisième évaluation, la somme est égale à trois. Comme cette valeur est supérieure au seuil, une minuterie est lancée pour la fenêtre de retest.

Tester de nouveau les fenêtres

La condition d'une règle d'alerte comporte une fenêtre de nouveau test, ce qui empêche le d'être satisfaite en raison d'une seule mesure ou prévision. Par exemple, supposons que la fenêtre de nouveau test d'une condition soit définie sur 15 minutes. Vous trouverez ci-dessous la description du comportement de la condition en fonction de son type:

• Les conditions de seuil des métriques sont remplies lorsque, pour une série temporelle unique, chaque mesure alignée dans un intervalle de 15 minutes enfreint le seuil.
• Les conditions d'absence de métrique sont remplies lorsqu'aucune donnée n'arrive pour une série temporelle sur un intervalle de 15 minutes.
• Les conditions de prévision sont remplies lorsque chaque prévision produit pendant une fenêtre de 15 minutes prédit que la série temporelle va dépasser le seuil au cours de la période de prévision.

Pour les règles à une condition, un incident est ouvert et les notifications sont envoyé lorsque la condition est remplie. Ces incidents restent ouverts pendant la condition reste remplie.

console Google Cloud

Vous configurez cette fenêtre à l'aide du champ Nouvelle fenêtre de test dans la Configurer un déclencheur d'alerte.

API

Vous configurez cette fenêtre en définissant le champ appelé duration dans le MetricThreshold et Structures MetricAbsence.

La figure précédente représentait trois évaluations d'un seuil de métrique . Au heure start + 2 minutes, la valeur alignée est supérieure au seuil. Toutefois, la condition n'est pas remplie, car la fenêtre de nouveau test est définie sur trois minutes. La figure suivante illustre les résultats de la des évaluations de la condition:

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

Une condition réinitialise la fenêtre de nouveau test chaque fois qu'une mesure ou une prévision ne remplit pas la condition. Ce comportement est illustré dans l'exemple Exemple:

Exemple: Cette règle d'alerte contient une condition de seuil de métrique qui spécifie une fenêtre de nouveau test de cinq minutes.

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

La séquence suivante illustre l'impact de la fenêtre de 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 est supérieure à deux secondes.
3. Dans la mesure suivante, la latence est inférieure à deux secondes. réinitialise la fenêtre de nouveau test.

4. Pendant les cinq minutes consécutives suivantes, la latence HTTP est supérieure à pendant deux secondes, la condition est donc remplie.

   Comme la règle d'alerte comporte une condition, Monitoring envoie des notifications lorsque la condition est remplie.

Définissez une période de nouveau test suffisamment longue pour limiter au maximum les faux positifs, suffisamment court pour garantir 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 est la d'échantillonnage de ce type de métrique. Par exemple, si le type de métrique est échantillonnée 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 période d'alignement à 5 * 300 secondes ou 1 500 secondes.

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

Utilisez la fenêtre de nouveau test pour spécifier la réactivité de l'alerte. Par exemple : si vous définissez une fenêtre de test de 20 minutes Condition d'absence de métrique il ne doit pas y avoir de données pendant 20 minutes avant que la condition soit remplie. Pour une règle d'alerte plus réactive, définissez une valeur inférieure pour la fenêtre de nouveau test. Pour les conditions de seuil de métrique, afin d'obtenir la règle d'alerte la plus réactive, définissez la fenêtre de nouveau test sur zéro. Une seule valeur alignée entraîne ces types doivent être remplies.

Les conditions des règles d'alerte sont évaluées à une fréquence fixe. Les options que pour la période d'alignement, et la fenêtre de retest n'a aucune incidence la fréquence à laquelle la condition est évaluée.

Règles avec plusieurs conditions

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

Si vous utilisez l'API Cloud Monitoring ou si Si votre règle d'alerte comporte plusieurs conditions, vous devez spécifier quand 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 des options de combinaison à l'étape Déclencheur à plusieurs conditions.

API

Vous configurez des options de combinaison avec le champ combiner de la Structure AlertPolicy.

Ce tableau liste les paramètres de la console Google Cloud, l'équivalent dans l'API Cloud Monitoring, ainsi qu'une description de chaque paramètre:

Console Google Cloud Valeur des déclencheurs de 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 chacune condition est remplie, même si une 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.
Remarque : La règle d'alerte utilise les valeurs de libellé pour identifier la ressource par laquelle une condition est remplie. Pour qu'une règle d'alerte avec ce compilateur crée des incidents ou génère des notifications, les conditions suivantes doivent être remplies : Chaque condition doit surveiller la même ressource. Par exemple, pour toutes les conditions, le type de ressource est défini sur gce_instance. Les libellés de ressources surveillées disponibles après l'agrégation doivent être les mêmes pour toutes les conditions. Par exemple, pour la ressource gce_instance, les libellés sont project_id, instance_id et zone. Si une condition regroupe par zone, toutes les conditions doivent être regroupées par zone. Pour obtenir la liste des ressources surveillées et leurs libellés, consultez la section Types de ressources surveillées.

Dans ce contexte, le terme met signifie que la configuration de la condition renvoie la valeur true. Pour par exemple, si la configuration Any time series is greater than 10 for 5 minutes, alors, lorsque cette instruction est évaluée à 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 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 1 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. En effet, que l'utilisation du processeur est supérieure au seuil d'une minute, la condition CPU usage is too high atteint. 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 par vm1 reste supérieure à 100 ms/s et que l'utilisation du processeur par 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 cause la condition CPU usage is too high à la condition, alors qui entraîne également la création d’un incident. Un incident est créé, car vm1 et vm2, ce qui fait que la condition CPU usage is too high est remplie 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 n'arrivent plus ou que les données sont retardées, Monitoring classe les données comme manquantes. Des données manquantes peuvent empêcher la fermeture des incidents. Retards dans les données provenant de avec des fournisseurs cloud tiers peut atteindre 30 minutes, les retards de 5 à 15 minutes étant le plus courant. Une longue (plus long que la fenêtre de nouveau test), peut entraîner l'ajout de conditions un terme "inconnu" state. Lorsque les données arrivent enfin, Monitoring peut avoir perdu une partie de l'historique récent des maladies. 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 Google Cloud

Vous pouvez configurer la manière dont Monitoring évalue de seuil de métrique lorsque les données cessent d'arriver. Par exemple, lorsqu'un incident est ouvert et qu'une mesure attendue n'arrive pas, voulez-vous que Monitoring quitte l'incident l'ouvrir ou la fermer immédiatement ? De même, lorsque les données n'arrivent plus qu'aucun incident n'est ouvert, voulez-vous qu'un incident soit ouvert ? Enfin, combien de temps un incident doit-il rester ouvert une fois que les données cessent d’arriver ?

Deux champs configurables spécifient la manière dont Monitoring évalue les conditions de seuil des métriques lorsque les données cessent d'arriver:

• Configurer la manière dont Monitoring détermine la valeur de remplacement pour les données manquantes, utilisez le champ Évaluation des données manquantes que vous définissez à l'étape Déclencheur de condition. Ce champ est désactivé lorsque fenêtre de nouveau test est défini sur Pas de nouveau test.

  La fenêtre de nouveau test est le champ appelé "duration" dans l'API Cloud Monitoring.

• Configurer le délai d'attente avant la fermeture de Monitoring d'un incident ouvert une fois que les données cessent d'arriver, utilisez Délai pour la fermeture automatique de l'incident. Vous définissez la durée de fermeture automatique dans le champ Notification. Par défaut, la durée de fermeture automatique est sept jours.

Voici les différentes options disponibles pour le champ de données manquantes:

Console Google Cloud « Évaluation des données manquantes » champ	Résumé	Détails
Données manquantes vides	Les incidents ouverts restent ouverts. Les nouveaux incidents ne sont pas ouverts.	Lorsque les conditions sont remplies, la condition est toujours est satisfaite lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, alors l’incident reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'est disponible arrive, le minuteur de fermeture automatique démarre après un délai d'au moins 15 minutes. Si le délai expire, l'incident est clôturé. Lorsque les conditions ne sont pas remplies, lorsque les données cessent d'arriver.
Points de données manquants traités comme des valeurs qui ne respectent pas la condition du règlement	Les incidents ouverts restent ouverts. De nouveaux incidents peuvent être ouverts.	Lorsque les conditions sont remplies, la condition est toujours est satisfaite lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, alors l’incident reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive pour la fermeture automatique plus 24 heures, l’incident est clos. Lorsque les conditions ne sont pas remplies, le paramètre condition de seuil de métrique pour qu'elle se comporte comme une 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 alors é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 des valeurs n'enfreignant pas la condition du règlement	Les incidents ouverts sont fermés. Les nouveaux incidents ne sont pas ouverts.	Pour les conditions remplies, la condition cesse d'être remplie lorsque : les données cessent d'arriver. Si un incident est ouvert pour cette condition, alors l’incident est clos. Lorsque les conditions ne sont pas remplies, lorsque les données cessent d'arriver.

API

Vous pouvez configurer la manière dont Monitoring évalue de seuil de métrique lorsque les données cessent d'arriver. Par exemple, lorsqu'un incident est ouvert et qu'une mesure attendue n'arrive pas, voulez-vous que Monitoring quitte l'incident l'ouvrir ou la fermer immédiatement ? De même, lorsque les données n'arrivent plus qu'aucun incident n'est ouvert, voulez-vous qu'un incident soit ouvert ? Enfin, combien de temps un incident doit-il rester ouvert une fois que les données cessent d’arriver ?

Deux champs configurables spécifient la manière dont Monitoring évalue les conditions de seuil des métriques lorsque les données cessent d'arriver:

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

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

Voici les différentes options disponibles pour le champ de données manquantes:

API Champ evaluationMissingData	Résumé	Détails
EVALUATION_MISSING_DATA_UNSPECIFIED	Les incidents ouverts restent ouverts. Les nouveaux incidents ne sont pas ouverts.	Lorsque les conditions sont remplies, la condition est toujours est satisfaite lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, alors l’incident reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'est disponible arrive, le minuteur de fermeture automatique démarre après un délai d'au moins 15 minutes. Si le délai expire, l'incident est clôturé. Lorsque les conditions ne sont pas remplies, lorsque les données cessent d'arriver.
EVALUATION_MISSING_DATA_ACTIVE	Les incidents ouverts restent ouverts. De nouveaux incidents peuvent être ouverts.	Lorsque les conditions sont remplies, la condition est toujours est satisfaite lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, alors l’incident reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'est disponible arrive pour la durée de fermeture automatique plus 24 heures, l’incident est clos. Lorsque les conditions ne sont pas remplies, le paramètre condition de seuil de métrique pour qu'elle se comporte comme une metric-absence condition. Si les données n'arrivent pas dans le délai spécifié par le champ "duration", la condition est alors é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.	Pour les conditions remplies, la condition cesse d'être remplie lorsque : les données cessent d'arriver. Si un incident est ouvert pour cette condition, alors l’incident est clos. Lorsque les conditions ne sont pas remplies, lorsque les données cessent d'arriver.

Vous pouvez minimiser les problèmes dus à des données manquantes en effectuant l'une des opérations suivantes:

• Contactez votre fournisseur de services cloud tiers pour trouver des moyens de réduire la latence de collecte des métriques.
• Utilisez des périodes de test plus longues dans vos conditions. Utiliser une période de test plus longue présente l'inconvénient de réduire les règles d'alerte réactifs.

• 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 Surveillance.
  • 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 Présentation de l'agent Monitoring Présentation des métriques définies par l'utilisateur métriques basées sur les journaux.

Quand Monitoring envoie des notifications et crée des incidents

Cloud Monitoring envoie une notification lorsqu'une série temporelle une condition est remplie. La notification est envoyée à tous canaux de notification. Vous ne pouvez pas limiter la notification à un canal spécifique ou à un sous-ensemble canaux de distribution.

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

Vous pouvez recevoir plusieurs notifications uniques liées à une seule règle d'alerte sont vraies:

• Une condition surveille plusieurs séries temporelles.

• Une règle contient plusieurs conditions. Dans ce cas, les notifications que vous "receiver" dépendent de la valeur de l'attribut multicondition déclencheur:

  • Toutes les conditions sont remplies: lorsque toutes les conditions sont remplies, pour chaque série temporelle constituant une condition remplie 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.

  • N'importe quelle condition est remplie: la règle d'alerte envoie une notification lorsqu'une série temporelle remplit la 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 informent également lorsque la condition est remplie et quand elle cesse d'être remplie. Les règles d'alerte créées à l'aide de la console Google Cloud n'envoient pas une 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 d'incident

Dans les situations suivantes, Monitoring ne crée pas d'incident ou envoyer des 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 attente.
• Monitoring a atteint le nombre maximal d'enregistrements ouverts les incidents.

Règles d'alerte désactivées

Monitoring n'envoie pas d'incidents "create" des 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 la les valeurs de toutes les conditions au cours de la période de nouveau test la plus récente. La période de nouveau test la plus récente peut inclure des données collectées avant, pendant et après la a été activée. Les conditions d'une règle désactivée peuvent être remplies immédiatement après la reprise de la stratégie, même avec des fenêtres de nouveau test longues.

Par exemple, supposons que vous ayez une règle d'alerte qui surveille une processus et que vous désactivez cette stratégie. La semaine suivante, le processus tombe en panne, et comme la règle d'alerte est désactivée, vous n'en êtes pas informé. Si vous redémarrez le processus et activez la règle d'alerte immédiatement, La surveillance reconnaît que le processus n'est pas opérationnel de cinq minutes et ouvre un incident.

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

Règles d'alerte en attente

Monitoring n'envoie pas de notifications et ne crée pas d'incident pour une règle d'alerte mise en attente. Nous vous recommandons de répéter l'alarme lorsque vous souhaitez empêcher l'envoi d'une règle d'alerte ne recevoir des notifications que pendant de courts intervalles. Par exemple, avant d'effectuer sur une machine virtuelle (VM), vous pouvez créer une mise en pause et l'ajouter les règles d'alerte qui surveillent l'instance.

Lorsque vous mettez en pause une règle d'alerte, Monitoring se ferme tous les incidents ouverts liés à la règle. Surveillance peut ouvrir de nouveaux incidents après l'expiration de la mise en pause. Pour en savoir plus, consultez Suspendre les notifications et les alertes

Limites des notifications et des incidents ouverts

Une règle d'alerte peut s'appliquer à de nombreuses ressources. Un problème affectant peut entraîner l'ouverture d'incidents pour chaque ressource ressource. Un incident est ouvert pour chaque série temporelle qui génère une condition d’être satisfaite.

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

Prenons l'exemple d'une stratégie qui s'applique et chaque instance remplit les conditions d'alerte. Monitoring limite le nombre d'incidents ouverts à 1 000. Toutes les conditions restantes remplies sont ignorés jusqu'à ce que certains des incidents ouverts pour cette règle soient fermés.

Par conséquent, un seul canal de notification peut recevoir jusqu'à 1 000 notifications à la fois. Si vos alertes comporte plusieurs canaux de notification, cette limite s'applique à chacun canal de notification indépendamment les uns des autres.

Remarque :Si un incident est ouvert pour une règle d'alerte et que la série temporelle ayant déclenché l'incident dépasse de nouveau le seuil de condition, un incident est toujours ouvert, alors qu'aucun autre incident n'est ouvert. Cloud Monitoring ne conserve qu'un seul incident ouvert pour chaque série temporelle d'une règle d'alerte.

Latence

La latence désigne le délai entre le moment où Monitoring échantillonne un et le moment 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 instance surveillée a une latence allant jusqu'à 180 secondes, Monitoring ne crée pas d'incident pendant les 180 secondes qui suivent la condition de la règle d'alerte est évaluée à true. Pour en savoir plus, consultez 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 visibles pendant 60 secondes après la collecte ; Toutefois, le délai dépend en fonction de la métrique. Le calcul des règles d'alerte prend un délai supplémentaire de 60 à 90 secondes. Pour les métriques AWS CloudWatch, le délai de visibilité peut durer plusieurs minutes. Pour les tests de disponibilité, cela peut représenter en moyenne minutes (à partir de la fin de la période de nouveau test).

• Fenêtre de nouveau test: fenêtre configurée pour la condition. Les conditions ne sont remplies que lorsqu'une condition est vraie pendant le nouveau test fenêtre. Par exemple, si un intervalle de cinq minutes est défini un retard d'au moins cinq minutes à compter du moment où se produit pour la première fois.

• Délai de réception de la notification: canaux de notification (e-mail, par exemple) et les SMS, peuvent subir des latences réseau ou autres (sans rapport avec ce qui est livré), approchant parfois quelques 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 en savoir plus sur la création d'une règle d'alerte, consultez les ressources suivantes : documents:

  • Créer des règles d'alerte basées sur les seuils de métriques
  • Créer des règles d'alerte en cas d'absence de métrique
  • Créer des règles d'alerte basées sur les métriques prévues
  • 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.