Comportement des règles d'alerte basées sur les métriques

Ce document décrit comment les paramètres de durée et de durée d'alignement déterminent quand une condition est remplie, comment les règles d'alerte combinent plusieurs conditions et comment elles remplacent les points de données manquants. Il décrit également le nombre maximal d'incidents ouverts pour une règle, le nombre de notifications par incident et les causes des retards de notification.

Ce contenu ne concerne pas les règles d'alerte basées sur les journaux. Pour en savoir plus sur les règles d'alerte basées sur les journaux, consultez la page Surveiller vos journaux.

Paramètres de durée et de durée de l'alignement

La période d'alignement et l'intervalle de temps sont deux champs que vous définissez lorsque vous spécifiez une condition pour une règle d'alerte. Cette section décrit brièvement la signification de ces champs.

Période d'alignement

La période d'alignement est un intervalle d'analyse à partir d'un moment donné. L'aligneur est la fonction qui combine les points dans l'intervalle d'analyse en une valeur alignée. Par exemple, lorsque la période d'alignement est de cinq minutes à 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.

Console Google Cloud

Configurez les champs d'alignement à l'aide des menus Fenêtre glissante et Fenêtrage glissant de la boîte de dialogue Nouvelle condition.

Pour en savoir plus sur les fonctions disponibles, consultez la section Aligner dans la documentation de référence de l'API. Certaines fonctions d'aligneur alignent les données et les convertissent d'un genre ou d'un type de métrique à un autre. Pour en savoir plus, consultez la section Genres, types et conversions.

API

Vous configurez les champs 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 la section Aligner dans la documentation de référence de l'API. Certaines fonctions d'aligneur alignent les données et les convertissent d'un genre ou d'un type de métrique à un autre. Pour en savoir plus, consultez la section Genres, types et conversions.

Pour illustrer l'effet de la période d'alignement sur une condition de 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. La figure suivante illustre plusieurs évaluations séquentielles de la condition :

Figure illustrant l'effet de la période d'alignement

Chacune des trois lignes représente une évaluation singulière de la condition. Les données de séries temporelles sont affichées à gauche. Les points de la période d'alignement sont indiqués par des points bleus. Les points plus anciens sont noirs. Chaque ligne affiche la valeur alignée et indique si cette valeur est supérieure au seuil de deux. Pour la ligne intitulée start, la valeur alignée est calculée comme égale à 1, ce qui est inférieur au seuil. Lors de la prochaine évaluation, la somme des échantillons dans la période d'alignement est de deux. Lors de la troisième évaluation, la somme est égale à trois et, comme cette valeur est supérieure au seuil, un minuteur est déclenché pour la durée.

Intervalle de temps

Vous utilisez la durée, ou l'intervalle de temps, pour éviter qu'une condition ne soit remplie en raison d'une seule mesure ou prévision. Par exemple, supposons que le champ de durée d'une condition soit défini sur 15 minutes. Vous trouverez ci-dessous la description du comportement de la condition en fonction de son type:

  • Les conditions de seuil de métrique sont remplies lorsque, pour une seule série temporelle, toutes les mesures alignées sur un intervalle de 15 minutes ne respectent pas 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 sur une fenêtre 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 condition, un incident est ouvert et des notifications sont envoyées lorsque la condition est remplie. Ces incidents restent ouverts tant que les conditions continuent d'être remplies.

Console Google Cloud

Pour configurer l'intervalle de temps, utilisez le champ Intervalle de nouveau test à l'étape Configurer le déclencheur.

API

Pour configurer l'intervalle de temps, 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'heure start + 2 minutes, la valeur alignée est supérieure au seuil. Cependant, la condition n'est pas remplie, car l'intervalle de temps est défini sur trois minutes. La figure suivante illustre les résultats des prochaines évaluations de la condition:

Figure illustrant l'effet de l'intervalle de temps

Même si la valeur alignée est supérieure au seuil au moment 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'heure start + 5 minutes.

Une condition réinitialise son intervalle de temps chaque fois qu'une mesure ou une prévision ne remplit pas la condition. Ce comportement est illustré dans l'exemple suivant:

Exemple: Cette règle d'alerte contient une condition de seuil de métrique qui spécifie un intervalle de temps de cinq minutes.

Si la latence de réponse HTTP est supérieure à deux secondes
et si elle est supérieure au seuil pendant cinq minutes,
ouvrez un incident et envoyez un e-mail à votre équipe d'assistance.

La séquence suivante illustre l'importance de l'intervalle de temps sur l'évaluation de la condition :

  1. La latence HTTP est inférieure à deux secondes.
  2. Pendant les trois minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes.
  3. Dans la mesure suivante, la latence est inférieure à deux secondes. La condition réinitialise donc l'intervalle de temps.

  4. Pendant les cinq minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes. La condition est donc remplie.

    Comme la règle d'alerte comporte une condition, Monitoring envoie des notifications lorsque la condition est remplie.

Définissez un intervalle de temps suffisamment long pour réduire les faux positifs, mais suffisamment court pour vous assurer que les incidents sont ouverts en temps opportun.

Bonnes pratiques pour définir la période d'alignement et l'intervalle de temps

La période d'alignement détermine le nombre d'échantillons combinés à l'aligneur:

  • La valeur minimale de la période d'alignement pour un type de métrique correspond à la période d'échantillonnage de ce type de métrique. Par exemple, si le type de métrique est échantillonné toutes les 300 secondes, la période d'alignement doit être d'au moins 300 secondes. Toutefois, si vous souhaitez combiner cinq échantillons, définissez la durée de l'alignement sur 5 * 300 s ou 1 500 secondes.

  • La valeur maximale de la période d'alignement est de 24 heures en moins du 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 18 heures.

Utilisez l'intervalle de temps pour spécifier la réactivité de l'alerte. Par exemple, si vous définissez l'intervalle de temps sur 20 minutes pour une condition d'absence de métrique, il ne doit y avoir aucune donnée pendant 20 minutes avant que la condition ne soit remplie. Pour une règle d'alerte plus réactive, définissez la durée sur une valeur inférieure. Pour les conditions de seuil de métrique, définissez la durée sur zéro pour disposer de la règle d'alerte la plus réactive. Une valeur alignée unique permet de remplir ces types de conditions.

Les conditions des règles d'alerte sont évaluées à une fréquence fixe. Les choix que vous faites pour la période d'alignement et l'intervalle de temps 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 un incident est ouvert. Pour configurer la façon dont plusieurs conditions sont combinées, effectuez l'une des opérations suivantes :

Console Google Cloud

Vous configurez 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.

Ce tableau présente les paramètres de la console Google Cloud, la valeur équivalente dans l'API Cloud Monitoring et une description de chaque paramètre:

Console Google Cloud
Valeur des déclencheurs de règle		 Valeur combinée
dans l'API Cloud Monitoring		 Signification
Une condition est remplie OR Un incident est ouvert si une ressource entraîne le respect des conditions.
Toutes les conditions sont remplies
, même pour des ressources
différentes pour chaque condition
(par défaut)		 AND Un incident est ouvert si chaque condition est remplie, même si une ressource différente entraîne le respect de ces conditions.
All conditions are met (Toutes les conditions sont remplies) AND_WITH_MATCHING_RESOURCE Un incident est ouvert si chaque condition est remplie par la même ressource. Ce paramètre est le plus contraignant.

Dans ce contexte, le terme met signifie que la configuration de la condition renvoie la valeur true. Par exemple, si la configuration est Any time series is greater than 10 for 5 minutes, la condition est remplie lorsque cette instruction est évaluée à true.

Exemple

Prenons l'exemple d'un projet Google Cloud contenant deux instances de VM, vm1 et v2. Supposons également que vous créez une règle d'alerte avec deux conditions :

  • La condition nommée CPU usage is too high surveille l'utilisation du processeur liée aux instances. Cette condition est remplie lorsque l'utilisation du processeur de n'importe quelle instance est supérieure à 100 ms/s pendant une minute.
  • La condition nommée Excessive utilization surveille l'utilisation du processeur liée aux instances. Cette condition est remplie lorsque l'utilisation du processeur de n'importe quelle 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 Any condition is met (N'importe quelle condition est remplie), un incident est créé, car une condition est remplie. Si les conditions sont combinées avec All conditions are met (Toutes les conditions sont remplies) ou All conditions are met even for different resources for each condition (Toutes les conditions sont remplies même pour différentes ressources pour chaque condition), un incident n'est pas créé. Ces choix de combinaison nécessitent que les deux conditions soient remplies.

Supposons maintenant que l'utilisation du processeur par vm1 reste supérieure à 100 ms/s et que l'utilisation du processeur par vm2 dépasse 60% pendant 1 minute. Résultat : les deux conditions sont remplies. Ce qui suit se produit en fonction de la combinaison des conditions :

  • Any condition is met (N'importe quelle condition est remplie) : un incident est créé lorsqu'une ressource entraîne le respect d'une condition. Dans cet exemple, vm2 entraîne le respect de la condition Excessive utilization.

    Si vm2 entraîne le remplissage de la condition CPU usage is too high, un incident est également créé. Un incident est créé, car vm1 et vm2 entraînent la satisfaction de la condition CPU usage is too high par des événements distincts.

  • All conditions are met even for different resources for each condition (Toutes les conditions sont remplies même pour différentes ressources pour chaque condition) : un incident est créé, car les deux conditions sont remplies.

  • Toutes les conditions sont remplies : un incident n'est pas créé, car cette combinaison nécessite que la même ressource entraîne le respect de toutes les conditions. Dans cet exemple, aucun incident n'est créé, car vm1 entraîne le respect de CPU usage is too high, tandis que vm2 entraîne le respect de Excessive utilization.

Données de métriques partielles

Lorsque des données de séries temporelles cessent d'arriver ou lorsque des données sont retardées, Monitoring classe les données comme manquantes. Des données manquantes peuvent empêcher la fermeture des incidents. Les retards de données provenant de fournisseurs cloud tiers peuvent atteindre 30 minutes, les retards de 5 à 15 minutes étant les plus courants. Un long délai (plus long que l'intervalle de temps) peut provoquer un état "inconnu" pour les conditions. Lorsque les données arrivent enfin, Monitoring a peut-être perdu une partie de l'historique récent des conditions. Une inspection ultérieure des données de la série temporelle pourrait ne pas révéler ce problème, car il n'y a plus aucune preuve des délais après l'arrivée des données.

Console Google Cloud

Vous pouvez configurer la manière dont Monitoring évalue une condition de seuil de métrique lorsque les données cessent d'arriver. Par exemple, lorsqu'un incident est ouvert et qu'une mesure attendue n'arrive pas, voulez-vous que Monitoring laisse l'incident ouvert ou le ferme immédiatement ? De même, lorsque les données cessent d'arriver et qu'aucun incident n'est ouvert, voulez-vous qu'un incident soit ouvert ? Enfin, combien de temps un incident doit-il rester ouvert après l'arrêt des données ?

Deux champs configurables indiquent comment Monitoring évalue les conditions de seuil de métrique lorsque les données cessent d'arriver:

  • Pour configurer la manière dont Monitoring détermine la valeur de remplacement pour les données manquantes, utilisez le champ Évaluation des données manquantes que vous avez défini à l'étape Déclencheur de condition. Ce champ est désactivé lorsque la fenêtre de nouveau test est définie sur Aucun nouveau test.

  • Pour configurer le délai d'attente de Monitoring avant la fermeture d'un incident ouvert une fois que les données ont cessé d'arriver, utilisez le champ Délai de fermeture automatique de l'incident. Vous définissez le délai de fermeture automatique à l'étape Notification. Par défaut, le délai de fermeture automatique est de sept jours.

Voici les différentes options disponibles pour le champ de données manquantes:

Console Google Cloud
Champ "Évaluation des données manquantes"		 Résumé Détails
Données manquantes vides Les incidents ouverts restent ouverts.
Les nouveaux incidents ne sont pas ouverts.

Lorsque les conditions sont remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive, le minuteur de fermeture automatique démarre après un délai d'au moins 15 minutes. Si le délai du minuteur expire, l'incident est clos.

Lorsque les conditions ne sont pas remplies, la condition continue d'être non remplie lorsque les données cessent d'arriver.
Points de données manquants traités comme des valeurs qui enfreignent la condition de la règle Les incidents ouverts restent ouverts.
Vous pouvez ouvrir de nouveaux incidents.

Lorsque les conditions sont remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive pendant la durée de fermeture automatique plus 24 heures, l'incident est fermé.

Lorsque les conditions ne sont pas remplies, ce paramètre entraîne le comportement de la condition de seuil de métrique comme metric-absence condition. Si les données n'arrivent pas dans le délai spécifié par la fenêtre de nouveau test, la condition est évaluée comme remplie. Pour une règle d'alerte à une condition, la condition remplie entraîne l'ouverture d'un incident.
Points de données manquants traités comme des valeurs qui n'enfreignent pas la condition du règlement Les incidents ouverts sont fermés.
Les nouveaux incidents ne sont pas ouverts.

Lorsque les conditions sont remplies, la condition cesse d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il est fermé.

Lorsque les conditions ne sont pas remplies, la condition continue d'être non 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'un incident est ouvert et qu'une mesure attendue n'arrive pas, voulez-vous que Monitoring laisse l'incident ouvert ou le ferme immédiatement ? De même, lorsque les données cessent d'arriver et qu'aucun incident n'est ouvert, voulez-vous qu'un incident soit ouvert ? Enfin, combien de temps un incident doit-il rester ouvert après l'arrêt des données ?

Deux champs configurables indiquent comment Monitoring évalue les conditions de seuil de métrique lorsque les données cessent d'arriver:

  • Pour configurer la manière dont Monitoring détermine la valeur de remplacement pour les données manquantes, utilisez le champ evaluationMissingData de la structure MetricThreshold. Ce champ est ignoré lorsque la valeur du champ duration est zéro.

  • Pour configurer le délai d'attente de Monitoring avant la fermeture d'un incident ouvert après l'arrêt des données, utilisez le champ autoClose dans la structure AlertStrategy.

Voici les différentes options disponibles pour le champ de données manquantes:

API
Champ evaluationMissingData		 Résumé Détails
EVALUATION_MISSING_DATA_UNSPECIFIED Les incidents ouverts restent ouverts.
Les nouveaux incidents ne sont pas ouverts.

Lorsque les conditions sont remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive, le minuteur de fermeture automatique démarre après un délai d'au moins 15 minutes. Si le délai du minuteur expire, l'incident est clos.

Lorsque les conditions ne sont pas remplies, la condition continue d'être non remplie lorsque les données cessent d'arriver.
EVALUATION_MISSING_DATA_ACTIVE Les incidents ouverts restent ouverts.
Vous pouvez ouvrir de nouveaux incidents.

Lorsque les conditions sont remplies, la condition continue d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il reste ouvert. Lorsqu'un incident est ouvert et qu'aucune donnée n'arrive pendant la durée de fermeture automatique plus 24 heures, l'incident est fermé.

Lorsque les conditions ne sont pas remplies, ce paramètre entraîne le comportement de la condition de seuil de métrique comme metric-absence condition. Si les données n'arrivent pas dans le délai spécifié par le champ "duration", la condition est évaluée comme remplie. Pour une règle d'alerte à une condition, la condition remplie entraîne l'ouverture d'un incident.
EVALUATION_MISSING_DATA_INACTIVE Les incidents ouverts sont fermés.
Les nouveaux incidents ne sont pas ouverts.

Lorsque les conditions sont remplies, la condition cesse d'être remplie lorsque les données cessent d'arriver. Si un incident est ouvert pour cette condition, il est fermé.

Lorsque les conditions ne sont pas remplies, la condition continue d'être non remplie lorsque les données cessent d'arriver.

Vous pouvez limiter les problèmes dus à des données manquantes en effectuant l'une des actions suivantes:

  • Contactez votre fournisseur de services cloud tiers pour savoir comment réduire la latence de collecte des métriques.
  • Utilisez des intervalles de temps plus longs dans vos conditions. Utiliser une fenêtre de temps plus longue présente l'inconvénient de rendre vos règles d'alerte moins réactives.

  • Choisissez des métriques avec un délai de collecte inférieur :

    • Les métriques d'agent de surveillance, en particulier lorsque l'agent est exécuté sur des instances de VM dans des clouds tiers.
    • Les métriques personnalisées, lorsque vous écrivez leurs données directement dans Monitoring.
    • Métriques basées sur les journaux, si la collecte des entrées de journal n'est pas retardée.

Pour en savoir plus, consultez les pages Présentation de l'agent Monitoring, Présentation des métriques définies par l'utilisateur et Métriques basées sur les journaux.

Notifications et incidents par règle

Pour empêcher Monitoring de créer des incidents et d'envoyer des notifications pour une règle d'alerte, créez une mise en pause et incluez la règle d'alerte dans les critères de mise en pause. Lorsque la mise en pause est active, la règle d'alerte ne crée pas d'incidents et n'envoie pas de notifications.

Lorsque des règles sont activées et ne correspondent pas aux critères d'une mise en pause active, des incidents peuvent être créés et des notifications peuvent être envoyées. Cette section décrit les limites concernant le nombre d'incidents ouverts par règle et indique dans quels cas vous pouvez voir plusieurs notifications pour le même incident.

Nombre d'incidents ouverts par règle

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'incidents pour chaque ressource. Un incident est ouvert pour chaque série temporelle qui entraîne une condition remplie.

Pour éviter de surcharger le système, le nombre d'incidents qu'une même règle peut ouvrir simultanément est limité à 1 000.

Prenons l'exemple d'une règle qui s'applique à 2 000 instances Compute Engine. Chaque instance entraîne le respect des conditions d'alerte. Monitoring limite le nombre d'incidents ouverts à 1 000. Toutes les conditions restantes remplies sont ignorées jusqu'à la fermeture de certains des incidents ouverts pour cette règle.

Nombre de notifications par règle

Par défaut, une notification est envoyée lorsqu'une série temporelle entraîne le remplissage d'une condition. Vous pouvez recevoir plusieurs notifications lorsque l'une des conditions suivantes est remplie:

  • Une condition surveille plusieurs séries temporelles.

  • Une stratégie contient plusieurs conditions:

    • Toutes les conditions sont remplies: lorsque toutes les conditions sont remplies, pour chaque série temporelle qui aboutit à une condition remplie, Monitoring envoie une notification et crée un incident. Par exemple, supposons que vous ayez une règle avec deux conditions, et que chacune d'elles surveille une série temporelle. Lorsque toutes les conditions sont remplies, vous recevez deux notifications et deux incidents.

    • N'importe quelle condition est remplie: la règle d'alerte envoie une notification chaque fois qu'une condition est remplie. Par exemple, supposons que vous ayez une règle avec deux conditions, et que chacune d'elles surveille une série temporelle. Supposons que la première condition soit remplie. Cela entraîne l'ouverture d'un incident et l'envoi d'une notification. Si l'incident est toujours ouvert lorsqu'une mesure ultérieure entraîne le remplissage de la deuxième condition, une autre notification est envoyée.

Les règles d'alerte créées à l'aide de l'API Cloud Monitoring vous avertissent lorsque la condition est remplie et lorsqu'elle cesse de l'être. Par défaut, les règles d'alerte créées à l'aide de la console Google Cloud vous avertissent lorsqu'un incident est ouvert. Ils ne vous avertissent pas lorsqu'un incident est fermé. Vous pouvez activer les notifications concernant la fermeture d'un incident.

Notifications pour les règles d'alerte désactivées

Lorsque vous désactivez une règle d'alerte, elle continue d'évaluer ses conditions. Toutefois, aucun incident n'est créé et aucune notification n'est envoyée.

Lorsque vous activez une règle désactivée, Monitoring examine les valeurs de toutes les conditions au cours du dernier intervalle de temps. La durée la plus récente peut inclure les données collectées avant, pendant et après l'activation de la règle. Les conditions d'une règle désactivée peuvent être remplies immédiatement après sa réactivation, même avec de longues périodes.

Par exemple, supposons que vous ayez une règle d'alerte qui surveille un processus spécifique et que vous la désactiviez. La semaine suivante, le processus s'interrompt. Comme la règle d'alerte est désactivée, vous n'êtes pas averti. Si vous redémarrez le processus et activez la règle d'alerte immédiatement, Monitoring détecte que le processus n'a pas été actif depuis cinq minutes et ouvre un incident.

Lorsque vous désactivez une règle d'alerte, les incidents ouverts restent ouverts jusqu'à l'expiration du délai de fermeture automatique. Lorsque vous mettez en pause une règle d'alerte, tous les incidents ouverts qui lui sont associés sont fermés. Toutefois, à la fin de la mise en pause, de nouveaux incidents peuvent s'ouvrir. Pour en savoir plus, consultez la section Suspendre les notifications et les alertes.

Notifications pour les règles correspondant aux critères d'une mise en pause active

Si vous souhaitez empêcher une règle d'alerte d'envoyer des notifications pour de courts intervalles, nous vous recommandons de créer une mise en pause au lieu de désactiver la règle d'alerte. Par exemple, avant d'effectuer une maintenance sur une machine virtuelle (VM), vous pouvez créer une mise en pause et ajouter aux critères de mise en pause les règles d'alerte qui surveillent l'instance.

Lorsqu'une condition d'une règle d'alerte est remplie et que cette règle répond aux critères d'une mise en pause active, aucun incident n'est créé et aucune notification n'est envoyée. Lorsque la mise en pause expire, la règle d'alerte peut créer des incidents et envoyer des notifications.

Envoyer des notifications répétées

Pour rappeler aux destinataires des notifications leurs incidents ouverts et confirmés, configurez des notifications répétées. Cette fonctionnalité est utile pour les règles d'alerte qui surveillent les ressources critiques qui, lorsqu'elles sont épuisées, peuvent entraîner l'échec d'un service. Par exemple, vous pouvez configurer des notifications répétées pour une règle d'alerte qui surveille la quantité d'espace disque disponible.

Par défaut, une règle d'alerte envoie une notification à chaque canal de notification lorsqu'un incident est ouvert. Toutefois, vous pouvez modifier le comportement par défaut et configurer une règle d'alerte pour renvoyer des notifications à tout ou partie des canaux de notification des règles d'alerte. Ces notifications répétées sont envoyées pour les incidents dont l'état est "Ouvert" ou "Confirmé". L'intervalle de ces notifications doit être d'au moins 30 minutes et de 24 heures au maximum, exprimé en secondes.

Console Google Cloud

Vous ne pouvez pas configurer de notifications répétées dans la console Google Cloud. Utilisez plutôt Google Cloud CLI ou l'API.

API

Ajoutez au moins un objet NotificationChannelStrategy à votre objet AlertStrategy. Un objet NotificationChannelStrategy comporte deux champs:

  • renotifyInterval: durée, en secondes, entre les notifications répétées.

    Vous pouvez modifier la valeur du champ renotifyInterval à tout moment. Si un incident lié à la règle d'alerte est ouvert lorsque vous modifiez l'intervalle, la règle d'alerte envoie une autre notification pour l'incident, puis redémarre la période d'intervalle.

  • notificationChannelNames: tableau de noms de ressources de canaux de notification, qui sont des chaînes au format projects/PROJECT_ID/notificationChannels/CHANNEL_ID. Ces canaux de notification reçoivent les notifications répétées aux intervalles définis par la valeur renotifyInterval.

    L'ID du canal du nom de ressource est une valeur numérique. Pour savoir comment récupérer l'ID du canal, consultez la section Répertorier les canaux de notification d'un projet.

Par exemple, l'exemple JSON suivant montre une stratégie d'alerte configurée pour envoyer des notifications répétées toutes les 1 800 secondes (30 minutes) au canal de notification répertorié:

  "alertStrategy": {
    "notificationChannelStrategy": [
      {
        "notificationChannelNames": [
          "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
        ],
        "renotifyInterval": "1800s"
      }
    ]
  }

Pour en savoir plus sur la création de règles d'alerte avec l'API, consultez Créer des règles d'alerte par API.

Pour arrêter les notifications répétées pendant un certain temps, désactivez ou créez une mise en attente pour la règle d'alerte. Pour arrêter complètement les notifications répétées, modifiez la règle d'alerte à l'aide de l'API et supprimez l'objet NotificationChannelStrategy.

Latence

La latence désigne le délai entre l'échantillonnage d'une métrique par Monitoring et le moment où le point de données de la métrique devient visible en tant que données de séries temporelles. La latence affecte le moment où les notifications sont envoyées. Par exemple, si une métrique surveillée a une latence allant jusqu'à 180 secondes, Monitoring ne crée pas d'incident pendant un délai maximal de 180 secondes après que la condition de la règle d'alerte est évaluée à "true". Pour en savoir plus, consultez la section Latence des données de métriques.

Les événements et paramètres suivants contribuent à la latence:

  • Le délai de collecte des métriques: le 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 60 à 90 secondes. Pour les métriques AWS CloudWatch, le délai de visibilité peut être de plusieurs minutes. Pour les tests de disponibilité, il peut s'agir d'une moyenne de deux minutes (à partir de la fin de l'intervalle de temps).

  • L'intervalle de temps : la période configurée pour la condition. Les conditions ne sont remplies que lorsqu'une condition est remplie pendant l'intervalle de temps. Par exemple, un paramètre de fenêtre de durée de cinq minutes entraîne un retard d'au moins cinq minutes dans la notification à compter du moment où l'événement se produit pour la première fois.

  • Délai de réception de la notification: les canaux de notification, tels que les e-mails et les SMS, peuvent connaître des latences réseau ou autres (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