Aperçu des alertes

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

Fonctionnement des alertes

Le processus d'alerte de Cloud Monitoring se compose de trois parties:

  • Une règle d'alerte, qui décrit les circonstances dans lesquelles vous souhaitez être alerté et la manière dont vous voulez être informé d'un incident. La règle d'alerte 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 répondent à la condition de 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ée 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.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 deux 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ées règles d'alerte basées sur des 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.

  • Données de journaux stockées par Cloud Logging. Ces types de règles sont appelées règles d'alerte basées sur les journaux. Les règles d'alerte basées sur les journaux vous informent lorsqu'un message particulier apparaît dans vos journaux.

    Ce document porte sur les règles d'alerte basées sur les métriques, avec des informations générales sur les règles d'alerte basées sur les journaux, le cas échéant. Pour plus d'informations sur les règles d'alerte basées sur les journaux, consultez la section Surveiller vos journaux.

Le processus d'alerte vous aide à répondre aux problèmes lorsque les performances d'une application ne parviennent pas à atteindre des valeurs acceptables. Par exemple, vous pouvez déployer 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 fluctue, il est préférable 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 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.

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 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. 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. 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 comme 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. Après la configuration, la règle d'alerte commence à surveiller sa cible immédiatement, sans aucune autre action de l'utilisateur requise.

Les règles d'alerte recommandées sont utiles lorsque vous avez déployé un nouveau service et souhaitez être averti sur des métriques importantes. Par exemple, le package d'intégration Cloud SQL contient des alertes recommandées pour les instances ayant échoué et les transactions lentes:

Deux des alertes recommandées pour le package d'intégration Cloud SQL.

Pour en savoir plus sur les intégrations d'alertes, consultez Surveiller des applications tierces.

Utilisez Cloud Monitoring

Si vous souhaitez créer une règle d'alerte et choisir son type de condition avec d'autres composants tels que le type de métrique et les séries temporelles, utilisez Monitoring. Le tableau suivant répertorie les différents types de conditions que vous pouvez utiliser lorsque vous créez une règle d'alerte.

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 temps spécifique.

Pour en savoir plus, consultez Créer des règles d'alerte par 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 d'au moins 500 ms pendant cinq tests de disponibilité consécutifs de plus 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 pendant un intervalle de temps spécifique. Elle peut atteindre 24 heures si vous créez votre condition dans la console Google Cloud ou 24,5 heures dans l'API Cloud Monitoring.

Pour en savoir plus, consultez 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 qu'une règle d'alerte ouvre un incident à votre équipe d'assistance lorsqu'une ressource ne répond à aucune requête HTTP dans un délai de cinq minutes.
Condition de valeur de métrique prévue

Les conditions prévues pour les valeurs de métriques sont remplies lorsque la règle d'alerte prévoit que le seuil sera dépassé dans la période 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 pour les métriques basées sur les prévisions et Créer des règles d'alerte à l'aide de l'API.

 Vous souhaitez qu'une règle d'alerte ouvre un incident à votre équipe d'assistance lorsqu'une ressource est susceptible d'atteindre 80% de l'espace disque utilisé dans les prochaines 24 heures.
Condition 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 métrique basée sur les journaux correspond aux critères de la règle d'alerte. Les métriques basées sur les journaux extraient les données de métriques du contenu des entrées de journal. Par exemple, vous pouvez utiliser une métrique basée sur les journaux pour compter le nombre d'entrées de journal contenant un message particulier ou pour extraire les informations de latence enregistrées dans les entrées de journal.

Pour en savoir plus, consultez Configurer des alertes basées sur les journaux et Créer une alerte basée sur les journaux à l'aide de l'API Monitoring.

 Vous souhaitez qu'une règle d'alerte ouvre un incident à votre équipe d'assistance lorsque votre projet comporte au moins 50 entrées de journal avec un message contenant product_ids=['tier_1_support', 'tier_2_support'].

Composants des règles d'alerte

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

  • Une condition qui décrit le moment où une ressource ou un groupe de ressources est 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 des données telles que les périodes d'analyse, 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 des langages de requête tels que PromQL et Monitoring Query Language (MQL) pour inclure des expressions complexes telles que les seuils dynamiques et la 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 de canaux de notification décrivant les personnes à avertir lorsqu'une action est requise. Pour en savoir plus, consultez Créer et gérer des canaux de notification.

  • Documentation qui apparaît 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 et obtenir des exemples, consultez Annoter les alertes avec la 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 des métriques. Monitoring accepte les types de requêtes suivants:

  • Le langage de requête Prometheus (PromQL) est un langage de requête fonctionnel qui permet d'évaluer en temps réel les données de séries temporelles. Vous pouvez configurer des conditions de règle d'alerte pour inclure une requête PromQL dans leurs conditions. 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 avec une condition basée sur PromQL dans Google Cloud, vous pouvez réduire les dépendances sur l'infrastructure d'alerte externe. Pour en savoir plus, consultez les pages PromQL dans Cloud Monitoring et Règles d'alerte avec PromQL.

  • Le langage MQL (Monitoring Query Language) est une interface textuelle expressive qui vous permet de récupérer, de filtrer et de 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 Monitoring Query Language. Pour en savoir plus, consultez les pages Présentation du langage de requête Monitoring et Règles d'alerte avec MQL.

  • Les filtres de surveillance permettent de configurer des règles d'alerte pour utiliser des ratios de métriques basés sur des filtres. Il n'est pas possible d'afficher ni de modifier les règles d'alerte basées sur des filtres dans la console Google Cloud. Pour obtenir un exemple de règle utilisant des filtres Monitoring, consultez la section Ratio de métriques.

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

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 qu'elle surveille les conditions seulement pour certaines périodes. Si vous souhaitez désactiver la règle d'alerte pendant une certaine période, créez une mise en pause.

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 de clôture.

Tarification

En général, les métriques système de Cloud Monitoring sont gratuites, contrairement aux métriques 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 les tarifs de Cloud Monitoring, consultez les documents suivants:

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

Étapes suivantes