Alerts e Notifications no Snowflake (Atualizado para 2024)

O primeiro recurso é o de notificações por email. O Snowflake permite enviar emails para qualquer endereço verificado por meio de uma stored procedure chamada SYSTEM$SEND_EMAIL. Um endereço é considerado verificado quando pertence a um usuário do Snowflake e foi confirmado por ele através de um link de ativação enviado por email (instruções aqui). Se você tem uma caixa compartilhada ou um endereço específico que quer usar para notificações, será preciso primeiro criar um usuário separado no Snowflake e associar esse email a ele.

Para usar o SYSTEM$SEND_EMAIL, é necessário criar uma notification integration.

O que é uma Snowflake Notification Integration

Você pode pensar na notification integration como um "objeto wrapper" que encapsula as informações e privilégios de segurança necessários para enviar notificações a partir do Snowflake. Para criá-la, o usuário precisa ter uma role com o privilégio CREATE INTEGRATION. Por padrão, esse privilégio está disponível apenas para usuários com a role ACCOUNTADMIN. Isso permite que os administradores do Snowflake mantenham o princípio de "segregação de funções". Os admins podem criar a notification integration e manter a lista de destinatários, além de conceder o uso do objeto aos desenvolvedores, que podem utilizá-lo, mas não modificá-lo.

Como criar uma notification integration

Para criar uma notification integration, basta executar o seguinte comando:

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

O comando CREATE NOTIFICATION tem 3 parâmetros:

• TYPE: que tipo de notification integration queremos (EMAIL, QUEUE)
• ENABLED: TRUE ou FALSE
• ALLOWED_RECIPIENTS: até 10 endereços de email verificados para os quais queremos enviar as mensagens

Com a notification integration no lugar, pode ser interessante conceder o privilégio de uso a outras roles, para que também possam enviar emails.

1GRANT USAGE ON INTEGRATION my_email_int TO ROLE my_developer_role;

Uma vez criado o objeto de notification integration com pelo menos um endereço de email verificado, já dá para enviar emails.

Disparando emails manualmente a partir do Snowflake

A procedure SYSTEM$SEND_EMAIL é invocada com a palavra-chave CALL, como qualquer outra stored procedure. Veja um exemplo:

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'

Repare que o endereço de email é informado novamente na chamada da função. Caso o endereço não esteja na propriedade ALLOWED_RECIPIENTS definida na notification integration, nenhum email será enviado.

Veja como fica o email enviado pelo comando acima:

Se a stored procedure for executada com sucesso, ela retorna **TRUE**:

Disparando emails automaticamente a partir do Snowflake

A maioria dos clientes do Snowflake vai querer ter alertas automatizados. Como fazer isso?

Um padrão comum é embutir a stored procedure SYSTEM$SEND_EMAIL dentro de outra procedure. Normalmente, essa procedure primeiro valida se determinada condição foi atendida e, em caso afirmativo, dispara a SYSTEM$SEND_EMAIL para enviar os emails.

Que tipos de condição podem ser checadas?

• Monitorar tasks do Snowflake para verificar se foram suspensas
• Monitorar streams do Snowflake para receber notificação se um stream ficar stale rápido demais
• Validar regras de negócio específicas (por exemplo, o usuário precisa ser cliente pagante para acessar a funcionalidade X)

Vamos usar o monitoramento de tasks do Snowflake como exemplo. Imagine que você tem uma task ou uma árvore de tasks que deveria rodar em determinada periodicidade. Você quer saber se alguma task foi suspensa e, por isso, deixou de rodar. Isso pode acontecer sempre que uma task é alterada, já que é preciso suspendê-la antes da alteração e retomá-la depois.

Para detectar tasks suspensas, vamos criar uma stored procedure chamada task_state_monitoring que monitora o estado da task e, se encontrá-la no estado suspenso, envia um email para você. Essa procedure lista todas as tasks usando o comando show tasks, depois itera por cada uma e verifica se a variável state atual é igual a 'suspended'. Um email será enviado para cada task suspensa.

O código dessa procedure pode ficar assim:

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

Expandir Código

Para colocar essa stored procedure em produção, você pode criar uma Snowflake task que chame a procedure task_state_monitoring na periodicidade desejada (por exemplo, a cada 5 minutos, 2 vezes por dia etc.).

Outro recurso poderoso de notificação são os Snowflake Alerts. Trata-se de um objeto de schema que permite reagir a diferentes situações nos seus dados ou na sua conta Snowflake como um todo.

Cost Alerting é um caso de uso comum para os Snowflake Alerts. Por exemplo, dá para criar um alerta que detecta um pico no consumo de créditos da conta em um único virtual warehouse, ou em qualquer outro serviço do Snowflake. Outro caso de uso pode ser validar regras de negócio e receber uma notificação se a validação falhar. Os Alerts não se limitam a disparar emails. Por exemplo, sempre que a validação de uma regra falhar, você pode inserir um registro em uma tabela de log com o timestamp, o tipo da validação e a descrição da falha.

Um Snowflake Alert é formado por três componentes:

• Uma condition que dispara o alerta (ex.: a query não retorna registros)
• Uma action que define o que deve acontecer caso a condição seja atendida (ex.: enviar email, inserir registro em uma tabela)
• Uma configuração de frequency que define com que periodicidade a condição é avaliada (ex.: a cada 24 horas)

Como criar um Snowflake Alert?

Para este exemplo, vamos criar um Snowflake Alert que nos notifica por email se o consumo diário de créditos do Snowflake ultrapassar 100 créditos.

Veja o código do alerta, que roda de hora em hora:

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

))

Expandir Código

Vamos analisar o código:

• Definimos um virtual warehouse, COMPUTE_WH, que será usado para rodar o Alert.
• Definimos um agendamento via sintaxe CRON para que o alerta rode diariamente à 1h UTC.
• Como condition, temos uma query SQL que retorna uma única linha com o valor "1" caso o consumo de créditos do Snowflake nas últimas 24 horas tenha passado de 100.
• Como action, chamamos a procedure SYSTEM$SEND_EMAIL.

Depois que o Alert for criado com sucesso, precisamos retomá-lo, senão ele não vai rodar:

alter alert credits_consumption resume;

Agora o Alert está em modo operacional.

Monitoramento de Alerts

O Snowflake oferece uma view ALERT_HISTORY em ACCOUNT_USAGE, que pode ser usada para monitorar a execução dos alertas:

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

A view traz um panorama de cada execução de Alert, junto com os query_ids associados à query executada para validar a condition do alerta (CONDITION_QUERY_ID) e à query executada para a action correspondente (ACTION_QUERY_ID, ou seja, a query que dispara a procedure SYSTEM$SEND_EMAIL).

Atenção: as queries de action e condition não aparecem no QUERY_HISTORY e, para acessá-las, você precisa usar a função RESULT_SCAN:

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

Como os Snowflake Alerts são cobrados

Não há cobrança extra pelo envio de emails ou pelos Snowflake Alerts em si. Você só paga pelo tempo de compute necessário para rodar as queries de validação e action no virtual warehouse especificado.

Vantagens dos Snowflake Alerts

Os Snowflake Alerts simplificam bastante o processo de validar lógica de negócio e disparar alguma ação a partir disso. Para enviar notificações por email com a procedure SYSTEM$SEND_EMAIL, foi preciso criar uma stored procedure separada que executava explicitamente um SQL, processava os resultados e fazia as validações antes de disparar o email. Em seguida, foi preciso criar uma task separada para invocar essa stored procedure em um determinado agendamento.

Com os Snowflake Alerts, todas essas etapas ficam abstraídas na criação de um único objeto de alerta.

Muita gente prefere receber as notificações em um canal do Slack do time, em vez de por email. Isso facilita a colaboração e a resolução mais rápida do que motivou a notificação. Como o Slack permite enviar emails para um canal através de um endereço específico, dá para configurar a notification integration do Snowflake usando esse endereço dedicado ao canal.

Passo 1: Criar um endereço de email para o canal do Slack

Primeiro, precisamos criar uma nova integração no canal do Slack para obter um endereço de email que possamos usar. Nas configurações do canal, clique em "Integrações" e depois em "Enviar emails para este canal":

Passo 2: Receber a confirmação do Slack

Depois desse passo, o Slack envia automaticamente uma mensagem para o seu canal:

Passo 3: Criar um usuário no Snowflake com o endereço de email do Slack

Como o Snowflake só permite enviar emails para usuários verificados do Snowflake, precisamos criar um novo usuário no Snowflake e atribuir a ele o endereço de email do Slack. Em seguida, é preciso verificar esse endereço.

Passo 4: Verificar o email do Snowflake no Slack

O email de verificação é enviado pelo Snowflake direto para o canal do Slack, onde você pode clicar no link e validar o endereço para uso futuro na stored procedure SYSTEM$SEND_EMAIL(). Veja como o email de verificação do Snowflake aparece no Slack:

Anteriormente, ao criar a notification integration, definimos o parâmetro TYPE com o valor EMAIL. Mas esse parâmetro também aceita QUEUE como opção. Com QUEUE, dá para enviar notificações do Snowflake para outros serviços de mensageria em nuvem, como Amazon SNS, Google Pub/Sub ou Microsoft Azure Event Grid.

Essa funcionalidade combina bem com o parâmetro ERROR_INTEGRATION em Snowflake Tasks ou Snowpipe. O parâmetro ERROR_INTEGRATION aceita uma notification integration do tipo QUEUE. Para saber mais, confira o post sobre Error Notifications para Snowflake tasks.

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

Tomas é um Snowflake Data SuperHero de longa data e referência geral em Snowflake. Sua ampla experiência no mundo dos dados se estende por mais de uma década, durante a qual atuou como data engineer, arquiteto e admin de Snowflake em diversos projetos, em diferentes setores e tecnologias. Tomas é um membro central da comunidade, compartilhando ativamente seu conhecimento e inspirando outras pessoas. Também é instrutor da O'Reilly, conduzindo treinamentos online ao vivo.