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 quand 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, et 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 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 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, ce qui est également appelé "regroupement 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 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, la période d'alignement 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.
Monitoring configure une période d'alignement comme suit :
Console Google Cloud
Vous configurez la période d'alignement en choisissant 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 à exécuter sur 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'alignement 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 Aligner dans la documentation de référence de l'API. Certaines fonctions d'alignement 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 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 est définie sur cinq minutes et que l'aligneur est défini sur sum. Supposons également que la condition est remplie lorsque la valeur alignée de la série temporelle est supérieure à deux pendant au moins trois minutes, et que la condition est évaluée toutes les minutes.
Dans cet exemple, la fenêtre 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. 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 de la période d'alignement est de deux.
Lors de la troisième évaluation, la somme est de trois. Comme cette valeur est supérieure au seuil, un minuteur est lancé pour la fenêtre de nouveau test.
Fenêtres de nouveau test
La condition d'une règle d'alerte comporte une fenêtre de nouveau test, qui empêche que la condition soit 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. 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 continue d'être remplie.
Console Google Cloud
Vous configurez la fenêtre de nouveau test à l'aide du champ Fenêtre de nouveau test à 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 illustre trois évaluations d'une condition de seuil de métrique. À l'instant 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 évaluations suivantes de la condition :
Même si la valeur alignée est supérieure au seuil au moment 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 fenêtre de nouveau test chaque fois qu'une mesure ou une prévision ne remplit pas la condition. Par conséquent, définissez une fenêtre de nouveau test suffisamment longue pour minimiser les faux positifs, mais suffisamment courte pour vérifier que les alertes sont ouvertes en temps opportun. 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,
alors ouvrez une alerte 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.
- Lors de 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.
Étant donné que la règle d'alerte ne comporte qu'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 nouveau test
Pour configurer une règle d'alerte qui évalue de manière fiable sans fausses alertes, configurez la période d'alignement et la fenêtre de nouveau test en fonction de votre cas d'utilisation.
Définir la durée de l'alignement
La période d'alignement détermine le nombre d'échantillons que l'aligneur combine en une mesure agrégée. Lorsque vous définissez la période d'alignement, tenez compte de l'intervalle d'échantillonnage et du délai d'ingestion de la métrique :
Période d'alignement minimale : la période d'alignement doit être d'au moins 60 secondes (1 minute) et doit être un multiple entier de 60 secondes. Pour vous assurer que chaque fenêtre d'alignement capture des données représentatives, définissez la période d'alignement sur au moins l'intervalle d'échantillonnage de la métrique, arrondi à un multiple de 60 secondes. Par exemple, pour une métrique échantillonnée toutes les 30 secondes, définissez la période d'alignement sur au moins 60 secondes.
Délai d'ingestion : les données de métriques subissent une latence de collecte et d'ingestion avant d'atteindre Monitoring. Lors de l'évaluation des règles d'alerte, Monitoring décale les temps d'évaluation dans le passé pour tenir compte du délai d'ingestion attendu de chaque métrique, généralement d'au moins 60 secondes, avec des délais plus courts pour les métriques telles que les tests de disponibilité et des délais plus longs pour les métriques à latence plus élevée, telles que les métriques cloud tierces ou basées sur les journaux définies par l'utilisateur. Toutefois, si une métrique externe ou tierce subit un délai d'ingestion variable qui dépasse son délai intégré, choisissez une période d'alignement suffisamment large pour capturer plusieurs intervalles d'échantillonnage afin que les échantillons retardés ne produisent pas de fenêtres d'alignement vides.
Période d'alignement maximale : pour les conditions de seuil de métrique, la période d'alignement peut être de 25 heures au maximum. Pour les conditions d'absence de métrique, la somme de la période d'alignement et de la fenêtre de nouveau test ne doit pas dépasser 25 heures. Si vous devez évaluer les tendances historiques sur des périodes d'analyse de plus de 25 heures (jusqu'à deux ans), utilisez PromQL. Les règles d'alerte PromQL qui examinent une période de plus de 25 heures nécessitent que la période de nouveau test (
duration) soit égale à zéro, ne sont pas compatibles avec les métriques personnalisées ou basées sur les journaux, et appliquent des intervalles d'évaluation minimaux qui augmentent avec la durée de la période d'analyse :- De 25 heures et 10 minutes à 8 jours : 5 minutes
- De 8 à 16 jours : 1 heure
- De 16 à 32 jours : 2 heures
- De 32 à 93 jours : 6 heures
- 93 jours à 2 ans : 12 heures
Pour en savoir plus, consultez Utiliser PromQL pour créer des règles d'alerte.
Définir la fenêtre du nouveau test
La fenêtre de nouveau test (duration) spécifie la durée pendant laquelle une série temporelle doit continuellement enfreindre le seuil de condition avant que Monitoring n'ouvre une alerte :
Réactivité : pour les conditions de seuil de métrique, définir la fenêtre de nouveau test sur zéro (affichée dans la console Google Cloud sous la forme Aucun nouveau test) entraîne l'ouverture d'une alerte lorsqu'une seule mesure alignée ne respecte pas le seuil. Pour les conditions d'absence de métrique, les données doivent être absentes pendant toute la fenêtre de nouveau test avant que la condition ne soit remplie.
Évitez les fausses alertes : pour éviter les fausses alertes causées par des pics temporaires, une instabilité de l'évaluation ou une variance de la collecte des métriques, définissez la fenêtre de nouveau test sur au moins 180 secondes (3 minutes). Si vous définissez la fenêtre de nouveau test sur zéro, une alerte s'ouvre sur un seul point anormal.
Les conditions des règles d'alerte sont évaluées à une fréquence fixe, sauf lorsque vous utilisez PromQL. Pour PromQL, la fréquence d'évaluation peut varier en fonction de la durée de rétrospection de la requête.
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 combinateur avec le champ combiner de la structure AlertPolicy.
Ce tableau liste les paramètres de la console Google Cloud , la valeur équivalente dans l'API Cloud Monitoring et une description de chaque paramètre :
| Google Cloud console Valeur des déclencheurs de règles |
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 entraîne le respect 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, uniquement si la même ressource entraîne le respect de chaque condition. Ce paramètre est l'option de combinaison la plus stricte. |
Dans ce contexte, le terme remplie signifie que la configuration de la condition est évaluée à 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 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 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 des ressources différentes 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 :
N'importe quelle 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 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, qui entraînent le respect de la conditionCPU usage is too high, sont des événements distincts.Toutes les conditions sont remplies, même pour des ressources différentes 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 nécessite 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éries temporelles cessent d'arriver ou qu'elles sont retardées, Monitoring les classe comme manquantes. Les données manquantes peuvent empêcher la fermeture des alertes. Les retards d'arrivée des données provenant de fournisseurs de services cloud tiers peuvent atteindre 30 minutes, les retards de 5 à 15 minutes étant les plus courants. Un délai long (supérieur à la fenêtre de nouveau test) peut entraîner le passage des conditions à l'é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'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 la manière dont 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 avez défini à l'étape Déclencheur de condition. Ce champ est désactivé lorsque la période de nouveau test est définie sur Pas de 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 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 de l'alerte. Vous définissez le délai de fermeture automatique à l'étape Notification. La durée de fermeture automatique par défaut est de sept jours.
Voici 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. Les nouvelles alertes ne sont pas ouvertes. |
Pour les conditions remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle reste ouverte. 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, la condition continue de ne pas être remplie 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 d'être remplie lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle reste ouverte. 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 qui ne sont pas remplies, ce paramètre entraîne un comportement de la condition de seuil de métrique semblable à celui d'une condition |
| 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 sont pas ouvertes. |
Pour les conditions qui sont 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 qui ne sont pas remplies, la condition continue de ne pas être remplie 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'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 la manière dont 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 le délai d'attente de Monitoring avant de fermer une alerte ouverte après l'arrêt de l'arrivée des données, utilisez le champ
autoClosedans la structureAlertStrategy.
Voici les différentes options pour le champ de données manquantes :
Champ evaluationMissingData de l'API |
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 d'être remplie lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle reste ouverte. 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, la condition continue de ne pas être remplie 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 d'être remplie lorsque les données cessent d'arriver. Si une alerte est ouverte pour cette condition, elle reste ouverte. 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 qui ne sont pas 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. Aucune nouvelle alerte n'est ouverte. |
Pour les conditions qui sont 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 qui ne sont pas remplies, la condition continue de ne pas être remplie lorsque les données cessent d'arriver. |
Évaluation des données manquantes tout au long du cycle de vie des charges de travail
Dans les conditions de seuil de métrique et de langage de requête Monitoring, vous pouvez configurer la manière dont Monitoring évalue les données manquantes lorsque les séries temporelles cessent de générer des rapports. Pour configurer l'évaluation des données manquantes, la condition doit avoir une fenêtre de nouveau test non nulle (duration). Les conditions PromQL ne sont pas compatibles avec les paramètres d'évaluation des données manquantes. À la place, Monitoring ferme une alerte PromQL ouverte après l'absence de données pendant deux intervalles d'évaluation, plus un délai de grâce.
Lorsqu'une condition évalue les données manquantes avec le paramètre par défaut Données manquantes vides (EVALUATION_MISSING_DATA_NO_OP ou EVALUATION_MISSING_DATA_UNSPECIFIED), une alerte déjà ouverte reste ouverte lorsque les données de métrique cessent d'arriver. Par exemple, si un job ou un conteneur éphémère subit un pic prolongé qui déclenche une alerte, puis que la charge de travail se termine, l'alerte reste ouverte jusqu'à l'expiration de la durée de fermeture automatique (sept jours par défaut), car aucun point de données ultérieur n'arrive pour démontrer que la métrique est repassée sous le seuil.
Pour aligner le comportement de la règle d'alerte sur le cycle de vie de votre application, sélectionnez un paramètre d'évaluation des données manquantes et une durée de fermeture automatique en fonction des types de charges de travail suivants :
| Type de charge de travail | Paramètre recommandé pour les données manquantes | Durée de fermeture automatique recommandée | Comportement du cycle de vie et justification |
|---|---|---|---|
| Démons et infrastructure continus (VM Compute Engine, instances Cloud SQL, nœuds GKE) |
Données manquantes vides (EVALUATION_MISSING_DATA_NO_OP) ou Valeurs qui ne respectent pas la condition (EVALUATION_MISSING_DATA_ACTIVE) |
Par défaut (7 jours) ou 24 heures | L'infrastructure continue doit émettre des données de télémétrie de métriques sans interruption. Si la télémétrie cesse alors qu'une alerte est ouverte, le maintien de l'alerte ouverte garantit que les partitions réseau, les plantages de VM ou les défaillances de daemon attirent l'attention de l'opérateur au lieu de se fermer automatiquement. |
| Charges de travail éphémères et services d'autoscaling (pods GKE, jobs et révisions Cloud Run, Cloud Tasks, nœuds de calcul Batch) |
Valeurs qui n'enfreignent pas la condition (EVALUATION_MISSING_DATA_INACTIVE) |
Entre 30 minutes et 2 heures | Les pods éphémères et les conteneurs sans serveur s'arrêtent ou effectuent un scaling à zéro une fois le travail terminé. En définissant les données manquantes sur "Inactif", vous vous assurez que lorsqu'un conteneur éphémère disparaît, la condition cesse d'être évaluée comme non respectée et l'alerte se ferme. En réduisant la durée de fermeture automatique, vous évitez que les incidents temporaires ne persistent pendant plusieurs jours. |
| Charges de travail périodiques et planifiées (requêtes par lot quotidiennes, jobs Cron horaires, analyses par jour calendaire) |
Valeurs qui n'enfreignent pas la condition (EVALUATION_MISSING_DATA_INACTIVE) |
Entre 30 minutes et 2 heures | Les charges de travail par lot périodiques ne signalent les métriques que pendant les exécutions actives. Étant donné que la durée de fermeture automatique est mesurée à partir du moment où la télémétrie cesse d'arriver, l'utilisation de EVALUATION_MISSING_DATA_INACTIVE et d'une durée de fermeture automatique raccourcie (au moins 30 minutes) empêche les alertes d'exécution unique de persister sur plusieurs jours calendaires. |
Vous pouvez minimiser les problèmes dus à des données manquantes en procédant de l'une des manières suivantes :
- Contactez votre fournisseur de services cloud tiers pour identifier les moyens de réduire la latence de collecte des métriques.
- Utilisez des fenêtres de nouveau 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.
- 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 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-t-il des notifications et crée-t-il 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 ou à 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 règle d'alerte dans les cas suivants :
Une condition surveille plusieurs séries temporelles.
Une stratégie 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, pour chaque série temporelle qui entraîne 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.
Toute 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 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 attente.
- Monitoring 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 de la règle. 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 des fenêtres de nouveau test importantes.
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 s'arrête et, 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 lié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 attente. Nous vous recommandons de répéter les règles d'alerte lorsque vous souhaitez empêcher une règle d'alerte d'envoyer des notifications pendant de courts intervalles. 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 à cette règle. Monitoring peut ouvrir de nouvelles alertes après l'expiration de la mise en pause. 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 amener la règle d'alerte à ouvrir des alertes pour chaque ressource. Une alerte est ouverte pour chaque série temporelle qui entraîne le respect d'une condition.
Pour éviter de surcharger le système, le nombre d'alertes qu'une même règle peut ouvrir simultanément est limité à 1 000.
Par exemple, prenons une règle qui s'applique à 2 000 instances Compute Engine, et chaque instance entraîne le respect des conditions d'alerte. Monitoring limite le nombre d'alertes ouvertes à 1 000. Toutes les autres conditions remplies sont ignorées jusqu'à ce que certaines des alertes ouvertes pour cette règle soient fermées.
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 indépendamment à chaque canal de notification.
Latence
La latence correspond 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 l'envoi des notifications. Par exemple, si une métrique surveillée présente une latence allant jusqu'à 180 secondes, Monitoring ne créera pas d'alerte pendant un maximum de 180 secondes après que la condition de la règle d'alerte a été évaluée comme vraie. 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 pouvant aller jusqu'à 5 minutes et 30 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 période de nouveau test).
Fenêtre du 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, un paramètre de fenêtre de nouveau test de cinq minutes entraîne des retards dans la notification d'au moins cinq minutes à compter de la première occurrence de l'événement.
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 ce qui est diffusé), 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.