Snowflakeのデータに基づくアラートの設定¶

概要¶

場合によっては、Snowflakeのデータが特定の条件を満たしたときに、通知を受信するか、アクションを実行することができます。たとえば、次の場合に通知を受信できるようにします。

• ウェアハウスのクレジット使用状況が、現在のクォータの指定された割合だけ増加したとき。

• パイプライン、タスク、マテリアライズドビューなどのリソース消費が、指定された量を超えて増加したとき。

• データが、設定した特定のビジネスルールに準拠していないとき。

これを実行するには、Snowflakeアラートを設定できます。Snowflakeアラートは、以下を指定するスキーマレベルのオブジェクトです。

• アラートをトリガーする条件（例: 完了するまでに1秒以上かかるクエリの存在）。

• 条件が満たされたときに実行するアクション（例: メール通知を送信する、テーブル内のデータをキャプチャする、など）。

• 条件を評価する時期と頻度（例: 24時間ごと、毎週日曜日の深夜、など）。

たとえば、クレジット消費がウェアハウスの特定の制限を超えたときにメール通知を送信するとします。これを30分ごとにチェックするとします。次のプロパティを使用してアラートを作成できます。

• 条件: ウェアハウス（ACCOUNT_USAGE にある WAREHOUSE_METERING_HISTORY ビューの credits_used 列の合計）スキーマのクレジット消費量が、指定された制限を超えている。

• アクション: 管理者にメールを送信する。

• 頻度/スケジュール: 30分ごとにこの条件をチェックする。

アラートタイプの選択¶

以下のタイプのアラートを作成できます。

• スケジュールのアラート: Snowflakeは、スケジュールに基づいて既存のデータに対して条件を評価します。

  例えば、テーブルの既存の行に指定した値を超える列があるかどうかをチェックするアラートをスケジュールにセットできます。

• 新しいデータのアラート: Snowflakeは、指定したテーブルまたはビュー内の新しい行に対して条件を評価します。

  例えば、エラーメッセージの新しい行がアカウントの イベントテーブル に挿入された場合に通知するアラートを新しいデータにセットできます。動的なテーブルの更新やタスクの実行によりイベントテーブルに対してイベントがログ記録されるため、アラートを新しいデータにをセットアップできます。

  • 動的テーブルの更新を監視します。

  • タスク実行を監視します。

アラート用ウェアハウスの選択¶

アラートの実行には ウェアハウス が必要です。 サーバーレスコンピューティングモデル を使うか、 指定したバーチャルウェアハウス を使います。

警告のコストの理解¶

SQLコードを実行するためにアラートを実行することに関連するコストは、アラートに使用されるコンピューティングリソースによって異なります。

• サーバーレスアラートでは、Snowflakeはコンピューティングリソースの使用量に基づいてアカウントに請求します。料金は、 コンピューティング時間 のクレジット使用状況で測定されたリソースの合計使用状況（クラウドサービスの使用状況を含む）に基づいて計算されます。計算時間はウェアハウスのサイズとクエリの実行時間によって変わります。詳細については、 サーバーレスのクレジット使用状況 をご参照ください。

  アラートにより消費されたクレジット量を知る方法については、 Snowflakeサービス利用テーブル の「サーバーレス機能クレジットテーブル」をご参照ください。

  サーバーレスアラートの使用履歴を表示するには、以下の方法があります。

  • SERVERLESS_ALERT_HISTORY 関数を呼び出す。

  • SERVERLESS_ALERT_HISTORY ビュー をクエリする。

• 指定した仮想ウェアハウスを使用するアラートについては、Snowflakeは、アラート実行中のウェアハウスの使用状況に基づいて、 クレジット使用状況 をアカウントに請求します。これは、クライアントや Snowsight で同じ SQL ステートメントを実行するウェアハウスの使い方に似ています。秒あたりのクレジット請求と自動中断により、より大きなウェアハウスサイズから始めて、アラートワークロードに合わせてサイズを調整する柔軟性が得られます。

アラートを作成する権限の付与¶

アラートを作成するには、次の権限を持つロールを使用する必要があります。

• アカウントに対する EXECUTE ALERT 権限。

  注釈

  この権限は、 ACCOUNTADMIN ロールを持つユーザーのみが付与できます。

• 次の権限のいずれかです。

  • サーバーレスアラートを作成する場合は、アカウントのEXECUTEMANAGEDALERT権限。

  • アラートに仮想ウェアハウスを指定している場合は、アラートの実行に使用されるウェアハウスのUSAGE権限。

• アラートを作成するスキーマに対する USAGE および CREATE ALERT 権限。

• スキーマを含むデータベースに対する USAGE 権限。

• アラート条件でクエリするテーブルまたはビューのSELECT権限（新しいデータのアラート を作成する場合）。

これらの権限をロールに付与するには、 GRANT <権限> ... TO ROLE コマンドを使用します。

たとえば、 my_schema という名前のスキーマでアラートを作成する権限を持つ、 my_alert_role という名前のカスタムロールを作成するとします。アラートでウェアハウス my_warehouse を使用するとします。

これを実行するには、

1. ACCOUNTADMIN ロールを持つユーザーに、次を実行してもらいます。

   1. カスタムロールを作成します。

      例:

      USE ROLE ACCOUNTADMIN;
      
      CREATE ROLE my_alert_role;
      

      Copy

   2. そのカスタムロールに EXECUTE ALERT グローバル権限を付与します。

      例:

      GRANT EXECUTE ALERT ON ACCOUNT TO ROLE my_alert_role;
      

      Copy

   3. サーバレスアラートを作成したい場合は、EXECUTEMANAGEDALERTグローバル権限をそのカスタムロールに付与してください。

      例:

      GRANT EXECUTE MANAGED ALERT ON ACCOUNT TO ROLE my_alert_role;
      

      Copy

   4. ユーザーにカスタムロールを付与します。

      例:

      GRANT ROLE my_alert_role TO USER my_user;
      

      Copy

2. データベース、スキーマ、およびウェアハウスの所有者により、アラートの作成に必要な権限をカスタムロールに付与してもらいます。

   • スキーマの所有者は、スキーマに対する CREATE ALERT および USAGE 権限を付与する必要があります。

     GRANT CREATE ALERT ON SCHEMA my_schema TO ROLE my_alert_role;
     GRANT USAGE ON SCHEMA my_schema TO ROLE my_alert_role;
     

     Copy

   • データベースの所有者は、データベースに対する USAGE 権限を付与する必要があります。

     GRANT USAGE ON DATABASE my_database TO ROLE my_alert_role;
     

     Copy

   • アラートにウェアハウスを指定する場合は、そのウェアハウスの所有者がUSAGE権限を付与する必要があります。

     GRANT USAGE ON WAREHOUSE my_warehouse TO ROLE my_alert_role;
     

     Copy

アラートの作成¶

以下のセクションでは、各種のアラートタイプを作成するための基本的な手順と例を示します。

• スケジュールのアラート作成

• 新しいデータのアラートの作成

アラートスケジュールに基づくタイムスタンプの指定¶

場合によっては、アラートスケジュールに基づいて条件またはアクションを定義する必要があります。

たとえば、テーブルに行が追加された時刻を表すタイムスタンプ列があり、正常に評価された最後のアラートと現在スケジュールされているアラートの間に新しい行が追加された場合にアラートを送信するとします。つまり、以下を評価します。

<now> - <last_execution_of_the_alert>

CURRENT_TIMESTAMP とアラートのスケジュールされた時刻を使用してこの時間範囲を計算する場合、計算された範囲には、アラートがスケジュールされた時刻とアラート条件が実際に評価される時刻との間の待ち時間が考慮されません。

代わりに、現在のスケジュールアラートと正常に評価された最後のアラートのタイムスタンプが必要な場合は、次の関数を使用します。

• SCHEDULED_TIME は、現在のアラートがいつスケジュールされたかを表すタイムスタンプを返します。

• LAST_SUCCESSFUL_SCHEDULED_TIME は、最後に正常に評価されたアラートがスケジュールされた時刻を表すタイムスタンプを返します。

これらの関数は、 SNOWFLAKE.ALERT スキーマ で定義されています。これらの関数を呼び出すには、 SNOWFLAKE.ALERT_VIEWER データベースロール が付与されたロールを使用する必要があります。このロールを別のロールに付与するには、 GRANT DATABASE ROLE コマンドを使用します。たとえば、このロールをカスタムロール alert_role に付与するには、次を実行します。

GRANT DATABASE ROLE SNOWFLAKE.ALERT_VIEWER TO ROLE alert_role;

次の例では、正常に評価されたアラートが最後にスケジュールされてから現在のアラートがスケジュールされているまでの間に新しい行が my_table に追加された場合に、メールメッセージを送信します。

CREATE OR REPLACE ALERT alert_new_rows
  WAREHOUSE = my_warehouse
  SCHEDULE = '1 MINUTE'
  IF (EXISTS (
      SELECT *
      FROM my_table
      WHERE row_timestamp BETWEEN SNOWFLAKE.ALERT.LAST_SUCCESSFUL_SCHEDULED_TIME()
       AND SNOWFLAKE.ALERT.SCHEDULED_TIME()
  ))
  THEN CALL SYSTEM$SEND_EMAIL(...);

アラートアクションの条件に対するSQLステートメントの結果のチェック¶

アラートのアクションの中で、 SQL ステートメントの結果をチェックする必要がある場合:

1. GET_CONDITION_QUERY_UUID 関数を呼び出して、 SQL ステートメントの条件に対するクエリ ID を取得します。

2. クエリ ID を RESULT_SCAN 関数に渡して、 SQL ステートメントの実行結果を取得します。

例:

CREATE ALERT my_alert
  WAREHOUSE = my_warehouse
  SCHEDULE = '1 MINUTE'
  IF (EXISTS (
    SELECT * FROM my_source_table))
  THEN
    BEGIN
      LET condition_result_set RESULTSET :=
        (SELECT * FROM TABLE(RESULT_SCAN(SNOWFLAKE.ALERT.GET_CONDITION_QUERY_UUID())));
      ...
    END;

手動によるアラートの実行¶

場合によっては、手動でアラートを実行する必要があります。例:

• 新しいアラートを作成する場合、アラートが期待通りに機能するかどうかを確認することをお勧めします。

• データパイプラインの特定のポイントでアラートを実行したい場合があります。たとえば、ストアドプロシージャの呼び出しの最後にアラートを実行したい場合です。

アラートを手動で実行するには、 EXECUTE ALERT コマンドを実行します。

EXECUTE ALERT my_alert;

EXECUTE ALERT コマンドは、アラート用に定義されたスケジュールとは無関係に、アラートの単一実行を手動でトリガーします。

このコマンドはインタラクティブに実行できます。このコマンドは、ストアドプロシージャまたはSnowflakeスクリプトブロック内から実行することもできます。

このコマンドを実行するために必要な権限と、中断、実行中、およびスケジュールされたアラートに対するこのコマンドの効果の詳細については、 EXECUTE ALERT を参照してください。

アラートの中断と再開¶

アラートが一時的に実行されないようにする必要がある場合は、 ALTER ALERT ... SUSPEND コマンドを実行してアラートを中断できます。例:

ALTER ALERT my_alert SUSPEND;

中断したのアラートを再開するには、 ALTER ALERT ... RESUME コマンドを実行します。例:

ALTER ALERT my_alert RESUME;

アラートの変更¶

アラートのプロパティを変更するには、 ALTER ALERT コマンドを実行します。

例:

• my_alert という名前のアラートのウェアハウスを my_other_warehouse に変更するには、次のコマンドを実行します。

  ALTER ALERT my_alert SET WAREHOUSE = my_other_warehouse;
  

  Copy

• my_alert という名前のアラートが2分ごとに評価されるようにスケジュールを変更するには、次のコマンドを実行します。

  ALTER ALERT my_alert SET SCHEDULE = '2 minutes';
  

  Copy

• my_alert という名前のアラートの条件を変更して、 gauge という名前のテーブルにある行の gauge_value 列に 300 より大きい値がある場合にアラートを受け取るようにするには、次のコマンドを実行します。

  ALTER ALERT my_alert MODIFY CONDITION EXISTS (SELECT gauge_value FROM gauge WHERE gauge_value>300);
  

  Copy

• my_alert という名前のアラートのアクションを CALL my_procedure() に変更するには、次のコマンドを実行します。

  ALTER ALERT my_alert MODIFY ACTION CALL my_procedure();
  

  Copy

アラートのドロップ¶

アラートをドロップするには、 DROP ALERT コマンドを実行します。例:

DROP ALERT my_alert;

アラートが存在しない場合にエラーを出さずにアラートをドロップするには、次のように実行します。

DROP ALERT IF EXISTS my_alert;

アラートに関する詳細の表示¶

アカウント、データベース、またはスキーマで作成されたアラートをリストするには、 SHOW ALERTS コマンドを実行します。たとえば、現在のスキーマで作成されたアラートをリストするには、次のコマンドを実行します。

SHOW ALERTS;

このコマンドは、自分が所有するアラートと、 MONITOR または OPERATE 権限を持つアラートをリストします。

特定のアラートに関する詳細を表示するには、 DESCRIBE ALERT コマンドを実行します。例:

DESC ALERT my_alert;

アラーとのクローニング¶

アラートをクローンすることができます（CREATE ALERT ... CLONE を使用するか、アラートを含むデータベースまたはスキーマをクローンします）。

サーバレスアラートのクローンを作成する場合、グローバルEXECUTEMANAGEDALERT権限を持つロールを使用する必要はありません。ただし、アラートを所有するロールにEXECUTEMANAGEDALERT権限が付与されるまでは、そのアラートを再開することはできません。

アラートの実行のモニター¶

アラートの実行をモニターするには、次を実行します。

• アラートに対して指定されたアクションの結果を確認します。たとえば、アクションによってテーブルに行が挿入された場合は、テーブルに新しい行があるかどうかを確認できます。

• 次のいずれかを使用して、アラート実行の履歴を表示します。

  • INFORMATION_SCHEMA スキーマの ALERT_HISTORY テーブル関数をクエリします。

    たとえば、過去1時間のアラートの実行を表示するには、次のステートメントを実行します。

    SELECT *
    FROM
      TABLE(INFORMATION_SCHEMA.ALERT_HISTORY(
        SCHEDULED_TIME_RANGE_START
          =>dateadd('hour',-1,current_timestamp())))
    ORDER BY SCHEDULED_TIME DESC;
    

    Copy

  • 共有 SNOWFLAKE データベースにある ACCOUNT_USAGE スキーマの ALERT_HISTORY ビューをクエリします。

クエリ履歴では、クエリを実行したユーザーの名前は SYSTEM になります。（アラートは システムサービス によって実行されます。）

サーバーレスアラートのクエリ履歴の表示¶

サーバーレスアラートのクエリ履歴を表示するには、アラートの所有者であるか、アラート自体のMONITORまたはOPERATE権限を持つロールを使用する必要があります。(これは、ウェアハウスのMONITORまたはOPERATOR権限を必要とする、ウェアハウスを使用するアラートとは異なります)。

たとえば、アラート my_alert のクエリ履歴を表示する際に my_alert_role ロールを使用するとします。 my_alert_role が my_alert の所有者でない場合、そのロールに警告に対する MONITOR または OPERATE 権限を 付与 する必要があります。

GRANT MONITOR ON ALERT my_alert TO ROLE my_alert_role;

ロールにこの権限が付与されると、そのロールを使用してアラートのクエリ履歴を表示できます。

USE ROLE my_alert_role;

SELECT query_text FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
  WHERE query_text LIKE '%Some condition%'
    OR query_text LIKE '%Some action%'
  ORDER BY start_time DESC;