Présentation des alertes

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 concernant les règles d'alerte supposent que vous utilisez des règles d'alerte basées sur les métriques. Pour savoir comment 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 des 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 qu'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 métrique Latence de réponse HTTP et spécifie quand les valeurs de la métrique nécessitent une réponse. La condition est met lorsque la ressource ou le groupe de ressources est 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 fonctionne 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, le format Markdown et les 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 la création de l'incident. 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 indique 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 route fermée.

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 reçoit des notifications lorsque votre application présente 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 lance 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 à Cloud Console et confirme avoir reçu 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 de moins de deux secondes, il ferme l'incident et envoie une notification à l'équipe d'assistance pour lui indiquer que l'incident est fermé.

Si la latence augmente au-delà 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 la CLI Google Cloud :

  • Lorsque vous utilisez Cloud Console, vous pouvez activer une alerte recommandée ou créer une alerte depuis 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 permet de créer des liens vers des règles d'alerte configurées pour surveiller l'utilisation de la mémoire et la latence du réseau de ces instances.

    Vous pouvez également modifier et afficher des règles que vous créez à l'aide de Cloud Console via Cloud Console ou l'API Cloud Monitoring. L'API Cloud Monitoring vous permet de créer des règles d'alerte qui surveillent les ratios de métriques. Lorsque ces règles utilisent des filtres Monitoring, vous ne pouvez pas les afficher ni les modifier à l'aide de Cloud Console.

    Pour savoir comment créer une règle d'alerte lors de l'ouverture de la page Alertes de Cloud Monitoring, consultez la section Créer des règles d'alerte à l'aide de Cloud Console.

  • Lorsque vous utilisez l'API Cloud Monitoring directement ou lorsque vous utilisez la CLI Google Cloud, 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 la CLI Google Cloud. Lorsque vous utilisez l'API Cloud Monitoring, vous pouvez spécifier le rapport à l'aide du langage MQL (Monitoring Query Language) ou des filtres Monitoring. Pour obtenir un exemple de stratégie qui utilise des filtres Monitoring, consultez la section Ratio de métriques.

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

Cloud Monitoring accepte un langage textuel expressif qui peut être utilisé avec Google Cloud Console 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 en utilisant l'explorateur de journaux disponible dans Cloud Logging ou 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 associées à votre projet et les modifier, 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 CLI Google Cloud lors de la configuration du contrôle des accès. Pour en savoir plus, consultez la section Accorder, modifier et révoquer les accès. Cloud Console affiche les noms des rôles, tels que Monitoring Editor.

Rôles 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 Cloud Console, procédez comme suit:

  1. Ouvrez Cloud Console, puis sélectionnez le projet Google Cloud:

    Accéder à 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 ou de tests de disponibilité est totalement gratuite, mais dans les limites suivantes :

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