Présentation des alertes

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Les alertes permettent de détecter et de résoudre rapidement les problèmes qui surviennent dans les applications cloud.

Dans Cloud Monitoring, une règle d'alerte décrit les circonstances dans lesquelles vous souhaitez être averti et comment vous souhaitez être averti. Cette page vous offre un aperçu des règles d'alerte.

Les règles d'alerte utilisées pour suivre les données de métriques collectées par Cloud Monitoring sont appelées règles d'alerte basées sur les métriques. La plupart de la documentation Cloud Monitoring sur les règles d'alerte suppose que vous utilisez des règles d'alerte basées sur les métriques. Pour apprendre à configurer une règle d'alerte basée sur les métriques, consultez le guide de démarrage rapide pour Compute Engine.

Vous pouvez également créer des règles d'alerte basées sur les journaux, qui vous avertissent lorsqu'un message particulier apparaît dans vos journaux. Ces règles ne sont pas basées sur des métriques. 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.

Fonctionnement des alertes

Chaque règle d'alerte spécifie les éléments suivants :

  • Conditions qui décrivent le moment où une ressource ou un groupe de ressources est dans un état qui nécessite une réponse. Par exemple, vous pouvez configurer une condition comme suit:

    The HTTP response latency is higher than two seconds for at least five minutes.
    

    Dans cet exemple, la condition surveille la métrique Latence de réponse HTTP et se déclenche lorsque toutes les mesures de latence d'une période de cinq minutes sont supérieures à deux secondes.

    Il existe trois types de conditions:

    Une règle d'alerte doit comporter au moins une condition. Vous pouvez toutefois la configurer de sorte qu'elle contienne plusieurs conditions.

  • Les canaux de notification qui décrivent qui doit être averti lorsqu'une action est requise. Vous pouvez inclure plusieurs canaux de notification dans une règle d'alerte. Cloud Monitoring est compatible avec Cloud Mobile App et Pub/Sub en plus des canaux de notification courants. Pour obtenir la liste complète des canaux compatibles et des informations sur leur configuration, consultez la page Options de notification.

    Par exemple, vous pouvez configurer une règle d'alerte pour envoyer un e-mail à my-support-team@example.com et publier un message Slack sur le canal #my-support-team.

  • La documentation que vous souhaitez inclure dans une notification. Le champ de documentation accepte le texte brut, Markdown et variables.

    Par exemple, vous pouvez inclure dans la règle d'alerte la documentation suivante :

    ## HTTP latency responses
    
    This alert originated from the project ${project}, using
    the variable $${project}.
    

Une fois qu'une règle d'alerte basée sur les métriques est configurée, Monitoring surveille en permanence les conditions de cette règle. Vous ne pouvez pas configurer les conditions pour qu'elles ne soient surveillées que pour certaines périodes.

Lorsque les conditions d'une règle d'alerte se déclenchent, Monitoring crée un incident et envoie une notification concernant sa création. Cette notification comprend des informations récapitulatives sur l'incident, un lien vers la page Détails des règles qui vous permet d'enquêter sur cet incident, ainsi que toute documentation que vous avez spécifiée.

Si un incident est ouvert et que Monitoring détermine que les conditions de la règle basée sur les métriques ne sont plus remplies, Monitoring ferme automatiquement l'incident et envoie une notification sur la fermeture.

Exemple

Vous déployez une application Web sur une instance de machine virtuelle (VM) Compute Engine qui exécute une application Web. Vous prévoyez une fluctuation de la latence des réponses HTTP, mais vous souhaitez que votre équipe d'assistance réponde lorsque la latence de l'application est élevée pendant une période importante.

Pour vous assurer que votre équipe d'assistance reçoit une notification lorsque votre application subit des latences élevées, créez la règle d'alerte suivante:

  If the HTTP response latency is higher than two seconds for at least five
  minutes, then open an incident and send an email to your support team.

Dans cette règle d'alerte, la condition de seuil de métrique surveille la latence de réponse HTTP. Si cette latence est supérieure à deux secondes de manière continue pendant cinq minutes, la condition se déclenche et un incident est créé. Un pic temporaire de latence n'entraîne pas le déclenchement de la condition, ni la création d'un incident.

Votre application Web est populaire et la latence de réponse augmente au-delà de deux secondes. La règle d'alerte réagit de la manière suivante :

  1. Monitoring démarre un minuteur de cinq minutes lorsqu'il reçoit une mesure de latence HTTP supérieure à deux secondes.

  2. Si chaque mesure de latence reçue au cours des cinq minutes suivantes est supérieure à deux secondes, le minuteur expire. Lorsque le minuteur expire, la condition se déclenche et Monitoring ouvre un incident et envoie un e-mail à votre équipe d'assistance.

  3. L'équipe d'assistance reçoit l'e-mail, se connecte à la console Google Cloud et accuse réception de la notification.

  4. En suivant la documentation contenue dans l'e-mail de notification, votre équipe d'assistance sera en mesure de traiter la cause de la latence. En quelques minutes, la latence de réponse HTTP passe à moins de deux secondes.

  5. Lorsque Monitoring reçoit une mesure de latence HTTP inférieure à deux secondes, il ferme l'incident et envoie une notification à l'équipe d'assistance pour l'informer que l'incident est clos.

Si la latence dépasse de plus de deux secondes et reste supérieure à ce seuil pendant cinq minutes, un nouvel incident est ouvert et une notification est envoyée.

Ajouter une règle d'alerte

Vous pouvez ajouter une règle d'alerte basée sur les métriques à votre projet Google Cloud à l'aide de la console Google Cloud, de l'API Cloud Monitoring ou de Google Cloud CLI:

  • Lorsque vous utilisez la console Google Cloud, vous pouvez activer une alerte recommandée ou créer une alerte à partir de la page Alertes de Cloud Monitoring. Pour en savoir plus, consultez la page Créer des règles d'alerte basées sur les métriques à l'aide de la console Google Cloud.

    Les alertes recommandées sont disponibles pour certains produits Google Cloud. Ces alertes nécessitent une configuration minimale, telles que l'ajout de canaux de notification. Par exemple, la page Sujets de Pub/Sub Lite renvoie vers des alertes configurées pour vous avertir lorsque vous atteignez une limite de quota. De même, la page Instances de VM depuis Monitoring renvoie vers les règles d'alerte configurées pour surveiller l'utilisation de la mémoire et la latence du réseau de ces instances.

    Toute stratégie que vous créez à l'aide de la console Google Cloud peut également être modifiée et affichée à l'aide de la console Google Cloud ou de l'API Cloud Monitoring. L'API Cloud Monitoring vous permet de créer des règles d'alerte qui surveillent les ratios des métriques. Lorsque ces règles utilisent des filtres Monitoring, vous ne pouvez ni les afficher, ni les modifier depuis la console Google Cloud.

  • Lorsque vous utilisez l'API Cloud Monitoring directement ou lorsque vous utilisez Google Cloud CLI, vous pouvez créer, afficher et modifier des règles d'alerte. Pour en savoir plus, consultez la page Créer des règles d'alerte à l'aide de l'API Cloud Monitoring ou de Google Cloud CLI.

    Vous pouvez créer des conditions qui surveillent une seule métrique, plusieurs métriques ou un ratio de métriques. Lorsque vous utilisez l'API Cloud Monitoring, vous pouvez spécifier le ratio à l'aide du langage MQL (Monitoring Query Language) ou des filtres Monitoring. Pour obtenir un exemple de règle utilisant des filtres Monitoring, consultez Ratio de métriques.

Cloud Monitoring accepte un langage textuel expressif pouvant être utilisé avec la console Google Cloud et avec l'API Cloud Monitoring. Pour plus d'informations sur l'utilisation de ce langage avec des alertes, consultez la page Créer des règles d'alerte à l'aide du langage MQL (Monitoring Query Language).

Vous pouvez ajouter une règle d'alerte basée sur les journaux à votre projet Google Cloud à l'aide de l'explorateur de journaux de Cloud Logging ou de l'API Monitoring. 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.

Gérer les règles d'alerte

Pour savoir comment afficher la liste des règles d'alerte basées sur les métriques de votre projet et les modifier, consultez les articles suivants:

Pour en savoir plus sur la gestion des règles d'alerte basées sur les journaux, consultez la page Utiliser des alertes basées sur les journaux.

Autorisation requise pour créer des règles d'alerte

Cette section décrit les rôles ou les autorisations nécessaires pour créer une règle d'alerte. Pour en savoir plus sur la gestion de l'authentification et des accès (IAM) pour Cloud Monitoring, consultez la page Contrôle des accès.

Chaque rôle IAM possède un ID et un nom. Les ID de rôle ont la forme roles/monitoring.editor et sont transmis en tant qu'arguments à Google Cloud CLI lors de la configuration du contrôle des accès. Pour en savoir plus, consultez la page Accorder, modifier et révoquer les accès à des ressources. La console Google Cloud affiche les noms des rôles, par exemple "Éditeur Monitoring".

Rôles Google Cloud Console requis

Pour créer une règle d'alerte, le nom de votre rôle IAM pour le projet Google Cloud doit être l'un des suivants :

  • Éditeur Monitoring
  • Administrateur Monitoring
  • Propriétaire du projet

Pour afficher la liste des rôles et des autorisations associées, consultez la page Rôles.

Autorisations d'API requises

Pour créer une règle d'alerte à l'aide de l'API Cloud Monitoring, l'ID de votre rôle IAM pour le projet Google Cloud doit être l'un des suivants :

  • roles/monitoring.alertPolicyEditor : cet ID de rôle accorde les autorisations minimales nécessaires pour créer une règle d'alerte. Pour en savoir plus sur ce rôle, consultez la section Rôles d'alerte prédéfinis.
  • roles/monitoring.editor
  • roles/monitoring.admin
  • roles/owner

Pour identifier l'autorisation requise pour une méthode spécifique de l'API Cloud Monitoring, consultez la section Autorisations de l'API Cloud Monitoring. Pour afficher la liste des rôles et des autorisations associées, consultez la page Rôles.

Déterminer votre rôle

Pour déterminer votre rôle pour un projet à l'aide de la console Google Cloud, procédez comme suit:

  1. Ouvrez la console Google Cloud et sélectionnez le projet Google Cloud:

    Accéder à Google Cloud Console

  2. Pour afficher votre rôle, cliquez sur IAM et administration. Votre rôle figure sur la même ligne que votre nom d'utilisateur.

Pour déterminer les autorisations correspondant au niveau de votre organisation, contactez l'administrateur de votre organisation.

Coûts associés aux règles d'alerte

L'utilisation de règles d'alerte est gratuite. Pour en savoir plus sur la tarification des tests de disponibilité, consultez la page Récapitulatif des tarifs de Cloud Monitoring.

Les limites suivantes s'appliquent à votre utilisation des règles d'alerte et des tests de disponibilité:

Catégorie Valeur Type de règle1
Règles d'alerte (somme des métriques et des journaux) par champ d'application des métriques2 500 Métrique, journal
Conditions par règle d'alerte 6 Métrique
Période maximale qu'une condition d'absence de métrique
évalue3
1 jour Métrique
Période maximale qu'une condition de seuil de métrique
évalue3
23 heures 30 minutes Métrique
Nombre maximal de séries temporelles
surveillées par une condition de prévision
64 Métrique
Période de prévision minimale 1 heure (3 600 secondes) Métrique
Période maximale de prévisions 7 jours (604 800 secondes) Métrique
Canaux de notification par règle d'alerte 16 Métrique, journal
Taux maximal de notifications Une notification toutes les cinq minutes pour chaque alerte basée sur les journaux Journal
Nombre maximal de notifications 20 notifications par jour pour chaque alerte basée sur les journaux Journal
Nombre maximal d'incidents ouverts simultanément
par règle d'alerte
1 000 Métrique
Période après laquelle un incident sans nouvelle donnée est
automatiquement fermé
7 jours Métrique
Durée maximale d'un incident s'il n'est pas fermé manuellement 7 jours Journal
Conservation des incidents fermés 13 mois Non applicable
Conservation des incidents ouverts Indéfiniment Non applicable
Canaux de notification par champ d'application des métriques 4 000 Non applicable
Tests de disponibilité par champ d'application des métriques4 100 Non applicable
Nombre maximal de pings ICMP par test de disponibilité public 3 Non applicable
1 Métrique : règle d'alerte basée sur des données de métriques ; Journal : règle d'alerte basée sur des messages de journal (alertes basées sur les journaux)
2 Apigee et Apigee hybrid sont étroitement intégrés à Cloud Monitoring. La limite d'alerte pour tous les niveaux d'abonnements Apigee (Standard, Enterprise et Enterprise Plus) est la même que pour Cloud Monitoring : 500 par champ d'application de métriques.
3 La période maximale qu'une condition évalue est la somme de la période d'alignement et des valeurs d'intervalle de temps. Par exemple, si la période d'alignement est définie sur 15 heures et que l'intervalle de temps est défini sur 15 heures, 30 heures de données sont nécessaires pour évaluer la condition.
4 Cette limite s'applique au nombre de configurations de tests de disponibilité. Chaque configuration de tests de disponibilité inclut l'intervalle de temps entre les tests du statut de la ressource spécifiée. Pour en savoir plus, consultez la page Gérer les tests de disponibilité.

Pour connaître la tarification complète, consultez la page Tarifs de la suite d'opérations de Google Cloud.

Étapes suivantes