Alertas y notificaciones en Snowflake (actualizado a 2024)

La primera función son las notificaciones por correo electrónico. Snowflake te permite enviar correos a cualquier dirección verificada mediante un stored procedure llamado SYSTEM$SEND_EMAIL. Una dirección de correo se considera verificada si pertenece a un usuario de Snowflake y este la validó a través de un enlace de activación (instrucciones aquí). Si tienes un buzón compartido o una dirección específica que quieras usar para las notificaciones, primero debes crear un usuario aparte en Snowflake y luego asignarle ese correo.

Para usar SYSTEM$SEND_EMAIL, los usuarios deben crear una notification integration.

¿Qué es una Notification Integration de Snowflake?

Puedes pensar en la notification integration como un "objeto contenedor" que encapsula la información y los privilegios de seguridad necesarios para enviar notificaciones desde Snowflake. Para crearla, el usuario debe tener un rol con el privilegio CREATE INTEGRATION. Por defecto, este privilegio solo está disponible para los usuarios con el rol ACCOUNTADMIN, lo que permite a los administradores de Snowflake mantener el principio de "segregación de funciones". Los administradores pueden crear la notification integration y mantener la lista de destinatarios, y luego otorgar el uso del objeto a los desarrolladores, que pueden utilizarlo pero no modificarlo.

Cómo crear una notification integration

Para crear una notification integration, puedes ejecutar el siguiente comando:

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

El comando CREATE NOTIFICATION tiene 3 parámetros:

• TYPE: qué tipo de notification integration queremos (EMAIL, QUEUE)
• ENABLED: TRUE o FALSE
• ALLOWED_RECIPIENTS: hasta 10 direcciones de correo verificadas a las que queremos entregar el mensaje

Una vez creada la notification integration, quizá quieras otorgar el privilegio de uso a otros roles para que también puedan usarla para enviar correos.

1GRANT USAGE ON INTEGRATION my_email_int TO ROLE my_developer_role;

Una vez creado el objeto de notification integration con al menos una dirección de correo verificada, los usuarios ya pueden enviar correos.

Cómo disparar correos manualmente desde Snowflake

El procedimiento SYSTEM$SEND_EMAIL se invoca con la palabra clave CALL, igual que cualquier otro stored procedure. Aquí tienes un comando de ejemplo:

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'

Como ves, la dirección de correo se define nuevamente en la llamada a la función. Si la dirección no figura en la propiedad ALLOWED_RECIPIENTS definida en la notification integration, no se enviará ningún correo.

Así se ve el correo generado por el comando anterior:

Si el stored procedure se ejecuta correctamente, devuelve **TRUE**:

Cómo disparar correos automáticamente desde Snowflake

La mayoría de los clientes de Snowflake querrán contar con alertas automatizadas. ¿Cómo se logra esto?

Un patrón de implementación habitual consiste en incrustar el stored procedure SYSTEM$SEND_EMAIL dentro de otro procedimiento. Por lo general, el stored procedure primero valida si se cumple cierta condición y, en ese caso, dispara SYSTEM$SEND_EMAIL para enviar los correos.

¿Qué tipo de condiciones se pueden verificar?

• Monitorear tasks de Snowflake para comprobar si la task se suspendió
• Monitorear streams de Snowflake para recibir notificaciones si un stream se vuelve obsoleto antes de tiempo
• Validar reglas de negocio específicas (por ejemplo, que los usuarios sean clientes de pago para acceder a la función X)

Tomemos como ejemplo el monitoreo de tasks de Snowflake. Imagina que tienes una task o un árbol de tasks que debería ejecutarse según una programación determinada. Quieres saber si alguna se suspendió y, por lo tanto, dejó de ejecutarse. Esto puede pasar cada vez que se modifica una task, ya que hay que suspenderla antes de hacer el cambio y luego reanudarla.

Para detectar tasks suspendidas, crearemos un stored procedure llamado task_state_monitoring que monitoreará el estado de la task indicada y, si la encuentra en estado suspendido, te enviará un correo. El procedimiento lista todas las tasks con el comando show tasks, recorre cada una y comprueba si la variable state actual es igual a 'suspended'. Se enviará un correo por cada task suspendida.

El código del procedimiento puede verse así:

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 desplegar este stored procedure, puedes crear una task de Snowflake que llame al procedimiento task_state_monitoring con la frecuencia que necesites (por ejemplo, cada 5 minutos, 2 veces al día, etc.).

Otra función potente de notificación son las Snowflake Alerts. Se trata de un objeto a nivel de esquema que te permite reaccionar ante distintas situaciones en tus datos o en tu cuenta de Snowflake en general.

Las alertas de costos son un caso de uso común para las Snowflake Alerts. Por ejemplo, se puede crear una alerta para detectar si el consumo de créditos de una cuenta se dispara en un solo virtual warehouse, o en cualquier otro servicio de Snowflake. Otro caso de uso es la validación de reglas de negocio y recibir una notificación cuando la validación falla. Las alertas no se limitan a disparar un correo. Por ejemplo, cada vez que la validación de una regla no pase, puedes insertar un registro en una tabla de log con el timestamp, el tipo de validación y la descripción del fallo.

Una Snowflake Alert consta de tres componentes:

• Una condición que dispara la alerta (por ejemplo, una consulta que no devuelve registros)
• Una acción que define lo que debe ocurrir si se cumple la condición (por ejemplo, enviar un correo, insertar un registro en una tabla)
• Una configuración de frecuencia que define cada cuánto se evalúa la condición (por ejemplo, cada 24 horas)

¿Cómo crear una Snowflake Alert?

En este ejemplo crearemos una Snowflake Alert que nos notifique por correo si el consumo diario de créditos de Snowflake supera los 100 créditos.

Este es el código de la alerta, que se ejecuta cada 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

Repasemos el código:

• Hay que definir un virtual warehouse, COMPUTE_WH, que se usará para ejecutar la alerta.
• Definimos una programación con sintaxis CRON para que la alerta se ejecute diariamente a la 1 AM UTC.
• Como condición tenemos una consulta SQL que devuelve una sola fila con el valor "1" si el consumo de créditos de Snowflake supera los 100 en las últimas 24 horas.
• Como acción llamamos al procedimiento SYSTEM$SEND_EMAIL.

Una vez creada la alerta con éxito, hay que reanudarla; de lo contrario no se ejecutará:

alter alert credits_consumption resume;

Ahora la alerta está en modo operativo.

Monitoreo de alertas

Snowflake ofrece una vista ALERT_HISTORY dentro de ACCOUNT_USAGE que sirve para monitorear la ejecución de las alertas:

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

La vista incluye un resumen de cada ejecución de alerta junto con los query_id asociados a la consulta que valida la condición (CONDITION_QUERY_ID) y a la consulta que ejecuta la acción (ACTION_QUERY_ID, es decir, la consulta que dispara el procedimiento SYSTEM$SEND_EMAIL).

Ten en cuenta que las consultas de acción y condición no aparecen en QUERY_HISTORY; para obtenerlas hay que usar la función RESULT_SCAN:

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

¿Cómo se facturan las Snowflake Alerts?

No hay cobro adicional por el envío de correos ni por las Snowflake Alerts en sí. Los usuarios solo pagan por el tiempo de cómputo necesario para ejecutar las consultas de validación y acción en el virtual warehouse especificado.

Ventajas de las Snowflake Alerts

Las Snowflake Alerts simplifican enormemente el proceso de validar lógica de negocio y disparar alguna acción a partir de ello. Para enviar notificaciones por correo con el procedimiento SYSTEM$SEND_EMAIL, antes había que crear un stored procedure aparte que ejecutara explícitamente cierto SQL, procesara los resultados y realizara las validaciones antes de disparar el correo. Después, había que crear una task separada que invocara el stored procedure según una programación.

Con las Snowflake Alerts, todos esos pasos se abstraen en la creación de un único objeto de alerta.

Muchos usuarios prefieren recibir las notificaciones en un canal de Slack del equipo en lugar de por correo. Esto agiliza la colaboración y la resolución del aviso. Como Slack admite el envío de correos a un canal mediante una dirección específica, podemos configurar la notification integration de Snowflake usando la dirección dedicada a ese canal.

Paso 1: crear una dirección de correo para el canal de Slack

Primero, hay que crear una nueva integración en el canal de Slack para obtener una dirección de correo que podamos usar. En la configuración del canal, haz clic en "Integrations" y luego en "Send emails to this channel":

Paso 2: recibir la confirmación de Slack

Tras completar este paso, Slack te enviará automáticamente un mensaje al canal:

Paso 3: crear un usuario de Snowflake con la dirección de correo de Slack

Como Snowflake solo permite enviar correos a usuarios verificados de Snowflake, hay que crear un nuevo usuario en Snowflake y asignarle esta dirección de correo de Slack. Luego debemos verificar la dirección.

Paso 4: verificar el correo de Snowflake en Slack

El correo de verificación se enviará desde Snowflake directamente al canal de Slack, donde puedes hacer clic en el enlace para verificar la dirección y luego utilizarla en el stored procedure SYSTEM$SEND_EMAIL(). Así se ve el correo de verificación de Snowflake en Slack:

Antes, al crear la notification integration, establecimos el parámetro TYPE con el valor EMAIL. Pero este parámetro también admite QUEUE como opción. Cuando se configura como QUEUE, los usuarios pueden enviar notificaciones desde Snowflake a otros servicios de mensajería en la nube como Amazon SNS, Google Pub/Sub o Microsoft Azure Event Grid.

Esta funcionalidad se complementa muy bien con el parámetro ERROR_INTEGRATION de las tasks de Snowflake o Snowpipe. ERROR_INTEGRATION acepta una notification integration de tipo QUEUE. Para saber más, consulta el post sobre Notificaciones de error para tasks de Snowflake.

Tomáš Sobotík·Senior Data Engineer y Snowflake SME en Norlys

Tomas es un Snowflake Data SuperHero de larga trayectoria y un referente en Snowflake. Su experiencia en el mundo de los datos abarca más de una década, durante la cual se ha desempeñado como data engineer, arquitecto y administrador de Snowflake en distintos proyectos, industrias y tecnologías. Tomas es un miembro activo de la comunidad: comparte su conocimiento y motiva a otros. Además, es instructor de O'Reilly y dirige sesiones de capacitación en vivo online.