Alertes et notifications dans Snowflake (édition 2024)

La première fonctionnalité, ce sont les notifications par e-mail. Snowflake permet d'envoyer des e-mails à toute adresse vérifiée via une procédure stockée appelée SYSTEM$SEND_EMAIL. Une adresse e-mail est considérée comme vérifiée si elle appartient à un utilisateur Snowflake et si celui-ci l'a validée via un lien d'activation reçu par e-mail (instructions ici). Si vous disposez d'une boîte partagée ou d'une adresse e-mail dédiée que vous souhaitez utiliser pour les notifications, vous devez donc d'abord créer un utilisateur distinct dans Snowflake, puis lui associer cette adresse.

Pour utiliser SYSTEM$SEND_EMAIL, il faut créer une intégration de notification.

Qu'est-ce qu'une intégration de notification Snowflake ?

On peut voir l'intégration de notification comme un objet wrapper qui encapsule les informations et les privilèges de sécurité nécessaires à l'envoi de notifications depuis Snowflake. Pour créer une intégration de notification, l'utilisateur doit disposer d'un rôle avec le privilège CREATE INTEGRATION. Par défaut, ce privilège n'est attribué qu'aux utilisateurs dotés du rôle ACCOUNTADMIN. Les administrateurs Snowflake peuvent ainsi respecter le principe de séparation des tâches : ils créent l'intégration de notification, gèrent la liste des destinataires et accordent un droit d'usage sur l'objet aux développeurs, qui peuvent l'utiliser sans pour autant le modifier.

Comment créer une intégration de notification

Pour créer une intégration de notification, exécutez la commande suivante :

CREATE NOTIFICATION INTEGRATION my_email_int
    TYPE=EMAIL
    ENABLED=TRUE
  ALLOWED_RECIPIENTS=('joe.doe@my_domain.com','another.joe@my_domain.com');

La commande CREATE NOTIFICATION comporte 3 paramètres :

• TYPE : le type d'intégration de notification souhaité (EMAIL, QUEUE)
• ENABLED : TRUE ou FALSE
• ALLOWED_RECIPIENTS : jusqu'à 10 adresses e-mail vérifiées vers lesquelles envoyer le message

Une fois l'intégration de notification en place, vous voudrez peut-être accorder le privilège d'usage à d'autres rôles afin qu'ils puissent l'utiliser pour envoyer des e-mails.

1GRANT USAGE ON INTEGRATION my_email_int TO ROLE my_developer_role;

Dès lors qu'un objet d'intégration de notification existe avec au moins une adresse e-mail vérifiée, vous pouvez envoyer un e-mail.

Déclencher manuellement des e-mails depuis Snowflake

La procédure SYSTEM$SEND_EMAIL s'invoque avec le mot-clé CALL, comme toute autre procédure stockée. Voici un exemple de commande :

CALL SYSTEM$SEND_EMAIL(
'my_email_int',
'joe.doe@my_domain.com,
'Hello from Snowflake Alerting',
'My first email sent from Snowflake via SYSTEM$SEND_EMAIL stored procedure'

Vous remarquerez que l'adresse e-mail est à nouveau spécifiée dans l'appel de la fonction. Si elle ne figure pas dans la propriété ALLOWED_RECIPIENTS définie dans l'intégration de notification, aucun e-mail ne sera envoyé.

Voici à quoi ressemble l'e-mail issu de la commande ci-dessus :

Si la procédure stockée s'exécute correctement, elle retourne **TRUE** :

Déclencher automatiquement des e-mails depuis Snowflake

La plupart des clients Snowflake souhaitent disposer d'alertes automatisées. Comment y parvenir ?

Un schéma de déploiement courant consiste à imbriquer la procédure stockée SYSTEM$SEND_EMAIL dans une autre procédure. En général, cette procédure stockée commence par vérifier qu'une condition est remplie, puis, le cas échéant, déclenche SYSTEM$SEND_EMAIL pour envoyer l'e-mail.

Quels types de conditions peut-on vérifier ?

• Superviser les tasks Snowflake en vérifiant si une task a été suspendue
• Superviser les streams Snowflake pour être notifié si un stream devient obsolète trop rapidement
• Valider des règles métier spécifiques (par exemple, l'utilisateur doit être un client payant pour accéder à la fonctionnalité X)

Prenons l'exemple de la supervision d'une task Snowflake. Vous avez peut-être une task — ou un arbre de tasks — censée s'exécuter selon une planification donnée. Vous souhaitez savoir si elle a été suspendue et a donc cessé de tourner. Cela peut arriver lors de la modification d'une task, puisqu'il faut la suspendre avant d'appliquer le changement, puis la reprendre.

Pour détecter les tasks suspendues, nous allons créer une procédure stockée nommée task_state_monitoring qui surveille l'état d'une task donnée et, si elle la trouve à l'état suspendu, envoie un e-mail. Cette procédure liste toutes les tasks via la commande show tasks, puis parcourt chacune d'elles et vérifie si la variable state courante de la task vaut 'suspended'. Un e-mail sera envoyé pour chaque task suspendue.

Le code d'une telle procédure peut ressembler à ceci :

create or replace procedure task_state_monitor(task_name string)
returns varchar not null
language SQL
AS
$$
DECLARE
    task_state string;
    c CURSOR FOR SELECT "state" from table(result_scan(last_query_id())) where "name" = ?;
BEGIN
    show tasks;
    open c USING (task_name);
    fetch c into task_state;
    IF(task_state = 'suspended') THEN
        CALL SYSTEM$SEND_EMAIL(
            'my_email_int',

Développer le code

Pour déployer cette procédure stockée, il suffit de créer une task Snowflake qui appellera la procédure task_state_monitoring selon la planification souhaitée (toutes les 5 minutes, 2 fois par jour, etc.).

Autre fonctionnalité puissante côté notification : les alertes Snowflake. Il s'agit d'un objet au niveau du schéma qui permet de réagir à différentes situations dans vos données ou, plus largement, dans votre compte Snowflake.

L'alerting sur les coûts est un cas d'usage fréquent des alertes Snowflake. Par exemple, une alerte peut détecter un pic de consommation de crédits sur un seul virtual warehouse ou tout autre service Snowflake. Autre cas d'usage : valider des règles métier et être notifié en cas d'échec de la validation. Les alertes ne se limitent pas à l'envoi d'un e-mail. Vous pouvez par exemple, à chaque échec de validation d'une règle, ajouter un enregistrement dans une table de logs contenant l'horodatage, le type de validation et une description de l'échec.

Une alerte Snowflake repose sur trois composants :

• Une condition qui déclenche l'alerte (par exemple, une requête ne renvoie aucun enregistrement)
• Une action qui définit ce qui doit se produire lorsque la condition est remplie (envoyer un e-mail, insérer un enregistrement dans une table, etc.)
• Une fréquence qui définit à quelle cadence la condition est évaluée (par exemple, toutes les 24 heures)

Comment créer une alerte Snowflake ?

Dans cet exemple, nous allons créer une alerte Snowflake qui nous notifie par e-mail si la consommation quotidienne de crédits Snowflake dépasse 100 crédits.

Voici le code de l'alerte, exécutée toutes les heures :

CREATE OR REPLACE ALERT credits_consumption
  WAREHOUSE = COMPUTE_WH
  SCHEDULE = 'USING CRON 0 1 * * * UTC'
  IF( EXISTS (
    select
        1
    from
        snowflake.account_usage.metering_history
    where
        start_time >= SNOWFLAKE.ALERT.LAST_SUCCESSFUL_SCHEDULED_TIME()
        AND SNOWFLAKE.ALERT.SCHEDULED_TIME()
    group by service_type
    having sum(credits_used) > 100

))

Développer le code

Décortiquons ce code :

• Nous devons définir un virtual warehouse, COMPUTE_WH, qui servira à exécuter l'alerte.
• Nous avons défini une planification au format CRON pour que l'alerte s'exécute chaque jour à 1h UTC.
• Comme condition, une requête SQL renvoie une seule ligne contenant la valeur 1 si la consommation de crédits Snowflake dépasse 100 sur les dernières 24 heures.
• Comme action, nous appelons la procédure SYSTEM$SEND_EMAIL.

Une fois l'alerte créée, il faut la reprendre, sinon elle ne s'exécutera pas :

alter alert credits_consumption resume;

L'alerte est désormais opérationnelle.

Supervision des alertes

Snowflake propose une vue ALERT_HISTORY dans ACCOUNT_USAGE, qui permet de suivre l'exécution des alertes :

SELECT *
FROM snowflake.account_usage.alert_history
ORDER BY SCHEDULED_TIME DESC
;

Cette vue offre un aperçu de chaque exécution d'alerte, avec les query_id associés à la requête utilisée pour valider la condition (CONDITION_QUERY_ID) et à celle exécutée pour l'action (ACTION_QUERY_ID, c'est-à-dire la requête qui déclenche la procédure SYSTEM$SEND_EMAIL).

À noter : les requêtes d'action et de condition n'apparaissent pas dans QUERY_HISTORY. Pour les récupérer, il faut utiliser la fonction RESULT_SCAN :

1select * from table(result_scan('<action_query_id>'));

Comment les alertes Snowflake sont-elles facturées ?

Il n'y a pas de surcoût pour l'envoi d'e-mails ni pour les alertes Snowflake elles-mêmes. Vous ne payez que le temps de compute nécessaire à l'exécution des requêtes de validation et d'action sur le virtual warehouse spécifié.

Les avantages des alertes Snowflake

Les alertes Snowflake simplifient considérablement la validation de la logique métier et le déclenchement d'une action en aval. Pour envoyer des notifications par e-mail via la procédure SYSTEM$SEND_EMAIL, il fallait créer une procédure stockée distincte exécutant explicitement du SQL, traitant les résultats et effectuant les contrôles de validation avant de déclencher l'e-mail. Il fallait ensuite créer une task séparée pour invoquer cette procédure stockée selon une planification.

Avec les alertes Snowflake, toutes ces étapes se résument à la création d'un seul objet d'alerte.

De nombreux utilisateurs préfèrent recevoir leurs notifications dans un canal Slack d'équipe plutôt que par e-mail. Cela favorise une collaboration plus rapide et une résolution plus efficace. Comme Slack permet d'envoyer des e-mails vers un canal via une adresse dédiée, il suffit de configurer notre intégration de notification Snowflake avec cette adresse.

Étape 1 : créer une adresse e-mail pour le canal Slack

D'abord, il faut créer une nouvelle intégration dans le canal Slack pour obtenir une adresse e-mail utilisable. Dans les paramètres du canal, cliquez sur Intégrations, puis sur Envoyer des e-mails à ce canal :

Étape 2 : recevoir la confirmation Slack

Une fois cette étape réalisée, Slack envoie automatiquement un message dans votre canal :

Étape 3 : créer un utilisateur Snowflake avec l'adresse e-mail Slack

Snowflake n'autorisant l'envoi d'e-mails qu'à des utilisateurs Snowflake vérifiés, il faut créer un nouvel utilisateur dans Snowflake et lui attribuer cette adresse e-mail Slack. Il reste ensuite à vérifier l'adresse.

Étape 4 : vérifier l'e-mail Snowflake dans Slack

L'e-mail de vérification est envoyé directement par Snowflake dans le canal Slack. Il suffit alors de cliquer sur le lien pour valider l'adresse, qui pourra ensuite être utilisée par la procédure stockée SYSTEM$SEND_EMAIL(). Voici à quoi ressemble l'e-mail de vérification Snowflake dans Slack :

Plus haut, lors de la création de l'intégration de notification, nous avons défini le paramètre TYPE sur EMAIL. Mais ce paramètre accepte également la valeur QUEUE. Avec QUEUE, vous pouvez envoyer des notifications depuis Snowflake vers d'autres services de messagerie cloud comme Amazon SNS, Google Pub/Sub ou Microsoft Azure Event Grid.

Cette fonctionnalité se marie très bien avec le paramètre ERROR_INTEGRATION des tasks Snowflake ou de Snowpipe. Le paramètre ERROR_INTEGRATION accepte une intégration de notification de type QUEUE. Pour en savoir plus, consultez l'article de blog sur les notifications d'erreur pour les tasks Snowflake.

Tomáš Sobotík · Senior Data Engineer et Snowflake SME chez Norlys

Tomas est Snowflake Data SuperHero de longue date et expert reconnu de Snowflake. Fort de plus d'une décennie d'expérience dans le monde de la data, il a occupé les rôles de data engineer, d'architecte et d'administrateur Snowflake sur des projets variés, dans des secteurs et technologies très divers. Membre actif de la communauté, il partage volontiers son expertise pour inspirer les autres. Il est également formateur O'Reilly et anime des sessions de formation en ligne en direct.