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. Pour la plupart de la documentation Cloud Monitoring sur les règles d'alerte, nous partons du principe 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 informent 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 des journaux.
Fonctionnement des alertes
Chaque règle d'alerte spécifie les éléments suivants :
Conditions qui décrivent quand 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 sur une période de cinq minutes sont supérieures à deux secondes.
Il existe trois types de conditions:
- Les conditions de seuil de métrique se déclenchent lorsque les valeurs d'une métrique sont supérieures ou inférieures à un seuil d'une fenêtre de durée spécifique.
- Les conditions d'absence de métrique se déclenchent en l'absence de mesures pendant un intervalle de temps.
- Les conditions prévues permettent de prédire le comportement futur des mesures en utilisant des données précédentes. Ces conditions se déclenchent lorsqu'il existe une prédiction de non-respect du seuil par une série temporelle dans une fenêtre de prévision.
Une règle d'alerte doit avoir au moins une condition, mais vous pouvez la configurer pour 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 ainsi que des informations sur leur configuration, consultez la page Créer et gérer des canaux de notification.
Par exemple, vous pouvez configurer une règle d'alerte pour envoyer un e-mail à
my-support-team@example.comet 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 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}.
Lorsqu'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 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 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. 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 soit 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 du seuil de métrique surveille la latence de réponse HTTP. Si cette latence est supérieure à deux secondes en continu 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 s'avère 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 :
Monitoring démarre un minuteur de cinq minutes lorsqu'il reçoit une mesure de latence HTTP supérieure à deux secondes.
Si chaque mesure de latence reçue au cours des cinq minutes suivantes est supérieure à deux secondes, le minuteur expire. Lorsque le délai expire, la condition se déclenche, et Monitoring ouvre un incident et envoie un e-mail à votre équipe d'assistance.
Votre équipe d'assistance reçoit l'e-mail, se connecte à la console Google Cloud et confirme la réception de la notification.
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.
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 pour le signaler.
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 via la console Google Cloud, l'API Cloud Monitoring ou Google Cloud CLI:
Lorsque vous utilisez la console Google Cloud, 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 renvoie vers les règles d'alerte configurées pour surveiller l'utilisation de la mémoire et la latence réseau de ces instances.
Pour savoir comment créer une règle d'alerte, consultez les documents suivants:
- Créer des règles d'alerte en fonction du seuil de métrique
- Créer des règles d'alerte en cas d'absence de métrique
- Créer des règles d'alerte basées sur les valeurs des métriques prévues
Vous pouvez également modifier et afficher toutes les règles que vous créez à l'aide de la console Google Cloud à 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 stratégies utilisent des filtres Monitoring, vous ne pouvez pas les afficher ni les modifier à l'aide de la console Google Cloud.
Lorsque vous utilisez l'API Cloud Monitoring directement ou avec 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 à l'aide de filtres Monitoring. Pour obtenir un exemple de stratégie utilisant des filtres Monitoring, consultez la section Ratio de métriques.
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 en utilisant l'explorateur de journaux de 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.
Coûts associés aux règles d'alerte
L'utilisation de règles d'alerte est gratuite. Pour en savoir plus sur les tarifs 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 |
| Longueur maximale du filtre utilisé dans une condition de seuil de métrique |
2 048 caractères Unicode | 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 de prévision maximale | 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 |
| Nombre maximal de règles d'alerte par mise en pause | 16 | Métrique, journal |
| Conservation d'une mise en pause | 13 mois | 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 |
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
Pour en savoir plus sur la latence des notifications et sur l'impact des choix liés aux paramètres d'une règle d'alerte sur l'envoi des notifications, consultez la section Comportement des règles d'alerte basées sur les métriques.
Pour obtenir une liste d'exemples de règles basées sur des métriques, consultez la page Récapitulatif des exemples de règles d'alerte.
Pour savoir comment surveiller le nombre de délais de trace ou de journaux ingérés, ou pour être averti lorsque du contenu spécifique est inclus dans une entrée de journal, consultez les pages suivantes: