Ce document explique comment les périodes d'alignement et les périodes de nouvelle analyse déterminent quand une condition est remplie, comment les règles d'alerte combinent plusieurs conditions et comment elles remplacent les points de données manquants. Il décrit également le nombre maximal d'incidents ouverts pour une règle, le nombre de notifications par incident et les causes des retards de notification.
Ce contenu ne concerne pas les règles d'alerte basées sur les journaux. Pour en savoir plus sur les règles d'alerte basées sur les journaux, consultez la page Surveiller vos journaux.
Périodes d'alignement et périodes de nouvelle analyse
Cloud Monitoring évalue la période d'alignement et la période de nouvelle analyse pour déterminer si la condition d'une règle d'alerte est remplie.
Période d'alignement
Avant d'être surveillées par une règle d'alerte, les données de séries temporelles doivent être régularisées afin que la règle d'alerte dispose de données régulièrement espacées à évaluer. Le processus de régularisation est appelé alignement.
L'alignement comprend deux étapes :
Diviser la série temporelle en intervalles de temps réguliers, également appelés "binning" des données. L'intervalle correspond à la 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. La fonction qui combine les points de données est appelée 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, si 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
Pour configurer 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.
- Fonction de fenêtre glissante : spécifie la fonction mathématique à effectuer sur la fenêtre de points de données.
Pour en savoir plus sur les fonctions disponibles, consultez la section Aligner dans la documentation de référence de l'API. Certaines des fonctions d'alignement se chargent à la fois d'aligner les données et de les 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 la section 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 soit définie sur cinq minutes et que l'aligneur soit défini sur sum. Supposons également que la condition soit remplie lorsque la valeur alignée de la série temporelle est supérieure à deux pendant au moins trois minutes et que la condition soit évaluée toutes les minutes.
Dans cet exemple, la période d'alignement est de deux minutes, et la période de nouvelle analyse, décrite dans la section suivante, est de trois minutes.
La figure suivante illustre plusieurs évaluations séquentielles de la condition :
Chacune des trois lignes représente une évaluation singulière de la condition. Les données de séries temporelles sont affichées à gauche. Les points de la période d'alignement sont indiqués par
points bleus ; les points plus anciens
sont noirs. Chaque ligne affiche la valeur alignée et indique 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 de trois. Étant donné que cette valeur est supérieure au seuil, un minuteur est lancé pour la période de nouvelle analyse.
Fenêtres de nouveau test
La condition d'une règle d'alerte comporte 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. La section suivante décrit le 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 dans un intervalle de 15 minutes.
- Les conditions de prévision sont remplies lorsque chaque prévision produite au cours d'une période de 15 minutes indique que la série temporelle dépassera le seuil au cours de cette période.
Pour les règles comportant une seule condition, un incident est ouvert et des notifications sont envoyées lorsque la condition est remplie. Ces incidents restent ouverts tant que la condition est remplie.
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 montre trois évaluations d'une condition de 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 à l'instant 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 un intervalle de réessai de cinq minutes.
Si la latence de réponse HTTP est supérieure à deux secondes,
et si cette latence dépasse ce seuil pendant cinq minutes,
ouvrez un incident et envoyez un e-mail à votre équipe d'assistance.La séquence suivante illustre l'impact de la fenêtre de nouveau test sur l'évaluation de la condition:
- La latence HTTP est inférieure à deux secondes.
- Pendant les trois minutes consécutives suivantes, la latence HTTP est supérieure est supérieure à deux secondes.
- Dans la mesure suivante, la latence est inférieure à deux secondes. réinitialise la fenêtre de nouveau test.
Pendant les cinq minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes, pour que la condition soit remplie.
Étant donné que la règle d'alerte comporte une seule condition, Monitoring envoie des notifications lorsque cette 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 correspond à la période 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 la période d'alignement sur 5 * 300 s, soit 1 500 s.
La valeur maximale de la période d'alignement est de 24 heures moins le délai d'ingestion du type de métrique. Par exemple, si le délai d'ingestion d'une métrique est de 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 la période de nouvelle analyse sur une valeur plus faible. Pour les conditions basées sur un seuil de métrique, définissez la période de nouvelle analyse sur zéro afin d'obtenir la règle d'alerte la plus réactive. Une seule valeur alignée permet de remplir ces types de conditions.
Les conditions des règles d'alerte sont évaluées à une fréquence fixe. Les 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 votre règle d'alerte comporte plusieurs conditions, vous devez spécifier le moment où un incident est ouvert. Pour configurer la façon dont plusieurs conditions sont combinées, effectuez l'une des opérations suivantes :
console Google Cloud
Vous configurez des options de combinaison à l'étape Déclencheur à plusieurs conditions.
API
Vous configurez les 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:
| Valeur des déclencheurs de règles dans la console Google Cloud |
Valeur combinée dans l'API Cloud Monitoring |
Signification |
|---|---|---|
| Une condition est remplie | OR |
Un incident est ouvert si une ressource entraîne le respect des conditions. |
| Toutes les conditions sont remplies , même pour des ressources différentes pour chaque condition (par défaut) |
AND |
Un incident est ouvert si chaque condition est remplie, même si une ressource différente entraîne le respect de ces conditions. |
| All conditions are met (Toutes les conditions sont remplies) | AND_WITH_MATCHING_RESOURCE |
Un incident est ouvert si chaque condition est remplie par la même ressource. Ce paramètre est le plus contraignant. |
Dans ce contexte, le terme met (condition remplie) signifie que la configuration de la condition prend la valeur true. 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 highsurveille 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 utilizationsurveille 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. Étant donné que l'utilisation du processeur est supérieure au seuil pendant une minute, la condition CPU usage is too high est remplie. Si les conditions sont combinées avec Any condition is met (N'importe quelle condition est remplie), un incident est créé, car une condition est remplie. Si les conditions sont combinées avec All conditions are met (Toutes les conditions sont remplies) ou All conditions are met even for different resources for each condition (Toutes les conditions sont remplies même pour différentes ressources pour chaque condition), un incident n'est pas créé. Ces choix de combinaison nécessitent que les deux conditions soient remplies.
Supposons ensuite que l'utilisation du processeur 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 entraîne le respect de la condition
CPU usage is too high, cela entraîne également la création d'un incident. Un incident est créé, car vm1 et vm2, ce qui fait que la conditionCPU usage is too highest 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 deExcessive utilization.
Données de métriques partielles
Lorsque les données de série temporelle ne sont plus reçues ou qu'elles sont retardées, la surveillance les classe comme manquantes. 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. Un long délai (plus long que l'intervalle de temps) peut provoquer un état "inconnu" pour les conditions. Lorsque les données arrivent enfin, il est possible que Monitoring ait perdu une partie de l'historique récent des conditions. Une inspection ultérieure des données de la série temporelle pourrait ne pas révéler ce problème, car il n'y a plus aucune preuve des délais après l'arrivée des données.
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 ne sont plus reçues et qu'aucun incident n'est ouvert, souhaitez-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 comment Monitoring évalue les conditions de seuil de métrique lorsque les données cessent d'arriver :
Pour configurer la manière dont Monitoring détermine la valeur de remplacement des 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 période de nouvelle analyse correspond au champ "duration" (durée) dans l'API Cloud Monitoring.
Pour configurer la durée d'attente de Monitoring avant de fermer un incident ouvert lorsque les données cessent d'arriver, utilisez le champ Durée de fermeture automatique des incidents. 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 Champ "Évaluation des données manquantes" |
Résumé | Détails |
|---|---|---|
| Données manquantes vides | Les incidents ouverts restent ouverts. Aucun nouvel incident n'est ouvert. |
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, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive, le minuteur de fermeture automatique se déclenche 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. Vous pouvez ouvrir de nouveaux incidents. |
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, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive pendant la durée de fermeture automatique plus 24 heures, l'incident est fermé. Pour les conditions non remplies, ce paramètre fait en sorte que la condition de seuil de métrique se comporte comme un |
| 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. Pour les conditions qui ne sont pas remplies, la condition ne continue pas d'être remplie 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 ne sont plus reçues et qu'aucun incident n'est ouvert, souhaitez-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:
Pour configurer la manière dont Monitoring détermine la valeur de remplacement pour les données manquantes, utilisez le champ
evaluationMissingDatade la structureMetricThreshold. Ce champ est ignoré lorsque le champdurationest nul.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
autoClosedans la structureAlertStrategy.
Voici les différentes options disponibles pour le champ de données manquantes:
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. |
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, le minuteur de fermeture automatique se déclenche 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. |
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, alors l’incident reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive pendant la durée de fermeture automatique plus 24 heures, l'incident est fermé. Lorsque les conditions ne sont pas remplies, le paramètre
condition de seuil de métrique pour qu'elle se comporte comme une |
EVALUATION_MISSING_DATA_INACTIVE |
Les incidents ouverts sont fermés. Aucun nouvel incident n'est ouvert. |
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. Pour les conditions qui ne sont pas remplies, la condition ne continue pas d'être remplie lorsque les données cessent d'arriver. |
Vous pouvez minimiser les problèmes liés aux données manquantes en procédant comme suit :
- Contactez votre fournisseur cloud tiers pour identifier des moyens de réduire la latence de collecte des métriques.
- Utilisez des périodes de test plus longues dans vos conditions. Utiliser une période de test plus longue a 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.
- Les métriques basées sur les journaux, si la collecte des entrées de journal n'est pas retardée.
Pour en savoir plus, consultez les pages Présentation de l'agent de surveillance, Présentation des métriques définies par l'utilisateur et Métriques basées sur les journaux.
Quand Monitoring envoie des notifications et crée des incidents
Cloud Monitoring envoie une notification lorsqu'une série temporelle entraîne le respect d'une condition. La notification est envoyée à tous 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 vers des canaux de notification spécifiques pour votre règle d'alerte.
Vous recevrez peut-être plusieurs notifications uniques concernant 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 recevez dépendent de la valeur du déclencheur à plusieurs conditions de la règle d'alerte :
Toutes les conditions sont remplies : lorsque toutes les conditions sont remplies, pour chaque série temporelle qui génère le respect d'une condition, la règle d'alerte envoie une notification et crée un incident.
Vous ne pouvez pas configurer Cloud Monitoring pour créer un seul incident et envoyer une seule notification lorsque la règle d'alerte contient plusieurs conditions.
Any condition is met (N'importe quelle condition est remplie) : la règle d'alerte envoie une notification lorsqu'une série temporelle remplit une condition.
Pour plus d'informations, consultez la section Règles comportant plusieurs conditions.
Les règles d'alerte créées à l'aide de l'API Cloud Monitoring vous avertissent également lorsque la condition est remplie et lorsque la condition cesse d'être remplie. Les règles d'alerte créées à l'aide de la console Google Cloud n'envoient pas de notification lorsque la condition cesse d'être remplie, sauf si vous avez activé ce comportement.
Lorsque Monitoring n'envoie pas de notifications ni ne crée pas d'incidents
Dans les situations suivantes, Monitoring ne crée pas d'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 veille.
- La surveillance a atteint la limite du nombre maximal d'incidents ouverts.
Règles d'alerte désactivées
Monitoring n'envoie pas d'incidents ni de notifications pour les règles d'alerte désactivées. Toutefois, Monitoring continue d'évaluer les conditions d'une règle d'alerte désactivée.
Lorsque vous activez une règle désactivée, Monitoring évalue les valeurs de toutes les conditions sur l'intervalle de nouvelle tentative le plus récent. La période de nouvelle analyse la plus récente peut inclure des données collectées avant, pendant et après l'activation de la règle. Les conditions d'une règle désactivée peuvent être remplies immédiatement après la reprise de la stratégie, même avec des fenêtres de nouveau test longues.
Par exemple, supposons que vous disposiez d'une règle d'alerte qui surveille un processus spécifique et que vous la désactiviez. La semaine suivante, le processus 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'à l'expiration de la durée de fermeture automatique de la règle.
Règles d'alerte différées
Monitoring n'envoie pas de notifications ni ne crée d'incidents pour une règle d'alerte mise en veille. Nous vous recommandons de 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 veille une règle d'alerte, Monitoring ferme tous les incidents ouverts associés à la règle. Monitoring peut ouvrir de nouveaux incidents une fois la mise en veille terminée. Pour en savoir plus, consultez 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 le respect d'une condition.
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. La surveillance 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 votre règle d'alerte comporte plusieurs canaux de notification, cette limite s'applique à chacun d'entre eux indépendamment.
Latence
La latence fait référence au délai entre le moment où Monitoring échantillonne une métrique et celui où le point de données de la métrique devient visible en tant que données de série temporelle. La latence affecte le moment où les notifications sont envoyées. Par exemple, si une métrique surveillée a une latence maximale de 180 secondes, la surveillance ne créera pas d'incident pendant 180 secondes après que la condition de la règle d'alerte aura été évaluée à "true". Pour en savoir plus, consultez la section Latence des données de métriques.
Les événements et paramètres suivants contribuent à la latence:
Délai de collecte des métriques : temps nécessaire à Monitoring pour collecter les valeurs des métriques. Pour les valeurs Google Cloud, la plupart des métriques visibles pendant 60 secondes après la collecte ; Toutefois, ce délai dépend en fonction 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 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 : période configurée pour la condition. Les conditions ne sont remplies que si une condition est vérifiée pendant toute la période de nouvelle analyse. Par exemple, un paramètre de période de nouvelle tentative de cinq minutes entraîne un retard de notification d'au moins cinq minutes à compter de la première occurrence de l'événement.
Délai de réception de la notification: canaux de notification (e-mail, par exemple) et les SMS, peuvent rencontrer 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 savoir comment créer une règle d'alerte, consultez les documents suivants :
Pour consulter un ensemble de règles d'alerte, consultez la section Exemples de règles.