Surveiller les résultats de vos requêtes SQL avec une règle d'alerte

Ce document explique comment créer une règle d'alerte pour surveiller les résultats d'une requête que vous exécutez dans Observability Analytics. Ces requêtes sont écrites en SQL et elles doivent interroger une vue de journal. La règle d'alerte vous avertit lorsque le résultat de la requête remplit les conditions que vous spécifiez. Par exemple, vous pouvez configurer une règle d'alerte pour être averti lorsqu'au moins 25% des entrées de journal d'une certaine période ont une gravité ERROR.

Les règles d'alerte que vous créez à partir de la page Observability Analytics s'exécutent sur un moteur BigQuery. Par conséquent, les données interrogées doivent être accessibles via un ensemble de données BigQuery associé. Pour cette raison, ces requêtes SQL ne peuvent interroger que des vues de journal. Elles ne peuvent pas interroger des vues analytiques.

Pour obtenir des informations générales sur Observability Analytics, consultez Interroger et analyser des journaux avec Observability Analytics.

Fonctionnement des règles d'alerte

Une règle d'alerte décrit les circonstances dans lesquelles vous souhaitez être averti d'un incident et de quelle manière. Vous pouvez utiliser trois approches différentes pour être averti lorsque du contenu ou des modèles apparaissent dans vos données de journal :

  • Pour analyser des entrées de journal individuelles à la recherche d'une expression spécifique, créez une règle d'alerte basée sur les journaux. Utilisez ces règles d'alerte lorsque vous souhaitez être averti d'événements liés à la sécurité, par exemple.

  • Pour surveiller les événements dans les données de vos entrée de journal, vous pouvez créer une métrique basée sur les journaux, puis créer une règle d'alerte pour surveiller la métrique. Ces types de règles d'alerte sont efficaces lorsque vous souhaitez surveiller les tendances dans les données des entrée de journal au fil du temps. Toutefois, elles ne sont pas aussi efficaces si vous n'attendez que quelques événements.

  • Pour surveiller l'analyse agrégée des données de vos entrée de journal, combinez Observability Analytics avec des règles d'alerte. Dans ce scénario, vous mettez à niveau un bucket de journaux pour utiliser Observability Analytics et créez un ensemble de données BigQuery associé pour ce bucket de journaux. Ensuite, vous utilisez Observability Analytics, qui est compatible avec les requêtes SQL, pour interroger une vue de journal sur le bucket de journaux. Enfin, vous créez la règle d'alerte pour surveiller les résultats de la requête SQL. Ce type de règle d'alerte est appelé règle d'alerte basée sur SQL.

Les règles d'alerte basées sur SQL sont plus efficaces pour évaluer des valeurs exactes sur plusieurs entrées de journal. Si vous souhaitez évaluer des entrées de journal individuelles, créez une règle d'alerte basée sur les journaux.

Le reste de ce document explique comment utiliser des règles d'alerte basées sur SQL.

Composants des règles d'alerte

Une règle d'alerte basée sur SQL contient une condition et une planification :

  • La condition contient la requête, qui est une requête SQL qui interroge vos données. La condition définit également les circonstances dans lesquelles le résultat de la requête amène Monitoring à créer un incident.

  • La planification définit la fréquence à laquelle la règle d'alerte exécute sa requête. La planification définit également la taille de la période d'analyse, qui est un filtre qui ne sélectionne que les données reçues depuis la dernière évaluation de la requête. Par exemple, si vous définissez la planification sur 60 minutes, la requête est exécutée toutes les 60 minutes à l'aide d'une période d'analyse qui sélectionne les 60 minutes de données les plus récentes.

Les règles d'alerte contiennent également une liste de canaux de notification. Lorsque la condition de la règle d'alerte est remplie, Cloud Monitoring crée un incident, puis envoie des notifications à son sujet via ces canaux. Un incident est un enregistrement des données qui ont entraîné le respect de la condition, ainsi que d'autres informations pertinentes. Ces informations peuvent vous aider à résoudre les problèmes qui ont provoqué l'incident. Vous pouvez afficher l'incident à l'aide de la Google Cloud console.

Types d'évaluation pour les règles d'alerte basées sur SQL

Les conditions qui surveillent un résultat de requête SQL sont compatibles avec deux types d'évaluation :

  • Seuil du nombre de lignes : la condition est remplie lorsque le nombre de lignes dans le résultat de la requête est supérieur, égal ou inférieur à une valeur seuil.

    Supposons, par exemple, que vous souhaitiez être averti lorsque plus de 50 entrées de journal de la période d'analyse ont une gravité supérieure à 200. Vous créez une requête qui signale les entrées de journal dont la gravité est supérieure à 200. Vous configurez ensuite une condition, sélectionnez le Seuil du nombre de lignes et définissez le seuil sur 50.

  • Booléen : la condition est remplie lorsqu'une colonne booléenne spécifique du tableau de résultats de la requête contient une ligne avec la valeur true.

    Supposons, par exemple, que vous souhaitiez être averti lorsque plus de 25% des entrées de journal de la période d'analyse ont une gravité ERROR. Vous créez une requête qui calcule le pourcentage d'entrées de journal dont le niveau de gravité est ERROR. Les résultats de la requête écrivent true dans la colonne notify lorsque ce pourcentage dépasse 25%. Ensuite, vous créez une condition, définissez le type sur Booléen et configurez la condition pour surveiller la notify colonne.

Les règles d'alerte qui surveillent un résultat de requête SQL ne doivent comporter qu'une seule condition.

Règles d'alerte et BigQuery

Pour qu'une règle d'alerte interroge vos données de journal, vous devez configurer un ensemble de données BigQuery associé. Les ensembles de données associés permettent à BigQuery de lire vos données de journal et d'exécuter des fonctions BigQuery sur les données renvoyées par votre requête SQL.

Lorsqu'une règle d'alerte exécute une requête SQL, cette requête est exécutée sur le moteur BigQuery dans le Google Cloud projet où la règle d'alerte est définie. Par défaut, les requêtes exécutées sur le moteur BigQuery utilisent des emplacements à la demande. Les emplacements à la demande et les emplacements réservés sont soumis aux tarifs de BigQuery.

Vous pouvez également choisir de configurer des réservations d'emplacement BigQuery dédiées pour votre projet :

  1. Créez une réservation avec des emplacements dédiés ou identifiez une réservation existante.
  2. Créez des attributions de réservation pour votre projet.

Entrées de journal évaluées

Pour qu'une entrée de journal soit évaluée par la requête SQL d'une règle d'alerte, les deux conditions suivantes doivent être remplies :

  • L'horodatage de réception de l'entrée de journal, qui enregistre le moment où l'entrée de journal a été reçue par Cloud Logging, doit se trouver dans la période d'analyse de la règle d'alerte.
  • L'horodatage de l'entrée de journal, qui enregistre le moment où l'entrée de journal a été générée, doit se trouver dans les 15 minutes de la période d'analyse.

Par exemple, votre règle d'alerte basée sur SQL a une période d'analyse de 60 minutes. Observability Analytics exécute la requête SQL de la règle d'alerte à 13h30. Pour être incluse dans la requête, une entrée de journal doit correspondre aux deux critères suivants :

  • L'horodatage de réception doit être compris entre 12h30 et 13h30.
  • L'horodatage doit être compris entre 12h15 et 13h45.

Lorsque vous exécutez une requête à partir de l'interface Observability Analytics, toutes les entrées de journal de la plage de dates sélectionnée sont évaluées en fonction de l'horodatage de l'entrée de journal.

Période d'analyse et délai de propagation des incidents

Lorsqu'une règle d'alerte est programmée pour évaluer sa condition, Observability Analytics retarde l'exécution de la requête SQL de cinq minutes pour laisser le temps à Cloud Logging d'indexer les données reçues pendant la période d'analyse. Par exemple, si la règle d'alerte utilise une période d'analyse qui se termine à 14h00, Observability Analytics n'exécute la requête SQL qu'à 14h05.

Si la condition d'alerte est remplie après l'exécution de la requête, la propagation de l'incident dans le système peut prendre jusqu'à deux minutes supplémentaires.

Échecs de requête

Les requêtes émises par des règles d'alerte basées sur SQL peuvent échouer pour diverses raisons, y compris les suivantes :

  • Le compte de service Monitoring n'existe plus ou ne dispose plus des autorisations nécessaires pour lire les données de journal interrogées.

  • Le délai d'exécution de la requête dépasse cinq minutes.

  • Une erreur interne se produit.

Une requête ayant échoué génère une entrée de journal contenant l'ID de la règle d'alerte et l'état de l'erreur. Vous pouvez utiliser une règle d'alerte basée sur les journaux pour créer une alerte lorsqu'une erreur est enregistrée.

Avant de commencer

Cette section suppose que vous avez mis à niveau votre bucket de journaux pour utiliser Observability Analytics et que vous pouvez interroger et afficher vos données de journal à l'aide de la page Observability Analytics. Elle suppose également que vous avez déjà créé un ensemble de données BigQuery associé pour votre bucket de journaux.

Avant de créer une règle d'alerte basée sur SQL, procédez comme suit :

  1. Pour obtenir les autorisations dont vous avez besoin pour créer et gérer des règles d'alerte basées sur SQL, demandez à votre administrateur de vous accorder les rôles IAM suivants :

  2. Vérifiez que le compte de service Monitoring existe et qu'il dispose des rôles suivants :

    1. Agent de service Monitoring (roles/monitoring.notificationServiceAgent) sur votre projet.
    2. Lecteur de données BigQuery (roles/bigquery.dataViewer) sur votre ensemble de données associé

    Si le compte de service Monitoring n'existe pas, consultez Résoudre les problèmes : aucun compte de service Monitoring.

  3. Configurez les canaux de notification que vous souhaitez utiliser pour recevoir les notifications d'incidents. À des fins de redondance, nous vous recommandons de créer plusieurs types de canaux de notification. Pour en savoir plus, consultez Créer et gérer des canaux de notification.

Créer une règle d'alerte basée sur SQL

Pour créer une règle d'alerte basée sur SQL, procédez comme suit :

Console

  1. Dans la Google Cloud console, accédez à la Observability Analytics page :

    Accéder à Observability Analytics

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

  2. Sur la page Observability Analytics, dans l'éditeur de requête, saisissez une requête SQL qui interroge vos données de journal.

    Pour en savoir plus sur l'écriture de requêtes SQL pour les vues de journal, consultez Interroger une vue de journal.

  3. Dans la barre d'outils, cliquez sur Exécuter sur BigQuery.

    Observability Analytics exécute votre requête sur le moteur BigQuery et affiche les résultats dans le tableau Résultats.

    Si Exécuter sur BigQuery ne s'affiche pas, cliquez sur Sélectionner le moteur de requête puis sur BigQuery. Le bouton Exécuter la requête devient Exécuter sur BigQuery.

  4. Dans le tableau Résultats de la page Observability Analytics, cliquez sur  Créer une alerte.

    La page Observability Analytics affiche la fenêtre Créer une règle d'alerte SQL, qui affiche votre requête dans la section Requête SQL.

  5. Dans la section Condition d'alerte , configurez la condition et la planification de votre règle d'alerte.

  6. Configurez les détails de l'alerte de votre règle d'alerte.

    1. Ajoutez des canaux de notification et configurez le contenu des notifications, par exemple une ligne d'objet personnalisée.

    2. Facultatif : ajoutez des libellés et de la documentation à la règle d'alerte.

    3. Cliquez sur Suivant.

  7. Examinez votre règle d'alerte, puis créez-la en cliquant sur Enregistrer.

Terraform

  1. Installez et configurez Terraform pour votre projet. Pour les configurations App Hub, sélectionnez le projet hôte App Hub ou le projet de gestion.

  2. Dans Cloud Shell, accédez au répertoire contenant votre configuration Terraform.

  3. Dans votre configuration Terraform, configurez une instance de la google_monitoring_alert_policy, y compris condition_sql.

  4. Dans Cloud Shell, saisissez terraform apply.

Pour modifier votre règle d'alerte, apportez vos modifications, puis réappliquez la configuration Terraform. Pour en savoir plus, consultez Gérer les règles d'alerte avec Terraform.

Pour obtenir des informations générales sur l'utilisation de Google Cloud avec Terraform, consultez Terraform avec Google Cloud.

REST

Utilisez la alertPolicies.create méthode pour créer des règles d'alerte par programmation. Le Condition type de votre règle d'alerte doit être MonitoringQueryLanguageCondition, qui est une instance de SqlCondition. Ce type de condition permet de définir les conditions de votre règle d'alerte avec SQL.

Pour définir la planification, définissez une valeur periodicity pour l'un des champs minutes, hours ou days. Par exemple, si vous souhaitez que la requête s'exécute toutes les 12 heures, définissez la périodicité du champ hours sur 12.

Pour définir la condition, utilisez les champs suivants :

  • boolean_test: configure la règle d'alerte de sorte que sa condition soit remplie lorsqu'une ligne d'une colonne booléenne du tableau de résultats de la requête contient une valeur "true".
  • row_count_test: configure la règle d'alerte de sorte que sa condition soit remplie lorsque le nombre de lignes dans le tableau de résultats de la requête atteint un certain seuil.

Pour obtenir la liste complète des champs et des définitions, consultez SqlCondition dans la documentation de l'API Cloud Monitoring.

Pour plus d'informations sur l'API Monitoring pour les règles d'alerte, consultez la page Gérer des règles d'alerte à l'aide d'API.

Limites

  • Vous ne pouvez avoir qu'une seule condition par règle d'alerte basée sur SQL.
  • Les règles d'alerte basées sur SQL ne peuvent pas interroger une vue analytique.

  • Les requêtes émises par des règles d'alerte basées sur SQL échouent lorsque leur délai d'exécution dépasse cinq minutes.

  • Il existe un délai de sept minutes maximum, plus le délai d'exécution de la requête, entre le moment où une requête est programmée et celui où un incident est créé.

Pour obtenir la liste complète des limites associées aux règles d'alerte, consultez Limites de Monitoring.

Tarifs

Pour en savoir plus sur les tarifs, consultez les documents suivants :

Étape suivante