Ce document décrit comment les périodes d'alignement et les fenêtres de retest déterminent le moment où une condition est remplie, comment les règles d'alerte combinent plusieurs conditions et comment les règles d'alerte remplacent les points de données manquants. Il décrit également le nombre maximal d'incidents ouverts pour une règle, le nombre de notifications par incident et les causes des retards de notification.
Ce contenu ne concerne pas les règles d'alerte basées sur les journaux. Pour en savoir plus sur les règles d'alerte basées sur les journaux, consultez 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ées de sorte que la règle d'alerte espace régulièrement les données à évaluer. Le processus de régularisation est appelé alignment.
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, calculer leur moyenne ou utiliser le maximum. La fonction qui combine les points de données est appelée aligneur. Le résultat de la combinaison est appelé valeur alignée.
Pour en savoir plus sur l'alignement, consultez la section Alignement: régularisation au sein de la série.
Par exemple, lorsque la période d'alignement est de cinq minutes à 13h, elle 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.
- Fenêtrage glissant: spécifie la fonction mathématique à exécuter 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 fonctions d'aligneur alignent les données et les convertissent d'un genre ou d'un type de métrique à un autre. Pour en savoir plus, consultez la section Genres, types et conversions.
API
Pour configurer la période d'alignement, définissez les champs aggregations.alignmentPeriod et aggregations.perSeriesAligner dans les structures MetricThreshold et MetricAbsence.
Pour en savoir plus sur les fonctions disponibles, consultez la section Aligner dans la documentation de référence de l'API. Certaines fonctions d'aligneur alignent les données et les convertissent d'un genre ou d'un type de métrique à un autre. Pour en savoir plus, consultez la section Genres, types et conversions.
Pour illustrer l'effet de la période d'alignement sur une condition d'une règle d'alerte, prenons l'exemple d'une condition de seuil de métrique 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. Supposons également que la condition est remplie lorsque la valeur alignée de la série temporelle est supérieure à deux pendant au moins trois minutes, 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écrite dans la section suivante, 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 des 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 et, comme cette valeur est supérieure au seuil, un minuteur est lancé pour la fenêtre de nouveau test.
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 la condition d'être remplie 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 une description du comportement de la condition en fonction de son type:
- Les conditions de seuil de métrique sont remplies lorsque, pour une seule série temporelle, chaque mesure alignée dans un intervalle de 15 minutes dépasse 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 produite au cours d'une fenêtre de 15 minutes prédit que la série temporelle va dépasser le seuil au cours de cette période.
Pour les règles comportant une condition, un incident est ouvert et des notifications sont envoyées lorsque la condition est remplie. Ces incidents restent ouverts tant que les conditions sont toujours remplies.
Console Google Cloud
Configurez la fenêtre de nouveau test à l'aide du champ Nouvelle fenêtre de test à l'étape Configurer le déclencheur d'alerte.
API
Pour configurer la fenêtre de nouveau test, définissez le champ appelé duration dans les structures MetricThreshold et MetricAbsence.
La figure précédente représentait trois évaluations d'une condition de seuil de métrique. À l'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 des prochaines évaluations de la condition:
Même si la valeur alignée est supérieure au seuil à l'instant start + 2 minutes, la condition n'est pas remplie tant que la valeur alignée n'est pas supérieure au seuil pendant trois minutes. Cet événement se produit à l'instant start + 5 minutes.
Une condition réinitialise sa période de nouveau test chaque fois qu'une mesure ou une prévision ne répond pas à la condition. Ce comportement est illustré dans l'exemple suivant:
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,
et 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:
- La latence HTTP est inférieure à deux secondes.
- Pendant les trois minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes.
- Dans la mesure suivante, la latence est inférieure à deux secondes. La condition réinitialise donc la fenêtre de nouveau test.
Pendant les cinq minutes consécutives suivantes, la latence HTTP est supérieure à 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 un intervalle suffisamment long pour limiter les faux positifs, mais suffisamment court pour que les incidents soient ouverts rapidement.
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 période d'échantillonnage de ce type de métrique. Par exemple, si le type de métrique est échantillonné 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 durée de l'alignement sur 5 x 300 ou 1 500 secondes.
La valeur maximale de la période d'alignement est inférieure de 24 heures au 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 l'intervalle de nouveau test sur 20 minutes pour une condition d'absence de métrique, il ne doit pas y avoir de données pendant 20 minutes avant que la condition ne 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 permet de remplir ces types de conditions.
Les conditions des règles d'alerte sont évaluées à une fréquence fixe. Les choix que vous faites pour la période d'alignement et la fenêtre de nouveau test ne déterminent pas 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 à quel moment un incident doit être 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 répertorie les paramètres de la console Google Cloud, la valeur équivalente 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 chaque condition est remplie, même si une ressource différente entraîne la réalisation de ces conditions. |
| All conditions are met (Toutes les conditions sont remplies) | AND_WITH_MATCHING_RESOURCE |
Un incident est ouvert si chaque condition est remplie par la même ressource. Ce paramètre est le plus contraignant. |
Dans ce contexte, le terme met signifie que la configuration de la condition renvoie la valeur true. Par exemple, si la configuration est Any time series is greater than 10 for 5 minutes, la condition est remplie lorsque cette instruction est évaluée à true.
Exemple
Prenons l'exemple d'un projet Google Cloud contenant deux instances de VM, vm1 et v2. Supposons également que vous créez une règle d'alerte avec deux conditions :
- La condition nommée
CPU usage is too highsurveille 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 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 une minute.
Au départ, supposons que les deux conditions prennent la valeur false.
Ensuite, supposons que l'utilisation du processeur de vm1 dépasse 100 ms/s pendant une minute. Comme l'utilisation du processeur est supérieure au seuil d'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 de la VM1 reste supérieure à 100 ms/s et que l'utilisation du processeur de la 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.Si vm2 cause la condition
CPU usage is too highà la condition, un incident est également créé. Un incident est créé, car vm1 et vm2 à l'origine de la conditionCPU usage is too highsont 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éries temporelles cessent d'arriver ou que les données sont retardées, Monitoring les classe comme manquantes. Des données manquantes peuvent empêcher la fermeture des incidents. Les retards pour les données provenant de fournisseurs cloud tiers peuvent atteindre 30 minutes, les plus courants étant de 5 à 15 minutes. Un long délai (plus long que la fenêtre de retest) peut entraîner le passage des conditions à un état "inconnu". Lorsque les données arrivent enfin, Monitoring peut avoir 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 une condition 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, souhaitez-vous que Monitoring le laisse ouvert ou le ferme immédiatement ? De même, lorsque les données cessent d'arriver et qu'aucun incident n'est ouvert, voulez-vous qu'un incident soit ouvert ? Enfin, combien de temps un incident doit-il rester ouvert après l'arrêt de l'arrivée des données ?
Deux champs configurables permettent de spécifier comment 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 Évaluation des données manquantes que vous avez défini à l'étape Déclencheur de condition. Ce champ est désactivé lorsque la fenêtre de nouveau test est définie sur Aucun nouveau test.
La fenêtre de nouveau test est le champ appelé "duration" dans l'API Cloud Monitoring.
Pour configurer le délai d'attente de Monitoring avant la fermeture d'un incident ouvert après l'arrêt des données, utilisez le champ Délai de fermeture automatique de l'incident. Vous définissez la durée de fermeture automatique à l'étape Notification. La durée par défaut de la fermeture automatique est de 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. Les nouveaux incidents ne sont pas ouverts. |
Lorsque les conditions sont remplies, elles continuent d'être remplies lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive, le minuteur de fermeture automatique démarre après un délai d'au moins 15 minutes. Si le délai expire, l'incident est clôturé. Lorsque les conditions ne sont pas remplies, elles continuent à l'être 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, elles continuent d'être remplies 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 clôturé. Pour les conditions qui ne sont pas remplies, ce paramètre fait en sorte que la condition de seuil de métrique se comporte comme une |
| 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. |
Lorsque les conditions sont remplies, la condition cesse d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il est clôturé. Lorsque les conditions ne sont pas remplies, elles continuent à l'être lorsque les données cessent d'arriver. |
API
Vous pouvez configurer la manière dont Monitoring évalue une condition 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, souhaitez-vous que Monitoring le laisse ouvert ou le ferme immédiatement ? De même, lorsque les données cessent d'arriver et qu'aucun incident n'est ouvert, voulez-vous qu'un incident soit ouvert ? Enfin, combien de temps un incident doit-il rester ouvert après l'arrêt de l'arrivée des données ?
Deux champs configurables permettent de spécifier comment 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 la valeur du champdurationest égale à zéro.Pour configurer le délai d'attente de Monitoring avant la fermeture d'un incident ouvert après l'arrêt des données, utilisez le champ
autoClosedans la structureAlertStrategy.
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, elles continuent d'être remplies lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive, le minuteur de fermeture automatique démarre après un délai d'au moins 15 minutes. Si le délai expire, l'incident est clôturé. Lorsque les conditions ne sont pas remplies, elles continuent à l'être 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, elles continuent d'être remplies 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 clôturé. Pour les conditions qui ne sont pas remplies, ce paramètre fait en sorte que la condition de seuil de métrique se comporte comme une |
EVALUATION_MISSING_DATA_INACTIVE |
Les incidents ouverts sont fermés. Les nouveaux incidents ne sont pas ouverts. |
Lorsque les conditions sont remplies, la condition cesse d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il est clôturé. Lorsque les conditions ne sont pas remplies, elles continuent à l'être 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 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. L'utilisation d'une fenêtre de nouveau test plus longue présente l'inconvénient de rendre vos règles d'alerte moins réactives.
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 Monitoring.
- 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 Monitoring, 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 la satisfaction d'une condition. La notification est envoyée à tous les canaux de notification. Vous ne pouvez pas limiter une notification à un canal spécifique ou à un sous-ensemble des canaux de votre règle.
Si vous configurez des notifications répétées, celles-ci sont renvoyées vers des canaux de notification spécifiques pour votre règle d'alerte.
Vous pouvez recevoir plusieurs notifications uniques liées à une règle d'alerte lorsque l'une des conditions suivantes est remplie:
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, la règle d'alerte envoie une notification et crée un incident pour chaque série temporelle conduisant à ce qu'une condition soit remplie.
Vous ne pouvez pas configurer Cloud Monitoring pour créer un seul incident et n'envoyer qu'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 avertissent également lorsque la condition est remplie ou quand elle 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 d'incident
Dans les situations suivantes, Monitoring ne crée pas d'incident et n'envoie pas de 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'incidents ouverts.
Règles d'alerte désactivées
Monitoring n'envoie pas d'incidents de création ni de notifications pour les règles d'alerte désactivées. Cependant, 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 au cours de la période de nouveau test la plus récente. La fenêtre de nouveau test 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 sa réactivation, même si les périodes de test sont longues.
Par exemple, supposons que vous ayez une règle d'alerte qui surveille un processus spécifique et que vous la désactiviez. La semaine suivante, le processus s'interrompt 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, Monitoring détecte que le processus n'a pas été opérationnel au cours des cinq dernières 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 qui est mise en attente. Nous vous recommandons de mettre en attente les règles d'alerte lorsque vous souhaitez les empêcher d'envoyer des notifications pendant de courts intervalles. Par exemple, avant d'effectuer des opérations de maintenance sur une machine virtuelle (VM), vous pouvez créer une mise en pause et ajouter aux critères de mise en pause les règles d'alerte qui surveillent l'instance.
Lorsque vous mettez en pause une règle d'alerte, Monitoring ferme tous les incidents ouverts liés à cette règle. Monitoring peut ouvrir de nouveaux incidents une fois la mise en pause arrivée à expiration. Pour en savoir plus, consultez la section 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 toutes les ressources peut entraîner l'ouverture d'incidents pour chaque ressource. Un incident est ouvert pour chaque série temporelle qui entraîne la satisfaction 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é à 1 000.
Prenons l'exemple d'une règle qui s'applique à 2 000 instances Compute Engine. Chaque instance remplit les conditions d'alerte. Monitoring limite le nombre d'incidents ouverts à 1 000. Toutes les autres conditions remplies sont ignorées jusqu'à ce que certains des incidents ouverts associés à cette règle soient fermés.
En raison de cette limite, 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'eux indépendamment.
Latence
La latence désigne le délai entre le moment où Monitoring échantillonne une métrique et le moment où le point de données de 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 allant jusqu'à 180 secondes, Monitoring ne crée pas d'incident pendant 180 secondes au maximum après l'évaluation de la condition de la règle d'alerte. 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 ne sont pas visibles pendant 60 secondes après leur collecte. Toutefois, le délai dépend 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 être de plusieurs minutes. Pour les tests de disponibilité, ce délai peut être de deux minutes en moyenne (à partir de la fin de la fenêtre 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 toute la période de nouveau test. Par exemple, si un intervalle de nouveau test est défini sur cinq minutes, la notification est retardée d'au moins cinq minutes à compter de la première occurrence de l'événement.
Délai de notification: les canaux de notification, tels que les e-mails et les SMS, peuvent 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
Pour en savoir plus sur la création d'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.