Ce document explique comment les périodes d'alignement et les périodes de nouveau test 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'alertes ouvertes pour une règle, le nombre de notifications par alerte 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 retest
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 a été remplie.
Période d'alignement
Avant que les données de série temporelle ne soient surveillées par une règle d'alerte, elles 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 période d'alignement.
Calculer une seule valeur pour les points de la période d'alignement. Vous choisissez le mode de calcul de ce point unique, en additionnant toutes les valeurs, en calculant la moyenne ou en utilisant la valeur maximale. 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 Alignement : régularisation au sein de la série.
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.
La surveillance 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 dynamique : spécifie la plage de temps à évaluer.
- Fonction de fenêtrage glissant : spécifie la fonction mathématique à appliquer à la fenêtre de points de données.
Pour en savoir plus sur les fonctions disponibles, consultez Aligner dans la documentation de référence de l'API. Certaines fonctions d'aligneur 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 une explication détaillée, consultez Genres, types et conversions.
API
Vous configurez la période d'alignement en définissant les champs aggregations.alignmentPeriod et aggregations.perSeriesAligner dans les structures MetricThreshold et MetricAbsence.
Pour en savoir plus sur les fonctions disponibles, consultez Aligner dans la documentation de référence de l'API. Certaines fonctions d'aligneur 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 une explication détaillée, consultez Genres, types et conversions.
Pour illustrer l'effet de la période d'alignement sur une condition dans 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 de nouveau test, 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 pris en compte dans la période d'alignement sont en bleu. Les points plus anciens sont en noir. 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 à 1, ce qui est inférieur au seuil.
Lors de l'évaluation suivante, la somme des échantillons sur la période d'alignement vaut deux.
Lors de la troisième évaluation, la somme est de trois. Comme cette valeur est supérieure au seuil, un minuteur pour la période de nouveau test est lancé.
Périodes de nouveau test
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 retest d'une condition soit définie sur 15 minutes. Le comportement de la condition est décrit ci-dessous 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 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 prédit que la série temporelle dépassera le seuil au cours de la fenêtre de prévision.
Pour les règles comportant une seule condition, une alerte est ouverte et des notifications sont envoyées lorsque la condition est remplie. Ces alertes restent ouvertes tant que la condition est remplie.
Console Google Cloud
Vous configurez la période de nouveau test à l'aide du champ Période de nouveau test à l'étape Configurer le déclencheur d'alerte.
API
Vous configurez la fenêtre de nouveau test en définissant le champ duration dans les structures MetricThreshold et MetricAbsence.
La figure précédente montre 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 période de nouveau test est définie sur trois minutes. La figure suivante montre les évaluations suivantes de la condition, et leur conséquence :
Même si la valeur alignée est supérieure au seuil à l'heure start + 2 minutes, la condition n'est remplie que lorsque la valeur alignée est supérieure au seuil pendant trois minutes. Cet événement se produit à l'instant start + 5 minutes.
Une condition réinitialise son intervalle de retest chaque fois qu'une mesure ou une prévision ne la respecte pas. Par conséquent, définissez une période de nouveau test suffisamment longue pour minimiser les faux positifs, mais suffisamment courte pour vérifier que les alertes sont ouvertes en temps voulu. 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 pendant cinq minutes,
ouvrir une alerte et envoyer un e-mail à l'équipe d'assistance.
La séquence suivante illustre l'impact de la période de retest 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 l'intervalle de temps pour le nouveau test.
Pendant les cinq minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes, ce qui signifie que la condition est remplie.
Étant donné que la règle d'alerte comporte une condition, Monitoring envoie des notifications lorsque cette condition est remplie.
Bonnes pratiques pour définir la période d'alignement et l'intervalle de retest
La période d'alignement détermine le nombre d'échantillons combinés par l'aligneur. L'intervalle d'échantillonnage, le délai d'ingestion et le nombre d'échantillons que vous souhaitez combiner ont une incidence sur la façon dont vous définissez la période d'alignement :
La période d'alignement ne doit pas dépasser 24 heures moins le délai d'ingestion.
Nous vous recommandons de définir une période d'alignement au moins aussi longue que le délai d'ingestion. Toutefois, la période d'alignement doit toujours être au moins aussi longue que l'intervalle d'échantillonnage.
Pour les conditions de seuil de métrique, la valeur maximale typique de la période d'alignement est de 25 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 six heures, la valeur maximale de la période d'alignement est de 19 heures. Vous pouvez utiliser PromQL pour créer des alertes sur les données datant de plus de 25 heures. Pour en savoir plus, consultez Utiliser PromQL pour créer des règles d'alerte.
Par exemple, si le délai d'ingestion pour un type de métrique est de six heures, nous vous recommandons d'utiliser une période d'alignement comprise entre six et 18 heures. Supposons que l'intervalle d'échantillonnage soit de 60 secondes. Si vous définissez la période d'alignement sur 6 heures et 5 minutes, l'aligneur combine en moyenne 5 échantillons.
Si un type de métrique présente un délai d'ingestion très long (18 heures, par exemple), définissez la période d'alignement sur une durée au moins égale à l'intervalle d'échantillonnage, mais au maximum égale à 24 heures moins le délai d'ingestion.
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 retest sur 20 minutes pour une condition d'absence de métrique, aucune donnée ne doit être disponible pendant 20 minutes avant que la condition soit remplie. Pour une règle d'alerte plus réactive, définissez une fenêtre de retest plus courte. Pour les conditions de seuil de métrique, définissez la fenêtre de nouveau test sur zéro afin d'obtenir la règle d'alerte la plus réactive. Une seule valeur alignée suffit à remplir ces types de conditions.
Si vous définissez la période de nouveau test, vous devrez peut-être raccourcir la période d'alignement en raison des limites des règles d'alerte.
Les conditions des règles d'alerte sont évaluées à une fréquence fixe. Les choix que vous ferez pour la période d'alignement et la période de retest ne déterminent pas la fréquence d'évaluation de la condition.
Règles avec plusieurs conditions
Une règle d'alerte peut contenir jusqu'à six conditions.
Si vous utilisez l'API Cloud Monitoring ou si votre règle d'alerte comporte plusieurs conditions, vous devez spécifier à quel moment une alerte est ouverte. Pour configurer la façon dont plusieurs conditions sont combinées, effectuez l'une des opérations suivantes :
Console Google Cloud
Vous configurez les options de combinaison à l'étape Déclencheur multicondition.
API
Vous configurez les options de combinaison avec le champ combiner de la structure AlertPolicy.
Ce tableau répertorie les paramètres dans la console Google Cloud , la valeur équivalente dans l'API Cloud Monitoring et une description de chaque paramètre :
| Valeur des déclencheurs de règlesGoogle Cloud dans la console |
Valeur combinée dans l'API Cloud Monitoring |
Signification |
|---|---|---|
| Une condition est remplie | OR |
Une alerte est ouverte si une ressource remplit l'une des conditions. |
| Toutes les conditions sont remplies , même pour des ressources différentes pour chaque condition (par défaut) |
AND |
Une alerte est ouverte pour chaque condition remplie lorsque toutes les conditions sont remplies, 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 |
Une alerte est ouverte pour chaque condition remplie lorsque toutes les conditions sont remplies, uniquement si la même ressource entraîne le respect de chaque condition. 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 greater than 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 vm2. 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 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 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. É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 N'importe quelle condition est remplie, une alerte est créée, car une condition est remplie. Si les conditions sont combinées avec Toutes les conditions sont remplies ou Toutes les conditions sont remplies même pour différentes ressources pour chaque condition, aucune alerte n'est créée. Ces choix de combinaison nécessitent que les deux conditions soient remplies.
Supposons ensuite 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) : une alerte est créée 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, une alerte est également créée. Une alerte est créée, car vm1 et vm2 entraînent le respect de la conditionCPU usage is too high, ce qui constitue des événements distincts.Toutes les conditions sont remplies, même pour différentes ressources pour chaque condition : une alerte est créée, car les deux conditions sont remplies.
Toutes les conditions sont remplies : aucune alerte n'est créée, car cette combinaison nécessite que la même ressource entraîne le respect de toutes les conditions. Dans cet exemple, aucune alerte n'est créée, 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 cessent d'arriver ou sont retardées, le service de surveillance les classe comme manquantes. Si des données sont manquantes, les alertes ne peuvent pas être fermées. 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 (supérieur à la période de nouveau test) peut entraîner le passage des conditions à l'état "inconnu". 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 façon dont Monitoring évalue une condition de seuil de métrique lorsque les données cessent d'arriver. Par exemple, lorsqu'une alerte est ouverte et qu'une mesure attendue n'arrive pas, souhaitez-vous que Monitoring laisse l'alerte ouverte ou la ferme immédiatement ? De même, lorsque les données cessent d'arriver et qu'aucune alerte n'est ouverte, souhaitez-vous qu'une alerte soit ouverte ? Enfin, combien de temps une alerte doit-elle rester ouverte après l'arrêt de l'arrivée des données ?
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 façon 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 la période de nouveau test est définie sur Aucun nouveau test.
La période de nouveau test correspond au champ "duration" (durée) dans l'API Cloud Monitoring.
Pour configurer la durée pendant laquelle Monitoring attend avant de fermer une alerte ouverte après l'arrêt de l'arrivée des données, utilisez le champ Durée de fermeture automatique des alertes. Vous définissez la durée de fermeture automatique à l'étape Notification. La durée de fermeture automatique par défaut est de sept jours.
Les différentes options pour le champ de données manquantes sont décrites ci-dessous :
| Google Cloud console Champ "Évaluation des données manquantes" |
Résumé | Détails |
|---|---|---|
| Données manquantes vides | Les alertes ouvertes restent ouvertes. Les nouvelles alertes ne s'ouvrent pas. |
Pour les conditions remplies, la condition continue de l'être lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle le reste. Lorsqu'une alerte est ouverte 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 minuteur expire, l'alerte est fermée. Pour les conditions non remplies, elles continuent de ne pas l'être lorsque les données cessent d'arriver. |
| Les points de données manquants sont traités comme des valeurs qui ne respectent pas la condition de la règle | Les alertes ouvertes restent ouvertes. De nouvelles alertes peuvent être ouvertes. |
Pour les conditions remplies, la condition continue de l'être lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle le reste. Lorsqu'une alerte est ouverte et qu'aucune donnée n'arrive pendant la durée de fermeture automatique plus 24 heures, l'alerte est fermée. Pour les conditions non remplies, ce paramètre fait que la condition de seuil de métrique se comporte comme un |
| Les points de données manquants sont traités comme des valeurs qui n'enfreignent pas la condition de la règle. | Les alertes ouvertes sont fermées. Les nouvelles alertes ne s'ouvrent pas. |
Pour les conditions remplies, la condition cesse de l'être lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle est fermée. Pour les conditions non remplies, elles continuent de ne pas l'être lorsque les données cessent d'arriver. |
API
Vous pouvez configurer la façon dont Monitoring évalue une condition de seuil de métrique lorsque les données cessent d'arriver. Par exemple, lorsqu'une alerte est ouverte et qu'une mesure attendue n'arrive pas, souhaitez-vous que Monitoring laisse l'alerte ouverte ou la ferme immédiatement ? De même, lorsque les données cessent d'arriver et qu'aucune alerte n'est ouverte, souhaitez-vous qu'une alerte soit ouverte ? Enfin, combien de temps une alerte doit-elle rester ouverte après l'arrêt de l'arrivée des données ?
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 façon dont Monitoring détermine la valeur de remplacement des données manquantes, utilisez le champ
evaluationMissingDatade la structureMetricThreshold. Ce champ est ignoré lorsque le champdurationest nul.Pour configurer la durée pendant laquelle Monitoring attend avant de fermer une alerte ouverte après l'arrêt de l'arrivée des données, utilisez le champ
autoClosedans la structureAlertStrategy.
Les différentes options pour le champ de données manquantes sont décrites ci-dessous :
Champ APIevaluationMissingData |
Résumé | Détails |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Les alertes ouvertes restent ouvertes. Les nouvelles alertes ne s'ouvrent pas. |
Pour les conditions remplies, la condition continue de l'être lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle le reste. Lorsqu'une alerte est ouverte 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 minuteur expire, l'alerte est fermée. Pour les conditions non remplies, elles continuent de ne pas l'être lorsque les données cessent d'arriver. |
EVALUATION_MISSING_DATA_ACTIVE |
Les alertes ouvertes restent ouvertes. De nouvelles alertes peuvent être ouvertes. |
Pour les conditions remplies, la condition continue de l'être lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle le reste. Lorsqu'une alerte est ouverte et qu'aucune donnée n'arrive pendant la durée de fermeture automatique plus 24 heures, l'alerte est fermée. Pour les conditions non remplies, ce paramètre fait en sorte que la condition de seuil de métrique se comporte comme un |
EVALUATION_MISSING_DATA_INACTIVE |
Les alertes ouvertes sont fermées. Les nouvelles alertes ne s'ouvrent pas. |
Pour les conditions remplies, la condition cesse d'être remplie lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle est fermée. Pour les conditions non remplies, elles continuent de ne pas l'être lorsque les données cessent d'arriver. |
Pour minimiser les problèmes liés aux données manquantes, vous pouvez effectuer l'une des opérations suivantes :
- Contactez votre fournisseur de services cloud tiers pour identifier les moyens de réduire la latence de collecte des métriques.
- Utilisez des intervalles de temps plus longs pour les tests dans vos conditions. L'utilisation d'une période de retest plus longue 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 Monitoring.
- 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 Présentation de l'agent Ops, 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 alertes
Cloud Monitoring envoie une notification lorsqu'une série temporelle entraîne le respect d'une condition. La notification est envoyée à tous les canaux de notification. Vous ne pouvez pas limiter une notification à un canal spécifique ni à un sous-ensemble des canaux de votre règle.
Si vous configurez des notifications répétées, la même notification est renvoyée à des canaux de notification spécifiques pour votre règle d'alerte.
Vous pouvez recevoir plusieurs notifications uniques liées à une même règle d'alerte dans les cas suivants :
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 une alerte.
Vous ne pouvez pas configurer Cloud Monitoring pour qu'il ne crée qu'une seule alerte et n'envoie qu'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 entraîne le respect de 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 et lorsqu'elle cesse de l'être. 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'alertes
Dans les situations suivantes, Monitoring ne crée pas d'alertes ni n'envoie 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 veille.
- La surveillance a atteint la limite du nombre maximal d'alertes ouvertes.
Règles d'alerte désactivées
Monitoring ne crée pas d'alertes ni n'envoie de notifications pour les règles d'alerte désactivées. Toutefois, le service 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 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 prises 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 avec des intervalles de temps plus longs.
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 échoue, mais comme la règle d'alerte est désactivée, vous n'êtes pas averti. Si vous redémarrez le processus et activez immédiatement la règle d'alerte, Monitoring reconnaît que le processus n'a pas été actif au cours des cinq dernières minutes et ouvre une alerte.
Les alertes associées à une règle d'alerte désactivée restent ouvertes jusqu'à l'expiration de la durée de fermeture automatique de la règle.
Règles d'alerte mises en veille
Monitoring n'envoie pas de notifications ni ne crée d'alertes pour une règle d'alerte mise en veille. Nous vous recommandons de mettre en veille les règles d'alerte lorsque vous souhaitez empêcher une règle d'alerte d'envoyer des notifications pendant de courtes périodes uniquement. Par exemple, avant d'effectuer une maintenance sur une machine virtuelle (VM), vous pouvez créer une mise en veille et ajouter aux critères de mise en veille les règles d'alerte qui surveillent l'instance.
Lorsque vous mettez en veille une règle d'alerte, Monitoring ferme toutes les alertes ouvertes associées à la règle. La surveillance peut ouvrir de nouvelles alertes après l'expiration de la mise en veille. Pour en savoir plus, consultez Mettre en veille les notifications et les alertes.
Limites des notifications et des alertes ouvertes
Une règle d'alerte peut s'appliquer à de nombreuses ressources, et un problème affectant toutes les ressources peut entraîner l'ouverture d'alertes pour chaque ressource. Une alerte est ouverte pour chaque série temporelle qui génère une condition remplie.
Pour éviter de surcharger le système, le nombre d'alertes qu'une même règle peut déclencher simultanément est limité à 1 000.
Par exemple, prenons l'exemple d'une règle qui s'applique à 2 000 instances Compute Engine et où chaque instance entraîne le respect des conditions d'alerte. La surveillance limite le nombre d'alertes ouvertes à 1 000. Toutes les conditions restantes qui sont remplies sont ignorées jusqu'à ce que certaines des alertes ouvertes pour cette règle soient fermées.
En raison de cette limite, un même 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 de manière indépendante.
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 présente une latence allant jusqu'à 180 secondes, Monitoring ne créera pas d'alerte pendant 180 secondes maximum après que la condition de la règle d'alerte a pris la valeur "true". Pour en savoir plus, consultez Latence des données de métrique.
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 la collecte. Toutefois, le délai dépend de la métrique. Les calculs des règles d'alerte prennent un délai supplémentaire de 5 minutes et 30 secondes maximum. 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 en moyenne de deux 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 lorsqu'elles sont vraies pendant toute la période de nouveau test. Par exemple, si vous définissez un intervalle de cinq minutes pour les nouveaux tests, la notification sera 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
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.