Aperçu des alertes

Ce document explique comment recevoir des notifications lorsque votre application échoue ou lorsque ses performances ne répondent pas aux critères définis.

Fonctionnement des alertes

Le processus d'alerte de Cloud Monitoring comporte trois parties :

  • Une règle d'alerte 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 qui ont provoqué l'incident.

  • Un canal de notification définit comment vous recevez des notifications lorsque Monitoring crée un incident. 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. 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 :

  • Les données de séries temporelles, également appelées données de métriques, qui sont 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 les métriques, essayez le guide de démarrage rapide de Compute Engine.

  • Les 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. Elles vous avertissent lorsqu'un message spécifique apparaît dans vos journaux. Pour en savoir plus, consultez Surveiller vos journaux.

  • Les 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 disponibles en version preview publique.

Le processus d'alerte vous aide à résoudre les 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 intervienne lorsque l' application présente une latence élevée pendant une période prolongée. Vous pouvez créer une règle d'alerte basée sur les métriques 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 un incident et envoie des notifications par e-mail à votre équipe d'assistance.

Comment 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 Google Cloud console. Vous pouvez également configurer une nouvelle règle d'alerte à l'aide de la Google Cloud console, 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 qui vous permettent de créer des règles d'alerte pour vos Google Cloud services et vos intégrations tierces. Ces packages incluent des règles d'alerte recommandées, des exemples de tableaux de bord et des métriques clés pour le service. Ils sont disponibles pour Google Cloud des services tels que Google Kubernetes Engine, Compute Engine et Cloud SQL, ainsi que pour des 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. Lorsque vous activez une règle d'alerte recommandée, vous configurez son canal de notification et vous pouvez éventuellement modifier d'autres valeurs. Une fois configurée, la règle d'alerte commence immédiatement à surveiller sa cible, sans nécessiter d'intervention supplémentaire de l'utilisateur.

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 en échec et les transactions lentes :

Deux des règles d'alerte recommandées pour le package d'intégration Cloud SQL.

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. Les sections suivantes listent 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 de métrique 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 une règle d'alerte qui 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 23,5 heures.

Pour en savoir plus, consultez Créer des règles d'alerte basées sur l'absence de métrique et Créer des règles d'alerte à l'aide de l'API.

Vous souhaitez 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 fenêtre 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 la valeur de métrique prévue et Créer des règles d'alerte à l'aide de l'API.

 Vous souhaitez une règle d'alerte qui ouvre un incident 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.

Surveiller les données d'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 sur 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 le 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 de requêtes SQL

Pour surveiller les résultats de 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 périodiquement 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 dans 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é 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 des règles d'alerte

Chaque règle d'alerte comporte les composants suivants :

  • Une condition qui décrit quand une ressource ou un groupe de ressources se trouve dans un état qui nécessite une intervention 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 des filtres et des 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.

  • Une liste de canaux de notification qui décrivent qui doit être averti lorsqu'une action est requise. Pour en savoir plus, consultez Créer et gérer des canaux de notification.

  • La documentation qui apparaît dans les notifications et les pages d'incident. Vous pouvez configurer l'objet d'une notification et vous pouvez ajouter des informations utiles au corps de la notification. Par exemple, vous pouvez configurer la notification pour afficher des liens vers des guides internes ou vers Google Cloud des pages telles que des tableaux de bord personnalisés. Pour en savoir plus sur la documentation, y compris des exemples, consultez Annoter des incidents avec une documentation définie par l'utilisateur.

Langages de requête

Utilisez le langage de requête Prometheus (PromQL) et des filtres dans vos règles d'alerte pour mieux contrôler l'évaluation de vos métriques. Monitoring est compatible avec les types de requêtes suivants :

  • 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 leur condition. Vos requêtes PromQL peuvent utiliser n'importe quelle expression valide, telle que des combinaisons de métriques, des ratios et des seuils de scaling. En configurant des règles d'alerte basées 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 PromQL dans Cloud Monitoring et Présentation des alertes PromQL.

  • Les filtres Monitoring 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 affichées ni modifiées dans la Google Cloud console. Pour obtenir un exemple de règle utilisant des filtres Monitoring, consultez Ratio de métriques.

Gérer les règles d'alerte et les incidents

Une fois la 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 période donnée, créez une mise en veille.

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

Pour en savoir plus sur les tarifs de Cloud Monitoring, consultez la page Tarifs de Google Cloud Observability.

Pour savoir comment surveiller le nombre de délais de trace ou de journaux ingérés, ou comment être averti lorsqu'un contenu spécifique est inclus dans une entrée de journal, consultez les documents suivants :

Étape suivante