Ce document explique comment recevoir une notification lorsque votre application échoue ou lorsque ses performances ne satisfont pas les critères définis.
Fonctionnement des alertes
Le processus d'alerte Cloud Monitoring comporte trois parties:
Une règle d'alerte, qui décrit les circonstances dans lesquelles vous souhaitez être averti d'un incident et de quelle manière. Elle peut surveiller les données de séries temporelles stockées par Monitoring ou les journaux stockés par Cloud Logging. Lorsque ces données remplissent la condition définie dans la règle d'alerte, Monitoring crée un incident et envoie les notifications.
Chaque incident est un enregistrement du type de données surveillées et du moment où les conditions ont été remplies. Ces informations peuvent vous aider à résoudre les problèmes à l'origine de l'incident.
Un canal de notification définit la manière dont vous recevez des notifications lorsque Monitoring crée un incident. Par exemple, vous pouvez configurer un canal de notification pour envoyer un e-mail à
my-support-team@example.comet publier un message Slack sur le canal#my-support-team. Une règle d'alerte peut contenir un ou plusieurs canaux de notification.
Les règles d'alerte peuvent évaluer trois types de données:
Données de séries temporelles, également appelées données métriques, stockées par Monitoring. Ces types de règles sont appelés règles d'alerte basées sur les métriques.
Pour apprendre à configurer une règle d'alerte basée sur des métriques, consultez le guide de démarrage rapide de Compute Engine.
Données d'entrée de journal stockées par Cloud Logging. Les règles d'alerte qui évaluent des entrées de journal individuelles sont appelées règles d'alerte basées sur les journaux. Les règles d'alerte basées sur les journaux vous avertissent lorsqu'un message particulier s'affiche dans vos journaux. Pour en savoir plus, consultez la page Surveiller vos journaux.
Résultats d'une requête SQL exécutée dans Log Analytics sur les données d'entrée de journal stockées dans Logging. Les règles d'alerte qui surveillent les résultats d'une requête SQL sont appelées règles d'alerte basées sur SQL. Pour en savoir plus, consultez la section Surveiller les résultats de vos requêtes SQL à l'aide d'une règle d'alerte.
Les règles d'alerte basées sur SQL sont disponibles en version Preview publique.
Le processus d'alerte vous aide à répondre aux problèmes lorsque les performances d'une application ne répondent pas aux valeurs acceptables. Par exemple, vous déployez une application Web sur une instance de machine virtuelle (VM) Compute Engine. Même si vous vous attendez à ce que la latence de réponse HTTP varie, vous souhaitez que votre équipe d'assistance réagisse lorsque l'application présente une latence élevée sur une période prolongée. Vous pouvez créer une règle d'alerte basée sur une métrique qui surveille la métrique de latence de la réponse HTTP de l'application. Si la latence de réponse est supérieure à deux secondes pendant au moins cinq minutes, Monitoring crée un incident et envoie des notifications par e-mail à votre équipe d'assistance.
Créer une règle d'alerte
Il existe plusieurs façons de créer une règle d'alerte. Par exemple, vous pouvez utiliser des règles d'alerte préconfigurées en activant les alertes recommandées à partir d'intégrations ou de certaines pages de la console Google Cloud. Vous pouvez également configurer une nouvelle règle d'alerte à l'aide de la console Google Cloud, de l'API Cloud Monitoring, de la Google Cloud CLI et de Terraform.
Utiliser les intégrations et les règles d'alerte recommandées
Monitoring fournit des packages prédéfinis qui vous permettent de créer des règles d'alerte pour vos services Google Cloud et vos intégrations tierces. Les packages incluent des règles d'alerte recommandées, des exemples de tableaux de bord et des métriques clés pour le service. Ces packages sont disponibles pour les services Google Cloud tels que Google Kubernetes Engine, Compute Engine et Cloud SQL, ainsi que pour les intégrations tierces courantes telles que MongoDB, Kafka et Elasticsearch.
Lorsque vous installez un package, vous pouvez activer les règles d'alerte recommandées pour ce package. Lorsque vous activez une règle d'alerte recommandée, vous configurez son canal de notification et modifiez éventuellement d'autres valeurs. Une fois la configuration terminée, la règle d'alerte commence immédiatement à surveiller sa cible, sans aucune autre saisie utilisateur requise.
Les règles d'alerte recommandées sont utiles lorsque vous avez déployé un nouveau service et que vous souhaitez recevoir des alertes sur des métriques importantes. Par exemple, le package d'intégration Cloud SQL est fourni avec des stratégies d'alerte recommandées pour les instances ayant échoué et les transactions lentes:
Pour en savoir plus sur les intégrations d'alertes, consultez la section Surveiller des applications tierces.
Créer des règles d'alerte
Vous pouvez créer des règles d'alerte pour surveiller différents types de données en fonction de vos besoins. Les sections suivantes répertorient les différents types de données que vous pouvez surveiller à l'aide de règles d'alerte.
Surveiller les données de séries temporelles
| Type de condition | Description | Exemple |
|---|---|---|
| Condition de seuil de métrique | Les conditions de seuil des métriques sont remplies lorsque les valeurs d'une métrique sont supérieures ou inférieures à un seuil pour une période de nouvelle analyse spécifique. Pour en savoir plus, consultez les pages Créer des règles d'alerte basées sur un seuil de métrique et Créer des règles d'alerte à l'aide de l'API. |
Vous souhaitez créer une règle d'alerte qui envoie une notification lorsque la latence de réponse est de 500 ms ou plus pendant cinq tests de disponibilité consécutifs sur une période de 10 minutes. |
| Condition d'absence de métrique | Les conditions d'absence de métrique sont remplies lorsqu'une série temporelle surveillée ne contient aucune donnée pour une période de nouvelle analyse spécifique. La période maximale de nouvelle analyse est de 23,5 heures. Pour en savoir plus, consultez les pages Créer des règles d'alerte en cas d'absence de métrique et Créer des règles d'alerte à l'aide de l'API. | Vous souhaitez créer une règle d'alerte qui ouvre un incident auprès de votre équipe d'assistance lorsqu'une ressource ne répond à aucune requête HTTP pendant cinq minutes. |
| Condition de valeur de métrique prévue | Les conditions de valeur de métrique prévue sont remplies lorsque la règle d'alerte prévoit que le seuil sera dépassé au cours de la prochaine fenêtre de prévision. La période de prévision peut aller de 1 heure à 7 jours. Pour en savoir plus, consultez les pages Créer des règles d'alerte basées sur la valeur prévue d'une métrique et Créer des règles d'alerte à l'aide de l'API. |
Vous souhaitez qu'une règle d'alerte ouvre un incident auprès de votre équipe d'assistance lorsqu'une ressource est susceptible d'atteindre 80% de l'espace disque dans les 24 heures. |
Surveiller les données des entrée de journal
Pour surveiller des entrées de journal individuelles, utilisez une règle d'alerte basée sur les journaux.
Une condition d'une règle d'alerte basée sur les journaux est remplie lorsque la règle d'alerte détecte qu'une expression d'une entrée de journal correspond aux critères de la règle d'alerte. Par exemple, vous souhaitez une règle d'alerte qui ouvre un incident auprès de votre équipe d'assistance lorsque l'message d'une entrée de journal contient product_ids=['tier_1_support', 'tier_2_support'].
Pour en savoir plus, consultez la section Configurer des règles d'alerte basées sur les journaux dans la documentation sur la journalisation.
Surveiller les résultats des requêtes SQL
Pour surveiller les résultats des requêtes SQL, utilisez une règle d'alerte basée sur SQL.
La condition d'une règle d'alerte basée sur SQL analyse régulièrement vos données d'entrée de journal, puis crée des incidents lorsque la table des résultats de la requête répond à certains critères. Ce type de règle d'alerte est utile lorsque vous avez besoin d'une règle d'alerte qui surveille les agrégations de données ou les modèles complexes sur plusieurs entrées de journal. Par exemple, vous souhaitez être averti lorsque plus de 50 entrées de journal au cours des 60 dernières minutes ont une gravité de WARNING.
Pour en savoir plus, consultez la section Surveiller les résultats de vos requêtes SQL à l'aide d'une règle d'alerte dans la documentation sur la journalisation.
Composants des règles d'alerte
Chaque règle d'alerte comporte les composants suivants:
Condition qui décrit lorsqu'une ressource ou un groupe de ressources est dans un état nécessitant une réponse de votre part. La condition inclut la source de données, un seuil statique ou dynamique, ainsi que des méthodes d'agrégation des données telles que les filtres et les regroupements. Vos conditions peuvent surveiller une seule métrique, plusieurs métriques ou un ratio de métriques. Vous pouvez également utiliser le langage de requête Prometheus (PromQL) pour inclure des expressions complexes telles que des seuils dynamiques et une logique conditionnelle.
Si vous utilisez une intégration pour activer une règle d'alerte recommandée, la condition de la règle d'alerte est préremplie.
Liste des canaux de notification qui décrivent qui doit être averti lorsqu'une action est requise. Pour en savoir plus, consultez la page Créer et gérer des canaux de notification.
Documentation qui s'affiche dans les notifications et les pages d'incidents Vous pouvez configurer l'objet d'une notification et ajouter des informations utiles dans le corps de la notification. Par exemple, vous pouvez configurer la notification pour afficher des liens vers des playbooks internes ou vers des pages Google Cloud telles que des tableaux de bord personnalisés. Pour en savoir plus sur la documentation, y compris des exemples, consultez la section Annoter les incidents avec une documentation définie par l'utilisateur.
Langages de requête
Utilisez des langages de requête et des filtres dans vos règles d'alerte pour mieux contrôler l'évaluation de vos métriques. Monitoring accepte les types de requêtes suivants:
Le langage de requête Prometheus (PromQL) est un langage de requête fonctionnel utilisé pour évaluer les données de séries temporelles en temps réel. Vous pouvez configurer des règles d'alerte pour inclure une requête PromQL dans leurs conditions. Vos requêtes PromQL peuvent utiliser n'importe quelle expression valide, comme des combinaisons de métriques, des ratios et des seuils de mise à l'échelle. En configurant des règles d'alerte avec une condition basée sur PromQL dans Google Cloud, vous pouvez réduire les dépendances vis-à-vis de l'infrastructure d'alerte externe. Pour en savoir plus, consultez les pages PromQL dans Cloud Monitoring et Règles d'alerte avec PromQL.
Les filtres de surveillance vous permettent de configurer des règles d'alerte pour utiliser des ratios de métriques basés sur des filtres. Les règles d'alerte basées sur des filtres ne peuvent pas être consultées ni modifiées dans la console Google Cloud. Pour obtenir un exemple de règle qui utilise des filtres de surveillance, consultez la section Ratio de métriques.
Le langage MQL (Monitoring Query Language) est une interface textuelle expressive qui vous permet de récupérer, filtrer et manipuler des données de séries temporelles. Vous pouvez créer des règles d'alerte avec des conditions qui incluent une opération d'alerte en langage MQL. Pour en savoir plus, consultez la présentation du langage MQL et la section Règles d'alerte avec MQL.
Gérer les règles d'alerte et les incidents
Une fois une règle d'alerte activée, Monitoring surveille en permanence les conditions de cette règle. Vous ne pouvez pas configurer la règle d'alerte pour surveiller les conditions uniquement pendant certaines périodes. Si vous souhaitez désactiver la règle d'alerte pendant une certaine période, créez un report.
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, il ferme automatiquement l'incident et envoie une notification concernant la fermeture.
Tarifs
En général, les métriques système Cloud Monitoring sont gratuites, contrairement aux métriques provenant de systèmes, d'agents ou d'applications externes. Les métriques facturables sont facturées en fonction du nombre d'octets ou du nombre d'échantillons ingérés.
Pour en savoir plus sur la tarification de Cloud Monitoring, consultez les documents suivants:
Pour savoir comment surveiller le nombre de plages de suivi ou de journaux ingérés, ou pour savoir comment être averti lorsqu'un contenu spécifique est inclus dans une entrée de journal, consultez les documents suivants:
- Alertes sur l'ingestion mensuelle de journaux
- Alertes sur l'ingestion mensuelle des délais de trace
- Configurer des alertes basées sur les journaux
Étape suivante
Pour en savoir plus sur la latence des notifications et l'incidence des choix de paramètres d'une règle d'alerte sur l'envoi des notifications, consultez la page Comportement des règles d'alerte basées sur les métriques.
Pour obtenir la liste des exemples de règles basées sur les métriques, consultez la section Récapitulatif des exemples de règles d'alerte.