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 la manière dont vous souhaitez être averti. Cette page vous offre un aperçu des règles d'alerte.

Pour apprendre à configurer une règle d'alerte, consultez le guide de démarrage rapide de Compute Engine.

Fonctionnement des alertes

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

  • Les conditions qui décrivent quand une ressource, ou un groupe ou des ressources, se trouvent dans un état qui nécessite une action de votre part. Une règle d'alerte doit comporter au moins une condition. Toutefois, 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 à quel moment les valeurs de la métrique nécessitent une action de votre part.

  • Canaux de notification décrivant les utilisateurs qui doivent être avertis lorsqu'une action est requise. Vous pouvez inclure plusieurs canaux de notification dans une règle d'alerte. Cloud Monitoring est compatible avec les canaux de notification courants, ainsi que Cloud Mobile App et Pub/Sub. 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.

  • Documentation que vous souhaitez inclure dans une notification. Le champ de documentation est compatible avec le texte brut, Markdown et variables.

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

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

Une fois la règle d'alerte configurée, Monitoring surveille en permanence les conditions de cette règle. Vous ne pouvez pas restreindre la surveillance de ces conditions à certaines périodes uniquement. Lorsque les conditions de cette règle sont remplies, c'est-à-dire lorsque l'état des ressources nécessite une action de votre part, Monitoring crée un incident et envoie une notification concernant l'incident. 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'examiner l'incident, ainsi que toute documentation utile que vous avez spécifié.

Si un incident est ouvert et Monitoring détermine que les conditions de la règle ne sont plus remplies, 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. Même si vous n'êtes pas sans savoir que la latence de réponse HTTP peut varier en fonction de l'augmentation ou de la diminution de la demande, vous souhaitez être averti si vos utilisateurs rencontrent une latence élevée sur une période prolongée. peuvent intervenir.

Pour recevoir une notification lorsque vos utilisateurs subissent une latence élevée, 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 réponse HTTP. Si cette latence est supérieure à deux secondes en continu pendant cinq minutes, la condition est remplie et un incident est créé. Un pic de latence transitoire n'entraîne pas la création de la condition ni l'incident.

Votre application Web s'avère très populaire, et la latence des réponses est supérieure à 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 prochaines minutes est supérieure à deux secondes, le minuteur expire. Lorsque le minuteur expire, Monitoring marque la condition comme remplie, ouvre un incident et envoie un e-mail à l'équipe d'assistance.

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

  4. En suivant la documentation figurant dans l'e-mail de notification, l'équipe d'assistance pourra résoudre 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 indiquant que l'incident est fermé.

Une fois l'incident fermé, si la latence de réponse HTTP augmente plus de deux secondes et reste supérieure à ce seuil pendant cinq minutes, Monitoring ouvre un nouvel incident et envoie un e-mail de notification.

Ajouter une règle d'alerte

Vous pouvez ajouter une règle d'alerte à votre projet Google Cloud à l'aide de Google Cloud Console, de l'API Cloud Monitoring ou du SDK Cloud:

  • Si vous utilisez Cloud Console, vous pouvez activer une alerte recommandée ou en créer une 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, si vous consultez la page Sujets de Pub/Sub Lite, vous pouvez activer une alerte pour vous avertir lorsque vous atteignez une limite de quota. De même, si vous affichez la page Instances de VM dans Monitoring, vous pouvez activer les règles d'alerte recommandées qui surveillent l'utilisation de la mémoire et la latence du réseau de ces instances.

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

  • Si vous utilisez l'API Cloud Monitoring directement ou si vous utilisez le SDK Cloud, vous pouvez créer, afficher et modifier des règles d'alerte. Si vous souhaitez que la condition d'une règle d'alerte calcule le ratio de deux métriques, puis la compare à un seuil, vous devez créer cette règle à l'aide de l'API Cloud Monitoring ou du SDK Cloud. s'affiche en haut de l'écran. Pour obtenir un exemple de ce type de règle, reportez-vous à 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 textuel 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 les alertes, consultez la section Créer des règles d'alerte à l'aide du langage de requête Monitoring (MQL).

Gérer les règles d'alerte

Pour savoir comment afficher la liste des règles d'alerte de votre projet et comment les modifier, consultez les sections suivantes:

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. Les noms de rôle, par exemple "Éditeur Monitoring", sont affichés par Cloud Console.

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.
  • role/monitoring.editor
  • role/monitoring.admin
  • role/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
Tests de disponibilité par champ d'application des métriques 1 100
Règles d'alerte par champ d'application des métriques 2 500
Conditions par règle d'alerte 6
Canaux de notification par règle d'alerte 16
Canaux de notification par champ d'application des métriques 4 000
Incidents ouverts simultanément par règle d'alerte 5 000
Durée maximale d'une condition d'absence de métrique 1 jour
Durée maximale d'une condition de seuil de métrique 23 heures 30 minutes
1Cette 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 plus d'informations, consultez la page Gérer les tests de disponibilité.

2Apigee et Apigee hybrid sont étroitement intégrés à Cloud Monitoring. La limite d'alerte pour tous les niveaux d'abonnement Apigee (Standard, Enterprise et Enterprise Plus) est identique à celle de Cloud Monitoring: 500 par champ d'application des métriques .

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

Étape suivante