Les règles d'alerte dans Cloud Monitoring détectent les problèmes d'application et d'infrastructure en évaluant les résultats des métriques, des journaux ou des requêtes SQL. Lorsque les données surveillées remplissent les conditions que vous spécifiez, Monitoring crée une alerte et envoie des notifications.
Fonctionnement des alertes
Le processus d'alerte Cloud Monitoring comprend trois parties :
Une règle d'alerte décrit les circonstances dans lesquelles vous souhaitez être averti d'une alerte 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 une alerte et envoie les notifications.
Chaque alerte 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'alerte.
Un canal de notification définit la manière dont vous recevez des notifications lorsque Monitoring crée une alerte. 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. 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 de 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 savoir comment configurer une règle d'alerte basée sur des métriques, consultez le guide de démarrage rapide pour 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 apparaît dans vos journaux. Pour en savoir plus, consultez Surveiller vos journaux.
Résultats d'une requête SQL exécutée dans Observability 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 Surveiller les résultats de vos requêtes SQL avec une règle d'alerte.
Les règles d'alerte basées sur SQL sont en version Preview publique.
Le processus d'alerte vous aide à résoudre les problèmes quand les performances d'une application n'atteignent pas les valeurs acceptables. Par exemple, vous déployez une application Web sur une instance de machine virtuelle (VM) Compute Engine. Bien que vous vous attendiez à ce que la latence de réponse HTTP fluctue, vous souhaitez que votre équipe d'assistance réponde lorsque l'application présente une latence élevée sur une période étendue. Vous pouvez créer une règle d'alerte basée sur une métrique qui surveille la métrique de latence de 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 une alerte 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 des 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 consoleGoogle Cloud , de l'API Cloud Monitoring, de Google Cloud CLI et de Terraform.
Utiliser des intégrations et des règles d'alerte recommandées
Monitoring fournit des packages prédéfinis pour vous permettre de créer des règles d'alerte pour vos servicesGoogle 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 servicesGoogle 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 du package. Lorsque vous activez une règle d'alerte recommandée, vous configurez son canal de notification et, si vous le souhaitez, vous modifiez d'autres valeurs. Après la configuration, la règle d'alerte commence immédiatement à surveiller sa cible, sans qu'aucune autre intervention de l'utilisateur ne soit requise.
Les règles d'alerte recommandées sont utiles lorsque vous avez déployé un nouveau service et que vous souhaitez être alerté sur des métriques importantes. Par exemple, le package d'intégration Cloud SQL est fourni avec des règles d'alerte recommandées pour les instances défaillantes et les transactions lentes :
Pour en savoir plus, consultez les documents suivants :
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 en matière d'alertes. Les sections suivantes répertorient les différents types de données que vous pouvez surveiller avec des règles d'alerte.
Surveiller les données de séries temporelles
| Condition Type (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 fenêtre de nouveau test spécifique. Pour en savoir plus, consultez 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 qu'une règle d'alerte envoie une notification lorsque la latence de réponse est de 500 ms ou plus pour cinq tests de disponibilité consécutifs sur 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 fenêtre de nouveau test spécifique. La fenêtre de nouveau test maximale est de 24 heures. Pour en savoir plus, consultez Créer des règles d'alerte 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 envoie une alerte à votre équipe d'assistance lorsqu'une ressource ne répond à aucune requête HTTP pendant cinq minutes. |
| Condition PromQL (Prometheus Query Language) | PromQL est un langage de requête fonctionnel utilisé pour évaluer les données de séries temporelles en temps réel. Vos requêtes PromQL peuvent utiliser n'importe quelle expression valide, comme des combinaisons de métriques, des ratios et des seuils dynamiques basés sur une métrique. Pour en savoir plus, consultez PromQL dans Cloud Monitoring et Présentation des alertes PromQL. |
Vous souhaitez utiliser une expression d'alerte PromQL trouvée dans un dépôt public, vous souhaitez une règle d'alerte basée sur plusieurs métriques, telles qu'un ratio, ou vous souhaitez une règle d'alerte qui fonctionne sur plus de 25 heures de données. |
| 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édit que le seuil sera dépassé au cours de la fenêtre de prévision à venir. La période de prévision peut aller d'une heure à sept jours. Pour en savoir plus, consultez Créer des règles d'alerte basées sur des valeurs de métriques prévues et Créer des règles d'alerte à l'aide de l'API. |
Vous souhaitez créer une règle d'alerte qui ouvre une alerte auprès de votre équipe d'assistance lorsqu'une ressource est susceptible d'atteindre 80% d'utilisation de l'espace disque dans les 24 prochaines heures. |
Nous vous recommandons de filtrer sur les libellés définis sur les types de ressources surveillées plutôt que sur les libellés définis sur les types de métriques lorsque cela est possible, en particulier si vous interrogez des métriques à cardinalité élevée. Si vous disposez d'une étiquette de ressource et d'une étiquette de métrique qui capturent des informations similaires, utilisez l'étiquette de ressource dans vos requêtes.
Par exemple, si votre ressource surveillée inclut une étiquette cluster et que votre métrique inclut une étiquette kubernetes_cluster_name qui capture des informations similaires, filtrez sur l'étiquette de ressource cluster.
Les étiquettes de métadonnées de ressources sont ajoutées de manière asynchrone aux séries temporelles et ne sont pas soumises aux mêmes attentes de latence que les valeurs des étiquettes définies par les types de métriques ou les types de ressources surveillées. Par conséquent, une règle d'alerte qui dépend des valeurs de métadonnées pour déclencher une action peut se comporter de manière irrégulière si le remplissage des libellés de métadonnées de ressources est retardé.
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 qu'une règle d'alerte ouvre une alerte auprès de votre équipe d'assistance lorsque le champ message d'une entrée de journal contient product_ids=['tier_1_support', 'tier_2_support'].
Pour en savoir plus, consultez Configurer des règles d'alerte basées sur les journaux dans la documentation Logging.
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 les données de vos entrées de journal, puis crée des alertes 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 un niveau de gravité WARNING.
Pour en savoir plus, consultez Surveiller les résultats de vos requêtes SQL avec une règle d'alerte dans la documentation Logging.
Composants d'une règle d'alerte
Chaque règle d'alerte comporte les composants suivants :
Condition qui décrit quand une ressource ou un groupe de ressources se trouve dans un état qui nécessite une réponse de votre part. La condition inclut la source de données, un seuil statique ou dynamique, et des méthodes d'agrégation de données telles que les filtres et groupby. 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 avertir lorsqu'une action est requise. Pour en savoir plus, consultez Créer et gérer des canaux de notification.
Documentation qui s'affiche dans les notifications et les pages d'alerte. Vous pouvez configurer la ligne d'objet d'une notification et ajouter des informations utiles au 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 Annoter des alertes avec une documentation définie par l'utilisateur.
Gérer les règles d'alerte et les alertes
Une fois qu'une règle d'alerte est 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 une mise en veille.
Si une alerte est ouverte et que Monitoring détermine que les conditions de la règle basée sur des métriques ne sont plus remplies, Monitoring ferme automatiquement l'alerte et envoie une notification de fermeture.
Étapes suivantes
Pour en savoir plus sur la latence des notifications et sur l'impact des choix des paramètres d'une règle d'alerte sur l'envoi des notifications, consultez Comportement des règles d'alerte basées sur des métriques.
Pour obtenir une liste d'exemples de règles basées sur des métriques, y compris comment utiliser JSON pour écrire une condition de seuil de métrique qui surveille un ratio de types de métriques, consultez Résumé des exemples de règles d'alerte.