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 effectuer le suivi des 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 des métriques. Pour apprendre à configurer une règle d'alerte basée sur les métriques, consultez le guide de démarrage rapide de 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'alertes 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 décrivant quand une ressource, ou un groupe de ressources, se trouve dans un état qui vous oblige à répondre. 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 le moment où 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 vous oblige à répondre.

  • 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, le 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 pour qu'elles soient surveillées uniquement pendant 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 respectées, Monitoring ferme automatiquement l'incident et envoie une notification concernant la 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 vous attendiez que la latence de la réponse HTTP varie, vous souhaitez que votre équipe d'assistance réponde lorsque l'application présente une latence élevée sur une période significative.

Pour vous assurer que votre équipe d'assistance est informée lorsque votre application subit des latences élevées, vous devez créer 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.

Il s'avère que votre application Web est populaire et que 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 à 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 reçoit une mesure de latence HTTP de moins de deux secondes, il ferme l'incident et envoie une notification à votre équipe d'assistance indiquant que l'incident est clos.

Si la latence dépasse 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 du SDK Cloud:

  • Lorsque vous utilisez 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 qui sont configurées pour vous avertir lorsque vous atteignez une limite de quota. De même, la page Instances de VM de Monitoring contient des règles d'alerte configurées pour surveiller l'utilisation de la mémoire et la latence réseau de ces instances.

    Toutes les règles que vous créez à l'aide de Cloud Console vous permettent également de les modifier et de les afficher à l'aide de 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 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 plus d'informations sur la création d'une règle d'alerte lors du démarrage sur la page Alertes de Cloud Monitoring, consultez la section Créer des règles d'alerte à l'aide de Cloud Console.

  • Lorsque vous utilisez directement l'API Cloud Monitoring ou le SDK Cloud, vous pouvez créer, afficher et modifier des règles d'alerte. Vous pouvez créer des conditions qui surveillent un ratio de métriques à l'aide de l'API Cloud Monitoring ou du SDK Cloud. 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 stratégie utilisant des filtres Monitoring, consultez la section Ratio de métriques.

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

Cloud Monitoring est compatible avec un langage expressif basé sur le texte qui peut être utilisé avec Google Cloud Console et 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 disponible dans Cloud Logging ou à l'aide 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'alertes basées sur les métriques de votre projet et modifier ces règles, consultez la page suivante:

Pour plus d'informations sur la gestion des règles d'alertes 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 se présentent sous la forme roles/monitoring.editor et sont transmis en tant qu'arguments à l'outil de ligne de commande gcloud 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 des noms de rôles tels que "Éditeur Monitoring".

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

Étape suivante