Alerts & Notifications in Snowflake (Update 2024)

Das erste Feature sind Email Notifications. Über die Stored Procedure SYSTEM$SEND_EMAIL lassen sich aus Snowflake heraus E-Mails an jede verifizierte E-Mail-Adresse senden. Verifiziert ist eine Adresse dann, wenn sie zu einem Snowflake-User gehört und von diesem über einen Aktivierungslink bestätigt wurde (Anleitung hier). Wenn Sie ein gemeinsam genutztes Postfach oder eine bestimmte Adresse für Benachrichtigungen verwenden möchten, müssen Sie in Snowflake zunächst einen eigenen User anlegen und ihm diese E-Mail-Adresse zuweisen.

Um SYSTEM$SEND_EMAIL nutzen zu können, brauchen Sie eine Notification Integration.

Was ist eine Snowflake Notification Integration?

Die Notification Integration lässt sich als "Wrapper-Objekt" verstehen, das alle Informationen und Sicherheitsrechte bündelt, die zum Versenden von Benachrichtigungen aus Snowflake nötig sind. Um eine Notification Integration anzulegen, benötigen Sie eine Rolle mit dem Privileg CREATE INTEGRATION. Standardmäßig steht dieses Privileg nur der Rolle ACCOUNTADMIN zur Verfügung. So lässt sich das Prinzip der Funktionstrennung ("segregation of duties") sauber wahren: Admins legen die Notification Integration an und pflegen die Empfängerliste; Entwickler erhalten lediglich das Nutzungsrecht für das Objekt – sie können es verwenden, aber nicht verändern.

So legen Sie eine Notification Integration an

Mit folgendem Befehl erstellen Sie eine Notification Integration:

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

Der Befehl CREATE NOTIFICATION hat drei Parameter:

• TYPE: die gewünschte Art der Notification Integration (EMAIL, QUEUE)
• ENABLED: TRUE oder FALSE
• ALLOWED_RECIPIENTS: bis zu 10 verifizierte E-Mail-Adressen, an die zugestellt werden soll

Sobald die Notification Integration steht, möchten Sie womöglich weiteren Rollen das Nutzungsrecht erteilen, damit auch diese E-Mails verschicken können.

1GRANT USAGE ON INTEGRATION my_email_int TO ROLE my_developer_role;

Sobald eine Notification Integration mit mindestens einer verifizierten E-Mail-Adresse existiert, lassen sich E-Mails versenden.

E-Mails manuell aus Snowflake auslösen

Die Prozedur SYSTEM$SEND_EMAIL wird – wie jede andere Stored Procedure – mit dem Schlüsselwort CALL aufgerufen. Ein Beispiel:

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'

Wie Sie sehen, wird die E-Mail-Adresse im Funktionsaufruf erneut angegeben. Stünde sie nicht in der Eigenschaft ALLOWED_RECIPIENTS der Notification Integration, würde keine E-Mail versendet.

So sieht die E-Mail aus, die der Befehl oben auslöst:

Wird die Stored Procedure erfolgreich ausgeführt, liefert sie **TRUE** zurück:

E-Mails automatisch aus Snowflake auslösen

Die meisten Snowflake-Kunden möchten ein automatisiertes Alerting einrichten. Wie funktioniert das?

Ein gängiges Muster ist es, die Stored Procedure SYSTEM$SEND_EMAIL in eine andere Prozedur einzubetten. Diese prüft zunächst, ob eine bestimmte Bedingung erfüllt ist, und ruft – falls ja – SYSTEM$SEND_EMAIL auf, um die E-Mails zu versenden.

Welche Bedingungen kommen dafür in Frage?

• Monitoring von Snowflake Tasks: Wurde der Task pausiert?
• Monitoring von Snowflake Streams: Ist ein Stream zu früh "stale" geworden?
• Validierung bestimmter Business-Regeln (etwa: Nutzer muss zahlender Kunde sein, um Feature X zu verwenden)

Nehmen wir das Task-Monitoring als Beispiel. Sie haben einen Task oder Task-Baum, der nach einem festen Zeitplan laufen soll. Sie möchten erfahren, wenn ein Task pausiert wurde und damit nicht mehr läuft. Genau das passiert immer dann, wenn ein Task geändert wird – denn vor der Änderung muss er pausiert und danach wieder aktiviert werden.

Um pausierte Tasks zu erkennen, legen wir eine Stored Procedure namens task_state_monitoring an. Sie prüft den Zustand des jeweiligen Tasks und versendet bei pausiertem Zustand eine E-Mail. Die Prozedur listet zunächst per show tasks alle Tasks auf, durchläuft sie dann in einer Schleife und prüft, ob die aktuelle Variable state des Tasks den Wert 'suspended' hat. Für jeden pausierten Task wird eine E-Mail versendet.

Der Code einer solchen Prozedur kann so aussehen:

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

Code ausklappen

Für das Deployment dieser Stored Procedure legen Sie einen Snowflake Task an, der die Prozedur task_state_monitoring nach beliebigem Zeitplan aufruft (etwa alle 5 Minuten, zweimal täglich usw.).

Ein weiteres leistungsfähiges Notification-Feature sind Snowflake Alerts. Dabei handelt es sich um ein Objekt auf Schema-Ebene, mit dem Sie auf unterschiedliche Situationen in Ihren Daten oder ganz allgemein in Ihrem Snowflake-Account reagieren können.

Ein typischer Anwendungsfall ist Cost Alerting. So lässt sich beispielsweise ein Alert anlegen, der erkennt, wenn der Credit-Verbrauch eines Accounts für ein einzelnes Virtual Warehouse oder einen anderen Snowflake-Service sprunghaft ansteigt. Ein weiterer Anwendungsfall ist die Prüfung von Business-Regeln, kombiniert mit einer Benachrichtigung bei fehlgeschlagener Validierung. Alerts sind dabei nicht aufs Versenden einer E-Mail beschränkt: Schlägt eine Validierung fehl, können Sie etwa einen Eintrag mit Zeitstempel, Validierungstyp und Fehlerbeschreibung in eine Log-Tabelle schreiben.

Ein Snowflake Alert besteht aus drei Komponenten:

• einer Condition, die den Alert auslöst (z. B. Query liefert keine Datensätze)
• einer Action, die festlegt, was bei erfüllter Bedingung passieren soll (z. B. E-Mail senden, Datensatz in eine Tabelle schreiben)
• einer Frequency, die festlegt, wie oft die Bedingung ausgewertet wird (z. B. alle 24 Stunden)

Wie legt man einen Snowflake Alert an?

Für dieses Beispiel erstellen wir einen Snowflake Alert, der uns per E-Mail benachrichtigt, sobald der tägliche Credit-Verbrauch in Snowflake 100 Credits überschreitet.

Hier der Code für den Alert, der stündlich läuft:

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

))

Code ausklappen

Gehen wir den Code Schritt für Schritt durch:

• Wir geben ein Virtual Warehouse an – hier COMPUTE_WH –, das den Alert ausführt.
• Über die CRON-Syntax legen wir einen Zeitplan fest, der den Alert täglich um 1:00 Uhr UTC startet.
• Als Condition dient eine SQL-Query, die genau eine Zeile mit dem Wert "1" zurückgibt, wenn der Snowflake-Credit-Verbrauch in den letzten 24 Stunden über 100 lag.
• Als Action rufen wir die Prozedur SYSTEM$SEND_EMAIL auf.

Nach dem erfolgreichen Anlegen müssen wir den Alert noch aktivieren, sonst läuft er nicht:

alter alert credits_consumption resume;

Damit ist der Alert produktiv.

Alerts-Monitoring

Snowflake stellt im Schema ACCOUNT_USAGE die View ALERT_HISTORY bereit, mit der Sie die Alert-Ausführungen überwachen können:

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

Die View bietet einen Überblick über jede Alert-Ausführung samt der query_ids, die zur Auswertung der Alert-Bedingung (CONDITION_QUERY_ID) und zur Ausführung der zugehörigen Action gehören (ACTION_QUERY_ID, also die Query, die SYSTEM$SEND_EMAIL auslöst).

Wichtig: Action- und Condition-Queries tauchen in der QUERY_HISTORY nicht auf. Um sie einzusehen, müssen Sie die Funktion RESULT_SCAN verwenden:

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

Wie werden Snowflake Alerts abgerechnet?

Weder für den E-Mail-Versand noch für die Snowflake Alerts selbst fallen zusätzliche Kosten an. Bezahlt wird ausschließlich die Compute-Zeit, die das angegebene Virtual Warehouse für die Validierungs- und Action-Queries benötigt.

Vorteile von Snowflake Alerts

Snowflake Alerts vereinfachen die Prüfung von Business-Logik und das Auslösen passender Aktionen erheblich. Um E-Mail-Benachrichtigungen über SYSTEM$SEND_EMAIL zu versenden, mussten wir bisher eine separate Stored Procedure schreiben, die explizit SQL ausführt, das Ergebnis verarbeitet und die Prüfungen durchläuft, bevor die E-Mail rausgeht. Anschließend brauchten wir einen separaten Task, der diese Prozedur nach Zeitplan aufruft.

Mit Snowflake Alerts werden all diese Schritte in einem einzigen Alert-Objekt zusammengefasst.

Viele Anwender möchten Benachrichtigungen lieber in einem Team-Channel in Slack erhalten als per E-Mail. Das beschleunigt Zusammenarbeit und Reaktion auf den Alert. Da Slack das Senden von E-Mails an einen Channel über eine dedizierte E-Mail-Adresse unterstützt, können wir unsere Snowflake Notification Integration genau mit dieser Channel-Adresse einrichten.

Schritt 1: E-Mail-Adresse für den Slack-Channel erstellen

Zunächst legen wir in unserem Slack-Channel eine neue Integration an, um eine nutzbare E-Mail-Adresse zu erhalten. Klicken Sie in den Channel-Einstellungen auf "Integrationen" und anschließend auf "E-Mails an diesen Channel senden":

Schritt 2: Bestätigung von Slack erhalten

Nach Abschluss dieses Schritts schickt Slack automatisch eine Nachricht in Ihren Channel:

Schritt 3: Snowflake-User mit Slack-E-Mail-Adresse anlegen

Da Snowflake E-Mails ausschließlich an verifizierte Snowflake-User sendet, legen wir in Snowflake einen neuen User an und weisen ihm die E-Mail-Adresse aus Slack zu. Anschließend muss diese Adresse verifiziert werden.

Schritt 4: Snowflake-E-Mail in Slack verifizieren

Die Verifizierungs-E-Mail wird von Snowflake direkt an den Slack-Channel gesendet. Dort klicken Sie auf den Link und bestätigen die Adresse für die spätere Nutzung in der Stored Procedure SYSTEM$SEND_EMAIL(). So sieht die Verifizierungs-E-Mail von Snowflake in Slack aus:

Beim Anlegen der Notification Integration haben wir den Parameter TYPE zuvor auf EMAIL gesetzt. Dieser Parameter unterstützt aber auch QUEUE. Mit QUEUE lassen sich Benachrichtigungen aus Snowflake an andere Cloud-Messaging-Dienste wie Amazon SNS, Google Pub/Sub oder Microsoft Azure Event Grid weiterleiten.

Diese Funktion spielt hervorragend mit dem Parameter ERROR_INTEGRATION in Snowflake Tasks oder Snowpipe zusammen. ERROR_INTEGRATION akzeptiert eine Notification Integration vom Typ QUEUE. Mehr dazu lesen Sie im Blogbeitrag zu Error Notifications für Snowflake Tasks.

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

Tomas ist langjähriger Snowflake Data SuperHero und ausgewiesener Snowflake-Experte. Seine über zehnjährige Erfahrung in der Datenwelt umfasst Rollen als Snowflake Data Engineer, Architect und Admin in unterschiedlichsten Projekten, Branchen und Technologien. Tomas ist ein zentrales Community-Mitglied, das sein Wissen aktiv teilt und andere inspiriert. Außerdem ist er O'Reilly-Instructor und leitet Live-Online-Trainings.