Les règles d'alerte basées sur des métriques dans Cloud Monitoring vous permettent de surveiller les données de séries temporelles, de créer des alertes et d'envoyer des notifications. Vous contrôlez le moment où les règles d'alerte créent des alertes et envoient des notifications en configurant des périodes d'alignement, des fenêtres de nouveau test et des règles multiconditions. Comprendre comment les règles d'alerte gèrent les données manquantes, les limites des alertes et des notifications, ainsi que les délais de notification vous aide à minimiser les faux positifs et à ajuster la réactivité des alertes.
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 buckets de 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 comment ce point unique est calculé : vous pouvez additionner toutes les valeurs, calculer leur moyenne ou utiliser 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, lorsque la période d'alignement est de cinq minutes, à 13h00, elle contient 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.
La surveillance configure une période d'alignement comme suit :
Console Google Cloud
Pour configurer la période d'alignement, vous devez choisir 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 alignent les données et les convertissent d'un type ou d'une catégorie de métrique à un autre. Pour obtenir une explication détaillée, consultez 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 Aligner dans la documentation de référence de l'API. Certaines fonctions d'aligneur alignent les données et les convertissent d'un type ou d'une catégorie 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 de la période d'alignement sont représentés par des points bleus, tandis que 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 la prochaine évaluation, la somme des échantillons de la période d'alignement sera de 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 période de nouveau test, qui empêche la condition d'être remplie en raison d'une seule mesure ou prévision. Par exemple, supposons que la période de nouveau test 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 à 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 retest à l'aide du champ Période de retest à l'étape Configurer le déclencheur d'alerte.
API
Pour configurer la fenêtre de nouveau test, définissez le champ duration dans les structures MetricThreshold et MetricAbsence.
La figure précédente illustrait 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 illustre les résultats des prochaines évaluations de la condition :
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 à start + 5 minutes.
Une condition réinitialise sa période de retest chaque fois qu'une mesure ou une prévision ne la satisfait pas. Par conséquent, définissez une période de 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 période 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,
ouvrez une alerte et envoyez un e-mail à votre équipe d'assistance.
La séquence suivante illustre l'impact de la période de nouveau test sur l'évaluation de la condition :
- La latence HTTP est inférieure à deux secondes.
- Pendant les trois prochaines minutes consécutives, la latence HTTP est supérieure à deux secondes.
- Lors de la mesure suivante, la latence est inférieure à deux secondes. La condition réinitialise donc la période de retest.
Au cours des 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 seule condition, Monitoring envoie des notifications lorsque cette condition est remplie.
Bonnes pratiques pour définir la période d'alignement et la fenêtre 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 test à nouveau pour spécifier la réactivité de l'alerte. Par exemple, si vous définissez la période de nouveau test 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 ne soit remplie. Pour une règle d'alerte plus réactive, définissez la fenêtre de nouveau test sur une valeur plus petite. 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 faites pour la période d'alignement et la période de retest 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 quand 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 à plusieurs conditions.
API
Vous configurez les options de combinaison avec le champ combiner de la structure AlertPolicy.
Le tableau suivant répertorie les paramètres de 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ègles de la consoleGoogle Cloud |
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 une ressource différente est à l'origine de ces conditions. |
| 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, une alerte n'est ouverte que si la même ressource est à l'origine de chaque condition remplie. Il s'agit du paramètre de combinaison le plus strict. |
Dans ce contexte, le terme remplie 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 renvoie la valeur true.
Exemple
Prenons l'exemple d'un projet Google Cloud qui contient 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 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. É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.
Ensuite, supposons 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 :
Une condition est remplie : une alerte est créée lorsqu'une ressource remplit une condition. Dans cet exemple, vm2 entraîne le respect de la condition
Excessive utilization.Si vm2 remplit la condition
CPU usage is too high, une alerte est également créée. Une alerte est créée, car vm1 et vm2 qui entraînent le respect de la conditionCPU usage is too highsont 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 ce combinateur exige que la même ressource remplisse 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, Monitoring les classe comme manquantes. Si des données sont manquantes, les alertes ne peuvent pas être fermées. Les données provenant de fournisseurs de services cloud tiers peuvent arriver avec un retard allant jusqu'à 30 minutes. Les retards de 5 à 15 minutes sont les plus fréquents. Un délai important (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 la surveillance 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 fenêtre 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 clôture automatique par défaut est de sept jours.
Vous trouverez ci-dessous les différentes options pour le champ de données manquantes :
| Google Cloud console Champ "Évaluation des données manquantes" |
Résumé | Détails |
|---|---|---|
| Données manquantes vides | Les alertes ouvertes restent ouvertes. Aucune nouvelle alerte n'est ouverte. |
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 qui ne sont pas 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 entraîne le comportement d'une condition de seuil de métrique |
| 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. Aucune nouvelle alerte n'est ouverte. |
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 qui ne sont pas 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 défini sur zéro.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.
Vous trouverez ci-dessous les différentes options pour le champ de données manquantes :
Champ APIevaluationMissingData |
Résumé | Détails |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Les alertes ouvertes restent ouvertes. Aucune nouvelle alerte n'est ouverte. |
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 qui ne sont pas 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 que la condition de seuil de métrique se comporte comme un |
EVALUATION_MISSING_DATA_INACTIVE |
Les alertes ouvertes sont fermées. Aucune nouvelle alerte n'est ouverte. |
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 qui ne sont pas 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 périodes de retest plus longues dans vos conditions. L'utilisation d'une période de retest 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.
- 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 journaux 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 remplit 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èglement.
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 multicondition 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 une alerte pour chaque série temporelle qui remplit une condition.
Vous ne pouvez pas configurer Cloud Monitoring pour qu'il crée une seule alerte et envoie 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 et lorsqu'elle ne l'est plus. Les règles d'alerte créées à l'aide de la console Google Cloud n'envoient pas de notification lorsque la condition n'est plus 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, 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 période de nouveau test la plus récente peut inclure des données collectées avant, pendant et après l'activation du règlement. Les conditions d'une règle désactivée peuvent être remplies immédiatement après la reprise de la règle, même avec de grandes fenêtres de retest.
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 est interrompu, mais comme la règle d'alerte est désactivée, vous ne recevez aucune notification. 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é opérationnel 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 clôture 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 suspendez une règle d'alerte, Monitoring ferme toutes les alertes ouvertes associées à la règle. Monitoring 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. 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 remplit une condition.
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 déclenche les 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 a 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 renvoyé la valeur "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 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 vérifications du temps d'activité, cela peut prendre en moyenne deux minutes (à partir de la fin de la période de nouveau test).
Période du 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 retest. Par exemple, si vous définissez un délai de cinq minutes pour les nouveaux tests, les notifications seront retardées d'au moins cinq minutes à partir du moment où l'événement se produit.
Délai de réception des notifications : les canaux de notification, tels que les e-mails et les SMS, peuvent subir des latences réseau ou autres (sans rapport avec le contenu envoyé), qui peuvent parfois 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.