Alert e notifiche in Snowflake (aggiornato al 2024)

La prima funzionalità è rappresentata dalle notifiche via email. Snowflake consente di inviare email a qualsiasi indirizzo verificato tramite una stored procedure denominata SYSTEM$SEND_EMAIL. Un indirizzo email si considera verificato se appartiene a un utente Snowflake che ne ha confermato la titolarità tramite il link di attivazione ricevuto via email (istruzioni qui). Se si vuole utilizzare per le notifiche una casella condivisa o un indirizzo specifico, occorre quindi creare prima un utente dedicato in Snowflake e poi associargli quell'indirizzo.

Per utilizzare SYSTEM$SEND_EMAIL è necessario creare una notification integration.

Che cos'è una Notification Integration di Snowflake

Si può pensare alla notification integration come a un "oggetto wrapper" che racchiude le informazioni e i privilegi di sicurezza necessari per inviare notifiche da Snowflake. Per crearne una, l'utente deve disporre di un ruolo con il privilegio CREATE INTEGRATION. Per impostazione predefinita, questo privilegio è riservato agli utenti con ruolo ACCOUNTADMIN: in questo modo gli amministratori Snowflake possono rispettare il principio della "segregation of duties". Gli amministratori creano la notification integration, gestiscono la lista dei destinatari e concedono il privilegio d'uso agli sviluppatori, che possono sfruttarla senza però modificarla.

Come creare una notification integration

Per creare una notification integration si può eseguire il comando seguente:

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

Il comando CREATE NOTIFICATION prevede 3 parametri:

• TYPE: il tipo di notification integration desiderato (EMAIL, QUEUE)
• ENABLED: TRUE o FALSE
• ALLOWED_RECIPIENTS: fino a 10 indirizzi email verificati a cui recapitare il messaggio

Una volta predisposta la notification integration, può essere utile concedere il privilegio d'uso ad altri ruoli, in modo che possano sfruttarla per inviare email.

1GRANT USAGE ON INTEGRATION my_email_int TO ROLE my_developer_role;

Una volta creato l'oggetto notification integration con almeno un indirizzo email verificato, si è pronti per inviare email.

Inviare email manualmente da Snowflake

La procedura SYSTEM$SEND_EMAIL si invoca con la parola chiave CALL, esattamente come qualsiasi altra stored procedure. Ecco un comando di esempio:

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'

Si noti che l'indirizzo email viene specificato nuovamente nella chiamata alla funzione. Se l'indirizzo non rientrasse nella proprietà ALLOWED_RECIPIENTS definita nella notification integration, non verrebbe inviata alcuna email.

Ecco come si presenta l'email generata dal comando sopra:

Se la stored procedure viene eseguita correttamente, restituisce **TRUE**:

Inviare email automaticamente da Snowflake

La maggior parte dei clienti Snowflake ha bisogno di un sistema di alerting automatizzato. Come ottenerlo?

Un pattern di deployment ricorrente consiste nell'incapsulare la stored procedure SYSTEM$SEND_EMAIL all'interno di un'altra procedura. In genere, quest'ultima verifica innanzitutto se una determinata condizione è soddisfatta e, in caso affermativo, richiama SYSTEM$SEND_EMAIL per inviare le email.

Che tipo di condizioni si possono controllare?

• Monitoraggio dei task di Snowflake, verificando se un task è stato sospeso
• Monitoraggio degli stream di Snowflake, per ricevere una notifica se uno stream diventa stale troppo presto
• Validazione di specifiche regole di business (ad es. l'utente deve essere un cliente pagante per accedere alla funzionalità X)

Prendiamo come esempio il monitoraggio dei task di Snowflake. Si supponga di avere un task, o un albero di task, che deve essere eseguito secondo una pianificazione prestabilita. È utile sapere se un task è stato sospeso e ha quindi smesso di girare: situazione che può verificarsi ogni volta che il task viene modificato, dato che è necessario sospenderlo prima dell'intervento e poi riattivarlo.

Per intercettare i task sospesi creeremo una stored procedure chiamata task_state_monitoring che monitora lo stato del task indicato e, se lo trova in stato sospeso, invia un'email. La procedura elenca tutti i task tramite il comando show tasks, poi itera su ognuno verificando se la variabile state corrente è uguale a 'suspended'. Per ogni task sospeso verrà inviata un'email.

Il codice della procedura può essere simile al seguente:

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',

Espandi codice

Per mettere in esercizio questa stored procedure è sufficiente creare un Snowflake task che richiami task_state_monitoring secondo la pianificazione preferita (ogni 5 minuti, 2 volte al giorno, ecc.).

Un'altra funzionalità di notifica molto potente è rappresentata dagli Snowflake Alerts: un oggetto a livello di schema che consente di reagire a diverse situazioni nei dati o, più in generale, nell'account Snowflake.

Il cost alerting è uno degli use case più frequenti. Si può ad esempio creare un alert per intercettare un picco nel consumo di crediti di un account su un singolo virtual warehouse o su un qualsiasi altro servizio Snowflake. Un altro caso d'uso è la validazione di regole di business, con notifica in caso di esito negativo. Gli alert non si limitano all'invio di email: ad esempio, quando una determinata regola non viene rispettata, si può inserire un record in una tabella di log contenente timestamp, tipologia di validazione e descrizione dell'errore.

Uno Snowflake Alert è composto da tre elementi:

• Una condizione che attiva l'alert (es. la query non restituisce alcun record)
• Un'azione che definisce cosa deve accadere se la condizione è soddisfatta (es. invio di un'email, inserimento di un record nella tabella)
• Un'impostazione di frequenza che stabilisce ogni quanto viene valutata la condizione (es. ogni 24 ore)

Come creare uno Snowflake Alert?

In questo esempio creeremo uno Snowflake Alert che ci notificherà via email quando il consumo giornaliero di crediti Snowflake supera i 100 crediti.

Ecco il codice dell'alert, eseguito ogni ora:

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

))

Espandi codice

Analizziamo il codice passo per passo:

• Va indicato un virtual warehouse, COMPUTE_WH, che verrà utilizzato per eseguire l'Alert.
• È stata definita una pianificazione con sintassi CRON per eseguire l'alert ogni giorno all'1:00 UTC.
• Come condizione viene usata una query SQL che restituisce una singola riga con il valore "1" se il consumo di crediti Snowflake nelle ultime 24 ore supera 100.
• Come azione viene richiamata la procedura SYSTEM$SEND_EMAIL.

Una volta creato correttamente, l'Alert va riattivato, altrimenti non verrà eseguito:

alter alert credits_consumption resume;

A questo punto l'Alert è operativo.

Monitoraggio degli Alert

Snowflake mette a disposizione la view ALERT_HISTORY all'interno di ACCOUNT_USAGE, utilizzabile per monitorare l'esecuzione degli alert:

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

La view fornisce una panoramica di ogni esecuzione dell'Alert, insieme ai query_id associati alla query eseguita per valutare la condizione (CONDITION_QUERY_ID) e a quella eseguita per l'azione (ACTION_QUERY_ID, ovvero la query che attiva la procedura SYSTEM$SEND_EMAIL).

Si tenga presente che le query di azione e di condizione non sono visibili nella QUERY_HISTORY: per recuperarle è necessario ricorrere alla funzione RESULT_SCAN:

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

Come vengono fatturati gli Snowflake Alerts

Non è previsto alcun costo aggiuntivo né per l'invio delle email né per gli Snowflake Alerts in sé. Si paga unicamente il tempo di compute necessario a eseguire le query di validazione e di azione sul virtual warehouse indicato.

Vantaggi degli Snowflake Alerts

Gli Snowflake Alerts semplificano enormemente la validazione della logica di business e l'attivazione di un'azione conseguente. Per inviare notifiche via email tramite SYSTEM$SEND_EMAIL era necessario creare una stored procedure dedicata che eseguisse SQL, ne elaborasse i risultati e svolgesse i controlli di validazione prima di inviare l'email; occorreva poi un task separato che invocasse la stored procedure secondo una pianificazione.

Con gli Snowflake Alerts tutti questi passaggi vengono astratti nella creazione di un unico oggetto alert.

Molti utenti preferiscono ricevere le notifiche su un canale Slack del team anziché via email: questo favorisce una collaborazione più rapida e una risoluzione tempestiva delle segnalazioni. Poiché Slack consente di inviare email a un canale tramite uno specifico indirizzo dedicato, è possibile configurare la notification integration di Snowflake utilizzando proprio quell'indirizzo.

Passo 1: creare l'indirizzo email del canale Slack

Per prima cosa occorre creare una nuova integrazione nel canale Slack, così da ottenere un indirizzo email da utilizzare. Nelle impostazioni del canale, fare clic su "Integrations" e quindi su "Send emails to this channel":

Passo 2: ricevere la conferma da Slack

Una volta completato questo passaggio, Slack invierà automaticamente un messaggio nel canale:

Passo 3: creare un utente Snowflake con l'indirizzo email di Slack

Dato che Snowflake permette di inviare email solo a utenti Snowflake verificati, è necessario creare un nuovo utente in Snowflake e associargli l'indirizzo email di Slack. A quel punto va verificato l'indirizzo.

Passo 4: verificare l'email di Snowflake in Slack

L'email di verifica verrà inviata da Snowflake direttamente al canale Slack: cliccando sul link sarà possibile confermare l'indirizzo e renderlo utilizzabile dalla stored procedure SYSTEM$SEND_EMAIL(). Ecco come apparirà su Slack l'email di verifica di Snowflake:

In precedenza, nella creazione della notification integration, abbiamo impostato il parametro TYPE sul valore EMAIL. Lo stesso parametro supporta però anche l'opzione QUEUE: con questa impostazione è possibile inviare notifiche da Snowflake ad altri servizi di messaggistica cloud come Amazon SNS, Google Pub/Sub o Microsoft Azure Event Grid.

Questa funzionalità si integra perfettamente con il parametro ERROR_INTEGRATION degli Snowflake Tasks o di Snowpipe. Il parametro ERROR_INTEGRATION accetta infatti una notification integration di tipo QUEUE. Per approfondire, si rimanda all'articolo del blog su Error Notifications for Snowflake tasks.

Tomáš Sobotík·Senior Data Engineer & Snowflake SME presso Norlys

Tomas è un Snowflake Data SuperHero di lunga data ed esperto di riferimento sulla piattaforma. Vanta oltre dieci anni di esperienza nel mondo dei dati, durante i quali ha ricoperto i ruoli di Snowflake data engineer, architect e admin in progetti che hanno spaziato fra settori e tecnologie molto diversi tra loro. È un membro attivo della community, con cui condivide costantemente le proprie competenze, ed è inoltre istruttore O'Reilly, dove tiene sessioni di formazione online dal vivo.