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 des documents Cloud Monitoring sur les règles d'alerte supposent 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 lorsqu'une ressource ou un groupe de ressources est dans un état qui nécessite une réponse. Une règle d'alerte doit comporter au moins une condition. Cependant, vous pouvez configurer une règle pour qu'elle contienne plusieurs conditions.

    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 latence de réponse HTTP et spécifie le moment auquel les valeurs de la métrique nécessitent une réponse. La condition est met lorsque la ressource ou le groupe de ressources se trouve dans un état qui nécessite une réponse.

  • 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 à surveiller uniquement pour certaines périodes.

Lorsque les conditions de cette règle sont remplies, 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 concernant sa fermeture.

Exemple

Vous déployez une application Web sur une instance de machine virtuelle (VM) Compute Engine qui exécute une application Web. Bien que la latence de réponse HTTP fluctue, 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 est avertie 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 surveille la latence de la réponse HTTP. Si cette latence est supérieure à deux secondes pendant cinq minutes de manière continue, la condition est remplie et un incident est créé. Un pic transitoire de latence n'entraîne pas le respect 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, Monitoring marque la condition comme remplie, il ouvre un incident et envoie un e-mail à l'équipe d'assistance.

  3. Votre équipe d'assistance reçoit l'e-mail, se connecte à Google Cloud Console 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 mesure la latence HTTP en moins de deux secondes, il clôture l'incident et envoie une notification à l'équipe d'assistance pour l'avertir que l'incident est clos.

Si la latence dépasse 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 Google Cloud Console, de l'API Cloud Monitoring ou de Google Cloud CLI:

  • Lorsque vous utilisez Google Cloud Console, vous pouvez activer une alerte recommandée ou créer une alerte à partir de la page Alertes de Cloud Monitoring.

    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 de 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.

    Toutes les règles que vous créez à l'aide de Google Cloud Console peuvent également être modifiées et affichées à l'aide de Google Cloud Console 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 stratégies utilisent des filtres Monitoring, vous ne pouvez pas les afficher ni les modifier à l'aide de Google Cloud Console.

    Pour savoir comment créer une règle d'alerte lorsque vous démarrez sur la page Alertes de Cloud Monitoring, consultez la page Créer des règles d'alerte à l'aide de 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. Vous pouvez créer des conditions pour surveiller un ratio de métriques à l'aide de l'API Cloud Monitoring ou de Google Cloud CLI. Lorsque vous utilisez l'API Cloud Monitoring, vous pouvez spécifier le ratio à l'aide du langage MQL (Monitoring Query Language) ou à l'aide de filtres Monitoring. Pour obtenir un exemple de règle utilisant des filtres Monitoring, consultez Ratio de métriques.

    Pour en savoir plus sur l'utilisation de l'API Cloud Monitoring et de Google Cloud CLI, consultez la page Créer des règles d'alerte à l'aide de l'API Cloud Monitoring ou de Google Cloud CLI.

Cloud Monitoring accepte un langage textuel expressif qui peut ê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 en savoir plus sur l'affichage de la liste des règles d'alerte basées sur les métriques de votre projet et sur la modification de ces règles, consultez les pages suivantes:

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 à la 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. Google Cloud Console affiche les noms des rôles, tels que "É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 Google Cloud Console, procédez comme suit:

  1. Ouvrez Google Cloud Console 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
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
5 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