Configuration d’alertes basées sur des données dans Snowflake¶

Introduction¶

Dans certains cas, vous pouvez souhaiter être informé ou prendre des mesures lorsque les données contenues dans Snowflake remplissent certaines conditions. Par exemple, il se peut que vous vouliez recevoir une notification quand :

• L’utilisation du crédit d’entrepôt augmente d’un certain pourcentage de votre quota actuel déterminé.

• La consommation de ressources pour vos pipelines, tâches, vues matérialisées, etc. augmente au-delà d’un certain montant.

• Vos données ne sont pas conformes à une règle de gestion particulière que vous avez mise en place.

Pour ce faire, vous pouvez configurer une alerte Snowflake. Une alerte Snowflake est un objet de niveau schéma qui spécifie :

• Une condition qui déclenche l’alerte (par exemple, la présence de requêtes qui prennent plus d’une seconde pour se terminer).

• L’action à exécuter lorsque la condition est remplie (par exemple, envoyer une notification par e-mail, saisir des données dans un tableau, etc.)

• Quand et à quelle fréquence la condition doit être évaluée (par exemple, toutes les 24 heures, tous les dimanches à minuit, etc.)

Par exemple, supposons que vous souhaitiez envoyer une notification par e-mail lorsque la consommation de crédit dépasse une certaine limite pour un entrepôt. Supposons que vous vouliez vérifier cela toutes les 30 minutes. Vous pouvez créer une alerte avec les propriétés suivantes :

• Condition : la consommation de crédit pour un entrepôt (la somme de la colonne credits_used dans la vue WAREHOUSE_METERING_HISTORY dans le schéma ACCOUNT_USAGE) dépasse une limite spécifiée.

• Action : envoyer un e-mail à l’administrateur.

• Fréquence / horaire : vérifier cette condition toutes les 30 minutes.

Choix du type d’alerte¶

Vous pouvez créer les types d’alertes suivants :

• Alerte sur une planification : Snowflake évalue la condition par rapport aux données existantes sur une base planifiée.

  Par exemple, vous pouvez paramétrer une alerte sur une planification pour vérifier si l’une des lignes existantes d’une table a une valeur de colonne qui dépasse un montant spécifié.

• Alerte sur les nouvelles données : Snowflake évalue la condition par rapport à toute nouvelle ligne dans une table ou une vue spécifiée.

  Par exemple, vous pouvez configurer une alerte sur les nouvelles données pour vous avertir lorsque de nouvelles lignes de messages d’erreur sont insérées dans la table d’événements pour votre compte. Étant donné que les rafraîchissements de tables dynamiques et les exécutions de tâches connectent des événements à la table des événements, vous pouvez établir un paramètre d’alerte en cas de nouvelles données :

  • Surveiller les actualisations de la table dynamique.

  • Contrôler l’exécution des tâches.

Choix de l’entrepôt pour les alertes¶

Une alerte nécessite un entrepôt pour être exécutée. Vous pouvez utiliser le modèle de calcul sans serveur ou un entrepôt virtuel que vous spécifiez.

Compréhension du coût des alertes¶

Les coûts associés à l’exécution d’une alerte pour exécuter du code SQL varient en fonction des ressources de calcul utilisées pour l’alerte :

• Pour les alertes sans serveur, Snowflake facture votre compte en fonction de l’utilisation des ressources de calcul. Les frais sont calculés sur la base de votre utilisation totale des ressources, y compris l’utilisation du service Cloud, mesurée en heures de calcul d’utilisation du crédit. Le coût en heures de calcul varie en fonction de la taille de l’entrepôt et de la durée d’exécution de la requête. Pour plus d’informations, voir Utilisation du crédit sans serveur.

  Pour savoir combien de crédits sont consommés par des alertes, reportez-vous au « Tableau des crédits de fonctionnalité sans serveur » dans la Table de consommation du service Snowflake.

  Pour voir l’historique d’utilisation des alertes sans serveur, vous pouvez :

  • Appelez la fonction SERVERLESS_ALERT_HISTORY.

  • Interroger Vue SERVERLESS_ALERT_HISTORY.

• Pour les alertes qui utilisent un entrepôt virtuel que vous spécifiez, Snowflake facture votre compte pour l’utilisation du crédit en fonction de l’utilisation de l’entrepôt lorsqu’une alerte est en cours. Cette utilisation est similaire à celle de l’entrepôt pour l’exécution des mêmes instructions SQL dans un client ou Snowsight. La facturation à la seconde et la suspension automatique du crédit vous permettent de commencer avec des tailles d’entrepôts plus grandes, puis d’ajuster la taille en fonction de vos charges de travail d’alertes.

Attribution de privilèges pour créer des alertes¶

Afin de créer une alerte, vous devez utiliser un rôle qui dispose des privilèges suivants :

• Le privilège EXECUTEALERT sur le compte.

  Note

  Ce privilège ne peut être accordé que par un utilisateur ayant le rôle ACCOUNTADMIN.

• Un des privilèges suivants :

  • Le privilège EXECUTE MANAGED ALERT sur le compte, si vous créez une alerte sans serveur.

  • Le privilège USAGE sur l’entrepôt utilisé pour exécuter l’alerte, si vous spécifiez un entrepôt virtuel pour l’alerte.

• Les privilèges USAGE et CREATE ALERT sur le schéma dans lequel vous voulez créer l’alerte.

• Le privilège USAGE sur la base de données contenant le schéma.

• Le privilège SELECT sur la table ou la vue que vous voulez interroger dans la condition d’alerte (si vous créez une alerte sur de nouvelles données).

Pour accorder ces privilèges à un rôle, utilisez la commande GRANT <privilèges> … TO ROLE.

Par exemple, supposons que vous souhaitiez créer un rôle personnalisé nommé my_alert_role qui dispose des privilèges nécessaires pour créer une alerte dans le schéma nommé my_schema. Vous voulez que l’alerte utilise l’entrepôt my_warehouse.

Pour ce faire :

1. Demandez à un utilisateur ayant le rôle ACCOUNTADMIN de faire ce qui suit :

   1. Créez le rôle personnalisé.

      Par exemple :

      CopyExpand

      USE ROLE ACCOUNTADMIN;
      
      CREATE ROLE my_alert_role;
      

      Show lessSee more

      Scroll to top

   2. Accordez le privilège global EXECUTE ALERT à ce rôle personnalisé.

      Par exemple :

      CopyExpand

      GRANT EXECUTE ALERT ON ACCOUNT TO ROLE my_alert_role;
      

      Show lessSee more

      Scroll to top

   3. Si vous souhaitez créer une alerte sans serveur, accordez le privilège global EXECUTE MANAGED ALERT à ce rôle personnalisé.

      Par exemple :

      CopyExpand

      GRANT EXECUTE MANAGED ALERT ON ACCOUNT TO ROLE my_alert_role;
      

      Show lessSee more

      Scroll to top

   4. Attribuez le rôle personnalisé à un utilisateur.

      Par exemple :

      CopyExpand

      GRANT ROLE my_alert_role TO USER my_user;
      

      Show lessSee more

      Scroll to top

2. Demandez aux propriétaires de la base de données, du schéma et de l’entrepôt d’accorder les privilèges nécessaires à la création de l’alerte pour le rôle personnalisé :

   • Le propriétaire du schéma doit accorder les privilèges CREATE ALERT et USAGE sur le schéma :

     CopyExpand

     GRANT CREATE ALERT ON SCHEMA my_schema TO ROLE my_alert_role;
     GRANT USAGE ON SCHEMA my_schema TO ROLE my_alert_role;
     

     Show lessSee more

     Scroll to top

   • Le propriétaire de la base de données doit accorder le privilège USAGE sur la base de données :

     CopyExpand

     GRANT USAGE ON DATABASE my_database TO ROLE my_alert_role;
     

     Show lessSee more

     Scroll to top

   • Si vous voulez spécifier un entrepôt pour l’alerte, le propriétaire de cet entrepôt doit accorder le privilège USAGE sur l’entrepôt :

     CopyExpand

     GRANT USAGE ON WAREHOUSE my_warehouse TO ROLE my_alert_role;
     

     Show lessSee more

     Scroll to top

Création d’une alerte¶

Les sections suivantes présentent les étapes de base et un exemple de création de différents types d’alertes :

• Création d’une alerte sur une planification

• Création d’une alerte sur de nouvelles données

Transmettre la configuration à une alerte¶

Vous pouvez enregistrer une configuration JSON dans une alerte et la lire lors de l’exécution, tant dans la condition (IF) que dans l’action (THEN) SQL. Cela vous permet de paramétrer la logique d’alerte (par exemple, les seuils, les cibles de notification ou les indicateurs de fonctionnalité) sans modifier les instructions SQL de l’alerte directement.

CREATE OR REPLACE ALERT my_metric_threshold_alert
  WAREHOUSE = my_alert_wh
  SCHEDULE = '5 MINUTE'
  CONFIG = $${
    "enabled": true,
    "threshold": 10,
    "notify": "ops"
  }$$
  IF( EXISTS(
    SELECT 1
      FROM my_db.my_schema.my_source_table
      WHERE COALESCE(TRY_TO_BOOLEAN(SYSTEM$GET_ALERT_CONFIG('enabled')), FALSE)
        AND metric_value > COALESCE(
          TRY_TO_NUMBER(SYSTEM$GET_ALERT_CONFIG('threshold')), 0)
  ))
  THEN
    INSERT INTO my_db.my_schema.my_output_table
      SELECT CURRENT_TIMESTAMP(), SYSTEM$GET_ALERT_CONFIG('notify');

ALTER ALERT my_metric_threshold_alert SET
  CONFIG = $${
    "enabled": true,
    "threshold": 25,
    "notify": "oncall"
  }$$;

CREATE OR REPLACE ALERT my_tasks_error_rate_alert
  WAREHOUSE = my_alert_wh
  SCHEDULE = '1 MINUTE'
  CONFIG = $${
    "ERROR_RATE_THRESHOLD": 0.05,
    "TASK_SCOPE": "ETL_",
    "SCOPE": "DATABASE",
    "DATABASE": "my_db"
  }$$
  IF( EXISTS(
    WITH cfg AS (
      SELECT
        COALESCE(TRY_TO_NUMBER(
          SYSTEM$GET_ALERT_CONFIG('ERROR_RATE_THRESHOLD')), 0.05)
          AS error_rate_threshold,
        COALESCE(SYSTEM$GET_ALERT_CONFIG('TASK_SCOPE')::STRING, '')
          AS task_scope,
        COALESCE(SYSTEM$GET_ALERT_CONFIG('DATABASE')::STRING, '')
          AS scope_database
    ),
    task_window AS (
      SELECT *
        FROM TABLE(
          INFORMATION_SCHEMA.TASK_HISTORY(
            SCHEDULED_TIME_RANGE_START =>
              SNOWFLAKE.ALERT.LAST_SUCCESSFUL_SCHEDULED_TIME()
          )
        )
        WHERE DATABASE_NAME = (SELECT scope_database FROM cfg)
          AND NAME ILIKE (SELECT task_scope FROM cfg) || '%'
    ),
    agg AS (
      SELECT
        COUNT(*) AS total_runs,
        COUNT_IF(STATE = 'FAILED') AS failed_runs
        FROM task_window
    )
    SELECT 1
      FROM agg, cfg
      WHERE total_runs > 0
        AND failed_runs / total_runs::FLOAT > error_rate_threshold
  ))
  THEN
    CALL my_db.my_schema.handle_task_alert(
      PARSE_JSON(SYSTEM$GET_ALERT_CONFIG())
    );

CONFIG = $${
  "ERROR_RATE_THRESHOLD": {
    "description": "Trigger alert when cumulative task error rate exceeds this threshold (0.0 - 1.0).",
    "value": 0.1
  },
  "NOTIFICATION": {
    "EMAIL": {
      "recipients": ["alerts@example.com"],
      "value": "my_email_int"
    },
    "WEBHOOK": {
      "value": ""
    },
    "notification_value": {
      "active": "EMAIL",
      "options": ["EMAIL", "WEBHOOK"]
    }
  },
  "SCOPE": {
    "DATABASE": { "value": "my_db" },
    "SCHEMA": { "value": "" },
    "scope_value": {
      "active": "DATABASE",
      "options": ["ACCOUNT", "DATABASE", "SCHEMA"]
    }
  },
  "TASK_NAME_FILTER": {
    "description": "Optional filter pattern to scope alert to specific tasks. Leave empty for all tasks.",
    "value": "ETL_"
  }
}$$

Spécification des horodatages basés sur les planifications d’alerte¶

Dans certains cas, vous pouvez avoir besoin de définir une condition ou une action basée sur le programme d’alerte.

Par exemple, supposons qu’une table possède une colonne d’horodatage qui représente le moment où une ligne a été ajoutée, et que vous souhaitez envoyer une alerte si de nouvelles lignes ont été ajoutées entre la dernière alerte évaluée avec succès et l’alerte programmée actuelle. En d’autres termes, vous voulez évaluer :

<now> - <last_execution_of_the_alert>

Si vous utilisez CURRENT_TIMESTAMP et l’heure prévue de l’alerte pour calculer cette plage de temps. La plage calculée ne tient pas compte de la latence entre l’heure à laquelle l’alerte est prévue et l’heure à laquelle la condition d’alerte est effectivement évaluée.

Au lieu de cela, lorsque vous avez besoin des horodatages de l’alerte programmée actuelle et de la dernière alerte qui a été évaluée avec succès, utilisez les fonctions suivantes :

• SCHEDULED_TIME renvoie l’horodatage représentant la date à laquelle l’alerte actuelle a été programmée.

• LAST_SUCCESSFUL_SCHEDULED_TIME renvoie l’horodatage représentant la date à laquelle la dernière alerte évaluée avec succès a été programmée.

Ces fonctions sont définies dans le schéma SNOWFLAKE.ALERT. Pour appeler ces fonctions, vous devez utiliser un rôle possédnant le SNOWFLAKE.ALERT_VIEWERrôle de la base de données. Pour accorder ce rôle à un autre rôle, utilisez la commande GRANT DATABASE ROLE. Par exemple, pour accorder ce rôle au rôle personnalisé alert_role, exécutez :

GRANT DATABASE ROLE SNOWFLAKE.ALERT_VIEWER TO ROLE alert_role;

L’exemple suivant envoie un message électronique si de nouvelles lignes ont été ajoutées à my_table entre le moment où la dernière alerte évaluée avec succès a été programmée et le moment où l’alerte actuelle a été programmée :

CREATE OR REPLACE ALERT alert_new_rows
  WAREHOUSE = my_warehouse
  SCHEDULE = '1 MINUTE'
  IF (EXISTS (
      SELECT *
      FROM my_table
      WHERE row_timestamp BETWEEN SNOWFLAKE.ALERT.LAST_SUCCESSFUL_SCHEDULED_TIME()
       AND SNOWFLAKE.ALERT.SCHEDULED_TIME()
  ))
  THEN CALL SYSTEM$SEND_EMAIL(...);

Vérification des résultats de l’instruction SQL pour la condition de l’action d’alerte¶

Dans l’action d’une alerte, si vous devez vérifier les résultats de l’instruction SQL pour la condition :

1. Appelez la fonction GET_CONDITION_QUERY_UUID pour obtenir l’ID de la requête pour l’instruction SQL de la condition.

2. Transmettez l’ID de la requête à la fonction RESULT_SCAN pour obtenir les résultats de l’exécution de l’instruction SQL.

Par exemple :

CREATE ALERT my_alert
  WAREHOUSE = my_warehouse
  SCHEDULE = '1 MINUTE'
  IF (EXISTS (
    SELECT * FROM my_source_table))
  THEN
    BEGIN
      LET condition_result_set RESULTSET :=
        (SELECT * FROM TABLE(RESULT_SCAN(SNOWFLAKE.ALERT.GET_CONDITION_QUERY_UUID())));
      ...
    END;

Exécution manuelle des alertes¶

Dans certains cas, il se peut que vous deviez exécuter une alerte manuellement. Par exemple :

• Si vous créez une nouvelle alerte, vous voudrez peut-être vérifier que l’alerte fonctionne comme prévu.

• Il se peut que vous souhaitiez exécuter l’alerte à un point précis de votre pipeline de données. Par exemple, vous pourriez vouloir exécuter l’alerte à la fin de l’appel d’une procédure stockée.

Pour exécuter une alerte manuellement, exécutez la commande EXECUTE ALERT:

EXECUTE ALERT my_alert;

La commande EXECUTE ALERT déclenche manuellement l’exécution unique d’une alerte, indépendamment de la programmation définie pour l’alerte.

Vous pouvez exécuter cette commande de manière interactive. Vous pouvez également exécuter cette commande à partir d’une procédure stockée ou d’un bloc de script Snowflake.

Pour plus de détails sur les privilèges requis pour exécuter cette commande et sur l’effet de cette commande sur les alertes suspendues, en cours d’exécution et programmées, consultez EXECUTE ALERT.

Suspension et reprise d’une alerte¶

Si vous devez empêcher l’exécution temporaire d’une alerte, vous pouvez la suspendre en exécutant la commande ALTER ALERT … SUSPEND. Par exemple :

ALTER ALERT my_alert SUSPEND;

Pour reprendre une alerte suspendue, exécutez la commande ALTER ALERT … RESUME. Par exemple :

ALTER ALERT my_alert RESUME;

Modification d’une alerte¶

Pour modifier les propriétés d’une alerte, exécutez la commande ALTER ALERT.

Par exemple :

• Pour changer l’entrepôt de l’alerte nommée my_alert en my_other_warehouse, exécutez :

  CopyExpand

  ALTER ALERT my_alert SET WAREHOUSE = my_other_warehouse;
  

  Show lessSee more

  Scroll to top

• Pour modifier le programme de l’alerte nommée my_alert afin qu’elle soit évaluée toutes les 2 minutes, exécutez :

  CopyExpand

  ALTER ALERT my_alert SET SCHEDULE = '2 minutes';
  

  Show lessSee more

  Scroll to top

• Pour modifier la condition de l’alerte nommée my_alert afin d’être alerté si des lignes de la table nommée gauge ont des valeurs supérieures à 300 dans la colonne gauge_value, exécutez :

  CopyExpand

  ALTER ALERT my_alert MODIFY CONDITION EXISTS (SELECT gauge_value FROM gauge WHERE gauge_value>300);
  

  Show lessSee more

  Scroll to top

• Pour modifier l’action de l’alerte nommée my_alert en CALL my_procedure(), exécutez :

  CopyExpand

  ALTER ALERT my_alert MODIFY ACTION CALL my_procedure();
  

  Show lessSee more

  Scroll to top

Destruction d’une alerte¶

Pour détruire une alerte, exécutez la commande DROP ALERT. Par exemple :

DROP ALERT my_alert;

Pour supprimer une alerte sans déclencher d’erreur si l’alerte n’existe pas, exécutez :

DROP ALERT IF EXISTS my_alert;

Affichage des détails à propos d’une alerte¶

Pour dresser la liste des alertes créées dans un compte, une base de données ou un schéma, exécutez la commande SHOW ALERTS. Par exemple, pour dresser la liste des alertes qui ont été créées dans le schéma actuel, exécutez la commande suivante :

SHOW ALERTS;

Cette commande dresse la liste des alertes dont vous êtes propriétaire et des alertes pour lesquelles vous disposez du privilège MONITOR ou OPERATE.

Pour voir les détails d’une alerte spécifique, exécutez la commande DESCRIBE ALERT. Par exemple :

DESC ALERT my_alert;

Clonage d’une alerte¶

Vous pouvez cloner une alerte (soit en utilisant CREATE ALERT … CLONE, soit en clonant la base de données ou le schéma contenant l’alerte).

Si vous clonez une alerte sans serveur, vous n’avez pas besoin d’utiliser un rôle doté du privilège global EXECUTE MANAGED ALERT. Toutefois, vous ne pourrez pas reprendre ce signalement tant que le rôle propriétaire de l’alerte n’aura pas obtenu le privilège EXECUTE MANAGED ALERT.

Suivi de l’exécution des alertes¶

Pour surveiller l’exécution des alertes, vous pouvez :

• Vérifier les résultats de l’action qui a été spécifiée pour l’alerte. Par exemple, si l’action a inséré des lignes dans un tableau, vous pouvez vérifier la présence de nouvelles lignes dans le tableau.

• Voir l’historique des exécutions d’alertes en utilisant l’une des méthodes suivantes :

  • La fonction de table ALERT_HISTORY dans le schéma INFORMATION_SCHEMA.

    Par exemple, pour voir les exécutions d’alertes au cours de la dernière heure, exécutez l’instruction suivante :

    CopyExpand

    SELECT *
    FROM
      TABLE(INFORMATION_SCHEMA.ALERT_HISTORY(
        SCHEDULED_TIME_RANGE_START
          =>dateadd('hour',-1,current_timestamp())))
    ORDER BY SCHEDULED_TIME DESC;
    

    Show lessSee more

    Scroll to top

  • La vue ALERT_HISTORY dans le schéma ACCOUNT_USAGE de la base de données partagée SNOWFLAKE.

Dans l’historique des requêtes, le nom de l’utilisateur qui a exécuté la requête sera SYSTEM. (Les alertes sont exécutées par le service système.)

Vue de l’historique des requêtes d’une alerte sans serveur¶

Pour voir l’historique des requêtes d’une alerte sans serveur, vous devez être le propriétaire de l’alerte ou utiliser un rôle qui dispose du privilège MONITOR ou OPERATE sur l’alerte elle-même. (Cela diffère des alertes utilisant l’un de vos entrepôts, qui nécessitent le privilège MONITOR ou OPERATOR sur l’entrepôt)

Par exemple, supposons que vous souhaitiez utiliser le rôle my_alert_role pour voir l’historique des requêtes de l’alerte my_alert. Si my_alert_role n’est pas le propriétaire de my_alert, vous devez accorder à ce rôle le privilège MONITOR ou OPERATE sur l’alerte :

GRANT MONITOR ON ALERT my_alert TO ROLE my_alert_role;

Une fois ce privilège accordé au rôle, vous pouvez l’utiliser pour voir l’historique des requêtes de l’alerte :

USE ROLE my_alert_role;

SELECT query_text FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
  WHERE query_text LIKE '%Some condition%'
    OR query_text LIKE '%Some action%'
  ORDER BY start_time DESC;