Les règles d'alerte en profondeur

Cette page vous offre une présentation détaillée des concepts de règles d'alerte de Stackdriver Monitoring. Les explications de ce document vous aideront à utiliser efficacement les règles d'alerte.

Pour en savoir plus sur la création et la gestion des règles d'alerte, consultez les pages suivantes :

Règles

Une règle d'alerte définit les conditions selon lesquelles un service est considéré comme défaillant. Lorsque les conditions sont remplies, la règle se déclenche et ouvre un nouvel incident. La règle déclenchée envoie également des notifications, si vous activez cette option.

Une règle appartient à un espace de travail individuel. Chaque espace de travail peut contenir jusqu'à 500 règles.

Conditions

Une condition détermine à quel moment une règle d'alerte doit se déclencher. Pour décrire une condition, vous devez indiquer :

  • une métrique à mesurer ;
  • un test pour déterminer à quel moment cette métrique atteint un état dont vous souhaitez être informé.

En fonction des éléments que vous souhaitez surveiller, vous pouvez créer une condition faisant référence à ce qui suit :

Types de conditions

Les conditions sont basées sur des métriques et peuvent surveiller si une métrique atteint une valeur spécifique ou si elle subit un changement soudain, par exemple. Les métriques sont associées aux ressources et en mesurent certaines caractéristiques, telles que l'utilisation moyenne du processeur dans un groupe de VM. Pour en savoir plus sur les métriques, consultez la page Métriques, séries temporelles et ressources.

Toutes les conditions surveillent trois éléments : une métrique spécifique se comportant d'une certaine manière pendant un certain temps.

Toutes les conditions sont implémentées selon l'un des deux types généraux :

  • Une condition d'absence de métrique qui déclenche une série temporelle dans la métrique ne contenant aucune donnée pour un intervalle de temps spécifique.

    Les conditions d'absence de métrique nécessitent au moins une mesure réussie (d'extraction de données) depuis l'installation de la règle ou comprise dans l'intervalle de temps maximal (24 heures).

    Supposons, par exemple, que vous définissiez l'intervalle de temps d'une règle d'absence de métrique sur 30 minutes. La condition n'est pas remplie si le sous-système qui écrit les données de métrique n'a jamais écrit de point de données. Pour qu'elle soit remplie, le sous-système doit générer au moins un point de données, puis ne générer aucun point de données supplémentaire pendant 30 minutes.

  • Une condition de seuil de métrique qui se déclenche si une métrique devient supérieure ou inférieure à une valeur déterminée pendant un intervalle de temps spécifique.

    Dans la classe des conditions de seuil de métrique, les modèles suivants appartiennent à des sous-catégories générales :

    • Taux (pourcentage) de changement de métrique : se déclenche si une métrique augmente ou diminue d'une valeur spécifique exprimée en pourcentage au cours d'un certain intervalle de temps.

      Dans ce type de condition, un calcul de pourcentage de changement est appliqué à la série temporelle avant la comparaison avec le seuil.

      La condition calcule la moyenne des valeurs de la métrique lors des 10 dernières minutes, puis compare ce résultat à la moyenne sur 10 minutes mesurée juste avant l'intervalle de temps. La période d'analyse de 10 minutes utilisée par une condition de taux de changement de métrique correspond à une valeur fixe, qui ne peut être modifiée. Cependant, c'est vous qui spécifiez l'intervalle de temps au moment de la création d'une condition.

    • Seuil d'agrégation de groupe : se déclenche si une métrique mesurée dans un groupe de ressources dépasse un seuil.

    • État de test de disponibilité : se déclenche si vous avez créé un test de disponibilité et que la ressource ne parvient pas à répondre à une requête envoyée depuis au moins deux emplacements géographiques.

      Les résultats des tests de disponibilité ne figurent que sur la page Vue d'ensemble des tests de disponibilité de la console Stackdriver Monitoring. En créant une règle d'alerte sur un test de disponibilité, il est possible que des tests de disponibilité ouvrent indirectement des incidents et envoient même des notifications en cas d'échec.

    • État du processus : se déclenche si le nombre de processus, (1) exécutés sur une instance de VM ou un groupe d'instances et (2) correspondant à une chaîne, est supérieur ou inférieur à un nombre spécifique au cours d'un certain intervalle de temps.

      Ce type de condition nécessite l'exécution de l'agent de surveillance sur les ressources surveillées.

Des exemples pour chacun de ces types sont disponibles ci-dessous :

Type de condition Exemple JSON
Seuil de métrique View
Taux de changement View
Agrégation de groupe View
Test de disponibilité View
État du processus View

Combiner des conditions

Une règle peut contenir jusqu'à six conditions. Si vous utilisez plusieurs conditions, les trois options suivantes vous permettent de spécifier les combinaisons qui enfreignent une règle :

  • OR : n'importe quelle condition est remplie.
  • AND : au moins une ressource enfreint chaque condition, même si une ressource différente enfreint chaque condition.
  • AND_WITH_RESOURCES : une même ressource enfreint toutes les conditions. (Cette option n'est disponible que pour les conditions créées à l'aide de l'API Monitoring.)

Intervalle de temps

Une condition inclut un intervalle de temps, qui correspond à la durée pendant laquelle une condition doit être évaluée comme étant vraie avant de se déclencher. Les intervalles de temps des conditions empêchent les règles d'alerte de se déclencher de manière excessive. Il est important de réduire les faux positifs, car une règle d'alerte qui envoie un flux constant de notifications finira par être ignorée.

En règle générale, plus la disponibilité du service est élevée ou plus les conséquences de non-détection de problèmes sont importantes, plus l'intervalle de temps à spécifier doit être court.

Les fluctuations de performances sont un phénomène normal. Ainsi, il vaut mieux éviter qu'une règle ne se déclenche lorsqu'une seule mesure correspond à une condition. Pour éviter cela, il est généralement recommandé de faire correspondre plusieurs mesures consécutives à une condition avant de considérer l'état d'une application comme défaillant.

Une condition réinitialise son intervalle de temps chaque fois qu'une mesure enfreint la condition.

Exemple

La condition suivante spécifie un intervalle de temps de cinq minutes :
latence HTTP supérieure à deux secondes pendant cinq minutes consécutives.

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

  1. Pendant trois minutes consécutives, la latence HTTP est supérieure à deux secondes.
  2. Dans la mesure suivante, la latence tombe en dessous de deux secondes. La condition réinitialise l'intervalle de temps.
  3. Pendant les cinq minutes consécutives suivantes, la latence HTTP est supérieure à deux secondes, ce qui déclenche la règle.

Les intervalles de temps doivent être suffisamment longs pour réduire les faux positifs, mais suffisamment courts pour que les incidents soient ouverts en temps opportun.

Comportement des règles

Les règles d'alerte sont utilisées dans des environnements dynamiques et complexes, il convient donc de bien comprendre certaines des variables pouvant affecter leur comportement. Ces variables incluent les métriques et les ressources surveillées par des conditions, les intervalles de temps des conditions et les canaux de notification.

Cette section fournit des informations supplémentaires pour vous aider à comprendre le comportement des règles d'alerte.

Règles d'alerte désactivées

Vous pouvez activer et désactiver une règle pour suspendre temporairement les règles d'alerte, puis les redémarrer. Par exemple, si une règle d'alerte est configurée pour vous avertir lorsqu'un processus est interrompu pendant plus de 5 minutes, vous pouvez la désactiver lorsque vous interrompez vous-même le processus pour effectuer une mise à jour ou toute autre activité de maintenance.

Même si la désactivation d'une règle d'alerte empêche la règle de se déclencher (ou de résoudre les incidents), Stackdriver continue d'évaluer les conditions de la règle et d'enregistrer les résultats.

Supposons que le processus surveillé est interrompu pendant 20 minutes à des fins de maintenance. Si vous redémarrez le processus et réactivez la règle d'alerte immédiatement, le processus est reconnu comme inactif pendant les 5 dernières minutes et un incident est ouvert.

Lorsqu'une règle désactivée est réactivée, Stackdriver examine les valeurs de toutes les conditions sur l'intervalle de temps le plus récent, pouvant inclure des données prises avant, pendant et après l'intervalle de pause. Les règles peuvent se déclencher immédiatement après leur réactivation, même avec des intervalles de temps plus longs.

Incidents inhabituels

Les règles d'alerte, en particulier celles avec des conditions d'absence de métrique ou de seuil "inférieur à", peuvent s'afficher sur la page Alertes > Incidents en se déclenchant de façon prématurée ou incorrecte.

Cela se produit lorsqu'il y a un fossé dans les données. Ces fossés ne sont pas toujours faciles à identifier. Le fossé peut être masqué ou corrigé.

Dans les graphiques, par exemple, les fossés présents dans les données sont interpolés. Même s'il manque plusieurs minutes de données, le graphique va relier les points manquants pour la contiguïté visuelle. Un tel fossé dans les données sous-jacentes peut suffire à déclencher une règle d'alerte.

Les points dans les métriques basées sur les journaux peuvent arriver en retard et être remplis, jusqu'à 10 minutes en arrière. Ce procédé permet de corriger efficacement le fossé, qui est rempli lorsque les données arrivent enfin. Ainsi, un fossé dans une métrique basée sur les journaux qui ne peut plus être vue pourra être la cause du déclenchement d'une règle d'alerte.

Les conditions d'absence de métrique ou de seuil "inférieur à" sont évaluées en temps réel, avec un délai de requête réduit. L'état de la condition peut changer entre le moment où il est évalué et le moment où l'incident correspondant s'affiche dans la console Stackdriver Monitoring.

Données de métriques partielles

Si des mesures sont manquantes (par exemple, si aucune requête HTTP n'est formulée pendant quelques minutes), la règle utilise la dernière valeur enregistrée pour évaluer les conditions.

Exemple

  1. Une condition spécifie une latence HTTP supérieure ou égale à deux secondes pendant cinq minutes consécutives.
  2. Pendant trois minutes consécutives, la latence HTTP dure trois secondes.
  3. Pendant deux minutes consécutives, aucune requête HTTP n'est formulée. Dans ce cas, une condition reporte la dernière mesure (trois secondes) pendant ces deux minutes.
  4. Après un total de cinq minutes, la règle se déclenche, même si aucune donnée n'a été enregistrée pendant les deux dernières minutes.

Les données métriques manquantes ou différées peuvent empêcher le déclenchement de règles d'alerte et la fermeture d'incidents. Les retards de données provenant de fournisseurs cloud tiers peuvent atteindre 30 minutes, les délais les plus courants étant compris entre 5 et 15 minutes. Un long délai (plus long que l'intervalle de temps) peut provoquer un état "inconnu" pour les conditions. Lorsque les données arrivent enfin, il est possible que Stackdriver Monitoring ait perdu une partie de l'historique récent des conditions. Une inspection ultérieure des données de la série temporelle pourrait ne pas révéler ce problème, car il n'y a plus aucune preuve des délais après l'arrivée des données.

Vous pouvez minimiser ces problèmes à l'aide de l'une des opérations suivantes :

  • Contactez votre fournisseur cloud tiers pour savoir s'il existe un moyen de réduire la latence de collecte des métriques.
  • Utilisez des intervalles de temps plus longs dans vos conditions. Cette méthode a pour inconvénient d'affecter la réactivité des règles d'alerte.
  • Choisissez des métriques avec un délai de collecte inférieur :

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

Pour en savoir plus, consultez les pages Présentation de l'agent de surveillance et Utiliser des métriques personnalisées ainsi que la page sur les métriques basées sur les journaux.

Incidents par stratégie

Une règle d'alerte peut s'appliquer à de nombreuses ressources, et un problème affectant toutes les ressources peut déclencher la stratégie et ouvrir des incidents pour chaque ressource. Pour éviter toute surcharge du système, le nombre d'incidents pouvant être ouverts simultanément par une stratégie est limité à 5 000.

Par exemple, si une stratégie s'applique à 2 000 (ou 20 000) instances Compute Engine, et que pour une raison quelconque celles-ci enfreignent les conditions d'alerte, seuls 5 000 incidents seront ouverts. Les violations restantes sont ignorées jusqu'à ce que certains des incidents en cours liés à cette stratégie soient résolus.

Notifications par incident

Le nombre de notifications envoyées par incident varie en fonction des conditions de la règle.

Si une règle ne contient qu'une seule condition, une seule notification est envoyée à l'ouverture initiale de l'incident, même si les mesures ultérieures continuent de remplir la condition.

Si une règle contient plusieurs conditions, elle peut envoyer plusieurs notifications selon sa configuration :

  • Si une règle ne se déclenche que lorsque toutes les conditions sont remplies, elle n'envoie de notification qu'à l'ouverture initiale de l'incident.

  • Si une règle se déclenche lorsqu'une condition est remplie, elle envoie une notification à chaque fois qu'une nouvelle combinaison de conditions est remplie. Exemple :

    1. La condition A est remplie, un incident est ouvert et une notification est envoyée.
    2. Lorsqu'une mesure ultérieure remplit les deux conditions A et B, l'incident reste ouvert et une autre notification est envoyée.

Latence de notification

La latence de notification correspond au délai qui s'écoule entre le moment où un problème survient et le moment où une règle est déclenchée.

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

  • Le délai de collecte des métriques : le temps nécessaire à Stackdriver Monitoring pour collecter les valeurs des métriques. Pour les valeurs GCP, cette composante est généralement négligeable. Pour les métriques AWS CloudWatch, cela peut prendre plusieurs minutes. Pour les tests de disponibilité, ce délai peut représenter une moyenne de 4 minutes et atteindre au maximum 5 minutes et 30 secondes (à partir de la fin de l'intervalle de temps).

  • L'intervalle de temps : la période configurée pour la condition. Veuillez prendre en compte que les conditions ne sont remplies que si une condition est vérifiée pendant tout l'intervalle de temps. Par exemple, si vous spécifiez une période de cinq minutes, la notification sera retardée d'au moins cinq minutes à compter de la première occurrence de l'événement.

  • Le délai de notification : les canaux de notification, tels que les e-mails et les SMS peuvent eux-mêmes subir des latences réseau ou d'autres types de latence (sans rapport avec les éléments distribués), pouvant atteindre plusieurs minutes. Sur certains canaux, tels que les SMS et Slack, il n'y a aucune garantie que les messages seront distribués.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Stackdriver Monitoring
Besoin d'aide ? Consultez notre page d'assistance.