動的テーブルのイベントテーブル監視とアラート¶

このトピックでは、リフレッシュステータスに関する情報を提供するイベントテーブルをクエリする方法と、イベントテーブルの新しいデータに関するアラートをセットアップする方法について説明します。

リフレッシュを監視するためにイベントテーブルをクエリします。¶

動的テーブルがリフレッシュされたときに、リフレッシュ操作のステータスに関する情報を提供するイベントを記録するようにSnowflakeを構成できます。イベントは、動的テーブルに関連付けられたアクティブイベントテーブルに記録されます。

例えば、イベントテーブルをデータベースに関連付けたとします。データベースの動的テーブルが更新されると、Snowflakeはそのイベントテーブルにイベントを記録します。

このアクティブ・イベント・テーブルにログ記録されたイベントをクエリして、動的テーブルの更新を監視できます。

たとえば、データベース my_db の動的テーブルを使用したエラーについて、タイムスタンプ、動的テーブル名、クエリ ID、およびエラーメッセージを取得するには、以下のようにします。

SELECT
    timestamp,
    resource_attributes:"snow.executable.name"::VARCHAR AS dt_name,
    resource_attributes:"snow.query.id"::VARCHAR AS query_id,
    value:message::VARCHAR AS error
  FROM my_event_table
  WHERE
    resource_attributes:"snow.executable.type" = 'DYNAMIC_TABLE' AND
    resource_attributes:"snow.database.name" = 'MY_DB' AND
    value:state = 'FAILED'
  ORDER BY timestamp DESC;

+-------------------------+------------------+--------------------------------------+---------------------------------------------------------------------------------+
| TIMESTAMP               | DT_NAME          | QUERY_ID                             | ERROR                                                                           |
|-------------------------+------------------+--------------------------------------+---------------------------------------------------------------------------------|
| 2025-02-17 21:40:45.444 | MY_DYNAMIC_TABLE | 01ba7614-0107-e56c-0000-a995024f304a | SQL compilation error:                                                          |
|                         |                  |                                      | Failure during expansion of view 'MY_DYNAMIC_TABLE': SQL compilation error:     |
|                         |                  |                                      | Object 'MY_DB.MY_SCHEMA.MY_BASE_TABLE' does not exist or not authorized.        |
+-------------------------+------------------+--------------------------------------+---------------------------------------------------------------------------------+

以下の例は、スキーマ my_schema の動的テーブルを持つアップストリーム・エラーの全列を取得します。

SELECT *
  FROM my_event_table
  WHERE
    resource_attributes:"snow.executable.type" = 'DYNAMIC_TABLE' AND
    resource_attributes:"snow.schema.name" = 'MY_SCHEMA' AND
    value:state = 'UPSTREAM_FAILURE'
  ORDER BY timestamp DESC;

+-------------------------+-----------------+-------------------------+-------+----------+-------------------------------------------------+-------+------------------+-------------+-----------------------------+-------------------+-------------------------------+-----------+
| TIMESTAMP               | START_TIMESTAMP | OBSERVED_TIMESTAMP      | TRACE | RESOURCE | RESOURCE_ATTRIBUTES                             | SCOPE | SCOPE_ATTRIBUTES | RECORD_TYPE | RECORD                      | RECORD_ATTRIBUTES | VALUE                         | EXEMPLARS |
|-------------------------+-----------------+-------------------------+-------+----------+-------------------------------------------------+-------+------------------+-------------+-----------------------------+-------------------+-------------------------------+-----------|
| 2025-02-17 21:40:45.486 | NULL            | 2025-02-17 21:40:45.486 | NULL  | NULL     | {                                               | NULL  | NULL             | EVENT       | {                           | NULL              | {                             | NULL      |
|                         |                 |                         |       |          |   "snow.database.id": 49,                       |       |                  |             |   "name": "refresh.status", |                   |   "state": "UPSTREAM_FAILURE" |           |
|                         |                 |                         |       |          |   "snow.database.name": "MY_DB",                |       |                  |             |   "severity_text": "WARN"   |                   | }                             |           |
|                         |                 |                         |       |          |   "snow.executable.id": 487426,                 |       |                  |             | }                           |                   |                               |           |
|                         |                 |                         |       |          |   "snow.executable.name": "MY_DYNAMIC_TABLE_2", |       |                  |             |                             |                   |                               |           |
|                         |                 |                         |       |          |   "snow.executable.type": "DYNAMIC_TABLE",      |       |                  |             |                             |                   |                               |           |
|                         |                 |                         |       |          |   "snow.owner.id": 2601,                        |       |                  |             |                             |                   |                               |           |
|                         |                 |                         |       |          |   "snow.owner.name": "DATA_ADMIN",              |       |                  |             |                             |                   |                               |           |
|                         |                 |                         |       |          |   "snow.owner.type": "ROLE",                    |       |                  |             |                             |                   |                               |           |
|                         |                 |                         |       |          |   "snow.schema.id": 411,                        |       |                  |             |                             |                   |                               |           |
|                         |                 |                         |       |          |   "snow.schema.name": "MY_SCHEMA"               |       |                  |             |                             |                   |                               |           |
|                         |                 |                         |       |          | }                                               |       |                  |             |                             |                   |                               |           |
+-------------------------+-----------------+-------------------------+-------+----------+-------------------------------------------------+-------+------------------+-------------+-----------------------------+-------------------+-------------------------------+-----------+

イベントテーブルをクエリするために必要なロールや、結果をフィルターするために使用できる条件については、新しいデータのアラート設定を参照してください。

新しいデータに対するアラートをセットし、更新を監視します。¶

前述したように、動的テーブルがリフレッシュされると、リフレッシュが成功したか失敗したかを示すイベントがイベント・テーブルにログ記録されます。イベントテーブルを監視するために、新しいデータに対してアラートをセットすることができます。リフレッシュが失敗したときに通知を送信するようにアラートを構成できます。

次のセクションでは、イベントをキャプチャするためのイベントログのセットアップ方法、アラートのセットアップ方法、イベントテーブルに記録されたイベントの解釈方法について説明します。

キャプチャするイベントの重大度レベルのセット
新しいデータのアラート設定
動的テーブルイベントのログ情報

注釈

動的テーブルのイベントのログにはコストがかかります。テレメトリーデータ収集の費用をご参照ください。

キャプチャするイベントの重大度レベルのセット¶

注釈

重大度レベルをセットしないと、イベントはキャプチャされません。

イベント・テーブルに記録する動的テーブル・イベントを設定するには、イベント・テーブルに記録するイベントの重大度レベルをセットします。イベントは以下のレベルで捕捉されます。

ERROR: 失敗イベントをリフレッシュします。
WARN: アップストリーム動的テーブルのリフレッシュ失敗およびリフレッシュ失敗イベント。
INFO: リフレッシュ成功イベント、アップストリーム動的テーブルのリフレッシュ失敗イベント、リフレッシュ失敗イベント。

レベルを設定するには、アカウントまたはオブジェクトの LOG_EVENT_LEVEL パラメーターを設定します。次のレベルを設定できます。

アカウント内のすべてのオブジェクト。
データベースまたはスキーマ内のすべてのオブジェクト。
特定の動的テーブル。

例:

アカウントでサポートされているすべてのオブジェクトに対して ERROR レベルの動的テーブルイベントをキャプチャするには、 ALTER ACCOUNT SET LOG_EVENT_LEVEL を実行します。
```
ALTER ACCOUNT SET LOG_EVENT_LEVEL = ERROR;
```
アカウントレベルでの LOG_EVENT_LEVEL の設定は、動的テーブルを含む、アカウントでサポートされているワークロードのログイベント（記録タイプ EVENT ）に適用されます。APIs のロギングによるログメッセージに関する LOG_LEVEL は置き換えられません。詳細については、パラメーターをご参照ください。
my_db データベースでサポートされているすべてのオブジェクトの INFO レベルのイベントをキャプチャするには、 ALTER DATABASE ... SET LOG_EVENT_LEVEL を実行します。
```
ALTER DATABASE my_db SET LOG_EVENT_LEVEL = INFO;
```
アカウントにレベルを設定する場合と同様に、データベースにレベルを設定すると、データベース内でサポートされているオブジェクトタイプのログイベントに影響します。
my_dynamic_table 動的テーブルのWARN レベルのイベントをキャプチャするには、 ALTER DYNAMIC TABLE ... SET LOG_EVENT_LEVEL を実行します。
```
ALTER DYNAMIC TABLE my_dynamic_table SET LOG_EVENT_LEVEL = WARN;
```

新しいデータのアラート設定¶

ログ・イベントの重大度レベルを設定した後、動的なテーブル更新の失敗を示す新しいイベントをイベント・テーブルで監視するために、新しいデータに対するアラートを設定できます。新しいデータに関するアラートは、イベントテーブルの新しい行が挿入され、アラートで指定された条件を満たすとトリガーされます。

注釈

新しいデータに対してアラートを作成するには、イベント・テーブルをクエリするために必要な権限を付与されたロールを使用する必要があります。

アラート条件がデフォルトのイベントテーブル (SNOWFLAKE.TELEMETRY.EVENTS) または定義済みのビュー (SNOWFLAKE.TELEMETRY.EVENTS_VIEW ビュー) にクエリする場合は、デフォルトのイベント・テーブルと EVENTS_VIEW へのアクセスのロールを参照してください。

EVENTS_VIEW 表示へのアクセスを管理するには、 EVENTS_VIEW 表示へのアクセス管理を参照してください。
アラート条件がカスタムイベントテーブルにクエリする場合は、イベントテーブルのアクセス制御権限を参照してください。

カスタムイベントテーブルへのアクセスを管理するには、イベントテーブルデータへのアクセスの管理を参照してください。

resource_attributes:"snow.executable.type" = 'DYNAMIC_TABLE' アラート条件では、動的テーブル・イベントをクエリするには、行を選択します。イベントリストを絞り込むには、以下の列でフィルターをかけることができます。

結果を特定のデータベース内の動的テーブルに限定するには、 resource_attributes:"snow.database.name" を使用します。
動的テーブルのエラーによりリフレッシュに失敗したイベントを返すには、 value:state = 'FAILED' を使用します。
上流の動的テーブルでエラーが発生し、リフレッシュに失敗したイベントを返すには、 value:state = 'UPSTREAM_FAILURE' を使用します。

動的テーブル・イベントでログに記録される値に関する情報は、動的テーブルイベントのログ情報を参照してください。

注釈

イベントテーブルの timestamp 列は、値をUTCで格納します。タイムスタンプフィルターでスケジュールされたアラートを使用する場合（例: timestamp > DATEADD('minute', -5, CURRENT_TIMESTAMP()) ）、正確な比較を行うために現在のタイムスタンプをUTCに変換します。

timestamp > DATEADD('minute', -5, CONVERT_TIMEZONE('UTC', CURRENT_TIMESTAMP()))

例えば、次のステートメントは、データベース my_db 内の動的テーブルのリフレッシュに失敗した場合にアクションを実行する新しいデータに対するアラートを作成します。例では次を前提としています。

アクティブなイベントテーブルがデフォルトのイベントテーブル（SNOWFLAKE.TELEMETRY.EVENTS）になる。
そのSlackチャンネルに対して Webhook通知統合をセットしている。

CREATE ALERT my_alert_on_dt_refreshes
  IF( EXISTS(
    SELECT * FROM SNOWFLAKE.TELEMETRY.EVENT_TABLE
      WHERE resource_attributes:"snow.executable.type" = 'dynamic_table'
        AND resource_attributes:"snow.database.name" = 'my_db'
        AND record:"name" = 'refresh.status'
        AND record:"severity_text" = 'ERROR'
        AND value:"state" = 'FAILED'))
  THEN
    BEGIN
      LET result_str VARCHAR;
      (SELECT ARRAY_TO_STRING(ARRAY_AGG(name)::ARRAY, ',') INTO :result_str
         FROM (
           SELECT resource_attributes:"snow.executable.name"::VARCHAR name
             FROM TABLE(RESULT_SCAN(SNOWFLAKE.ALERT.GET_CONDITION_QUERY_UUID()))
             LIMIT 10
         )
      );
      CALL SYSTEM$SEND_SNOWFLAKE_NOTIFICATION(
        SNOWFLAKE.NOTIFICATION.TEXT_PLAIN(:result_str),
        '{"my_slack_integration": {}}'
      );
    END;

動的テーブルイベントのログ情報¶

動的テーブルが更新されると、イベントがイベント・テーブルにログ記録されます。以下のセクションでは、イベントを表すイベント・テーブル行について説明します。

イベントテーブル列値
resource_attributes 列のキー値・ペア
record 列のキー値・ペア

イベントテーブル列値¶

動的テーブルが更新されると、以下の値を持つ行がイベント・テーブルに挿入されます。

注釈

列が以下にリストされていない場合、その列の値はイベントに対して NULL です。


列	データ型	説明
`timestamp`	TIMESTAMP_NTZ	イベント作成時の UTC タイムスタンプ。
`observed_timestamp`	TIMESTAMP_NTZ	ログに使用される時間は UTC です。現在、これは `timestamp` 列にある値と同じです。
`resource_attributes`	OBJECT	リフレッシュされた動的テーブルを識別する属性。
`record_type`	STRING	イベントタイプ、 `EVENT` 動的テーブル・リフレッシュ用です。
`record`	OBJECT	動的テーブルのリフレッシュのステータスについての詳細。
`value`	VARIANT	動的テーブルのリフレッシュと、リフレッシュに失敗した場合はそのエラー・メッセージのステータス。

`resource_attributes` 列のキー値・ペア¶

resource_attributes 列には、以下のキー値ペアを持つ OBJECT 値が含まれます。


属性名	属性タイプ	説明	例
`snow.database.id`	INTEGER	動的テーブルを含むデータベースの内部/システム生成識別子。	`12345`
`snow.database.name`	VARCHAR	動的テーブルを含むデータベース名。	`MY_DATABASE`
`snow.executable.id`	INTEGER	リフレッシュされた動的テーブルの内部/システム生成識別子。	`12345`
`snow.executable.name`	VARCHAR	リフレッシュされた動的テーブルの名前。	`MY_DYNAMIC_TABLE`
`snow.executable.type`	VARCHAR	オブジェクトのタイプ。動的テーブル・イベントの値は `DYNAMIC_TABLE` です。	`DYNAMIC_TABLE`
`snow.owner.id`	INTEGER	動的テーブルで OWNERSHIP 権限を持つロールの内部/システム生成識別子。	`12345`
`snow.owner.name`	VARCHAR	動的テーブルの OWNERSHIP 権限を持つロールの名前。	`MY_ROLE`
`snow.owner.type`	VARCHAR	オブジェクトを所有するロールのタイプ。例えば `ROLE` があります。. Snowflake Native App がオブジェクトを所有する場合、値は `APPLICATION` になります。. 削除されたオブジェクトには所有者ロールがないため、オブジェクトを削除した場合、Snowflakeは NULL を返します。	`ROLE`
`snow.query.id`	VARCHAR	動的テーブルを更新したクエリの ID	`01ba7614-0107-e56c-0000-a995024f304a`
`snow.schema.id`	INTEGER	動的テーブルを含むスキーマの内部/システム生成識別子。	`12345`
`snow.schema.name`	VARCHAR	動的テーブルを含むスキーマの名前。	`MY_SCHEMA`
`snow.warehouse.id`	INTEGER	動的テーブルの更新に使用されるウェアハウスの内部/システム生成識別子。	`12345`
`snow.warehouse.name`	VARCHAR	動的テーブルのリフレッシュに使用されるウェアハウスの名前。	`MY_WAREHOUSE`

`record` 列のキー値・ペア¶

record 列には、以下のキー値ペアを持つ OBJECT 値が含まれます。


キー	型	説明	例
`name`	VARCHAR	イベントの名前。動的テーブルリフレッシュに対して、値は `refresh.status` です。	`refresh.status`
`severity_text`	VARCHAR	イベントの重大度レベル（以下の値のいずれか）。 `INFO`: リフレッシュに成功しました。 `ERROR`: リフレッシュに失敗しました。 `WARN`: アップストリーム動的テーブルの更新に失敗しました。	`INFO`

`value` 列のキー値・ペア¶

value 列には、以下のキー値ペアを持つ VARIANT 値が含まれます。


キー	型	説明	例
`state`	VARCHAR	リフレッシュの状態。以下の値のいずれかになります。 `SUCCEEDED`: リフレッシュに成功しました。 `FAILED`: リフレッシュに失敗しました。 `UPSTREAM_FAILURE`: この動的テーブルが依存関係にある動的テーブルの更新に失敗したため、更新に失敗しました。	`SUCCEEDED`
`message`	VARCHAR	`state` の値が `FAILED` の場合、この列にはエラーメッセージが含まれます。	`SQL compilation error:\nFailure during expansion of view 'MY_DYNAMIC_TABLE': SQL compilation error:\nObject 'MY_DB.MY_SCHEMA.MY_BASE_TABLE' does not exist or not authorized.`

リフレッシュをトレースするためにパイプラインスパンをクエリする¶

:ref:` イベント <label-dynamic_tables_monitoring_sql_events>` に加えて、Snowflakeは動的テーブルリフレッシュのパイプラインスパンを記録できます。イベントとスパンは、2つの別々の可観測性メカニズムです。

イベント （ LOG_LEVEL によって制御される）は、動的テーブルのリフレッシュごとにログを提供し、各リフレッシュが成功したか失敗したかを示します。
スパン （ TRACE_LEVEL によって制御される）は、パイプライン全体の相関トレース IDs 、スキップの理由、および依存関係のトポロジーを含む、より豊富なパイプラインレベルの観測可能性を提供します、

スパンは、動的テーブルとそのコンシューマーのラグを最小限に抑えるために、スケジューラがリフレッシュをスキップした上流のスキップやリフレッシュサイクルによる SKIPPED リフレッシュを含む、イベントが出力されない追加の状態をキャプチャします。

注釈

動的テーブルのスパンを記録すると、コストが発生します。テレメトリーデータ収集の費用をご参照ください。

パイプラインのスパンを有効にする¶

動的テーブルのリフレッシュのためにパイプラインスパンを有効にするには、 TRACE_LEVEL パラメーターを ALWAYS データベースまたはスキーマレベルで設定します。

ALTER SCHEMA my_db.my_schema SET TRACE_LEVEL = 'ALWAYS';

また、データベースレベルでこれを設定すると、データベース内のすべての動的テーブルのスパンをキャプチャすることもできます。

ALTER DATABASE my_db SET TRACE_LEVEL = 'ALWAYS';

スパンデータをクエリする¶

動的テーブルリフレッシュのパイプラインスパンをクエリするには、record_type = 'SPAN' および record:"name" = 'table_refresh' の場合の行に対してフィルターします。

SELECT
    resource_attributes:"snow.executable.name"::STRING AS dt_name,
    record_attributes:"snow.dynamic_table.state"::STRING AS state,
    record_attributes:"snow.dynamic_table.state_reason"::STRING AS state_reason,
    record_attributes:"snow.dynamic_table.data_timestamp"::STRING AS data_timestamp,
    trace:"trace_id"::STRING AS trace_id,
    trace:"span_id"::STRING AS span_id,
    record:"status":"code"::STRING AS status_code
  FROM my_event_table
  WHERE record_type = 'SPAN'
    AND record:"name" = 'table_refresh'
  ORDER BY start_timestamp ASC;

スパン属性（ `record_attributes` ）¶

各スパン行には、動的テーブルリフレッシュに固有の record_attributes 列内の次の属性が含まれます。


属性名	型	説明
`snow.dynamic_table.state`	STRING	リフレッシュの状態: `SUCCEEDED` 、 `FAILED` 、または `SKIPPED` 。
`snow.dynamic_table.state_reason`	STRING	動的テーブルがスキップまたは失敗した理由。成功での NULL 。可能な値： `QUERY_FAILURE`: リフレッシュクエリに失敗しました。 `UPSTREAM_FAILURE`: 上流の動的テーブルがリフレッシュに失敗しました。 `UPSTREAM_SKIP`: 上流の動的テーブルがスキップされました。 `NOT_EFFECTIVE_TICK_TO_REFRESH`:パイプラインはすでにスケジュール遅れで実行されており、このリフレッシュ操作をスキップして、この動的テーブルとそのコンシューマーのラグを最小限に抑えます。
`snow.dynamic_table.data_timestamp`	STRING	リフレッシュが評価されたときのトランザクションのタイムスタンプ。（実際のリフレッシュの時間より少し前になる可能性があります。このタイムスタンプより前に到着したベースオブジェクト内のすべてのデータが動的テーブルに含まれています。

注釈

どのイベントが出力されないかについて、スパンは SKIPPED 状態（ UPSTREAM_SKIP および NOT_EFFECTIVE_TICK_TO_REFRESH 理由付き）をカバーします。リフレッシュのスキップを可視化する必要がある場合は、イベントの代わりにスパンを使用します。

トレース IDs およびスパンリンクとパイプラインの相関¶

スパンのユニークな機能は、パイプラインレベルの相関です。リフレッシュサイクルに複数の動的テーブルのリフレッシュ操作が含まれる場合、結果として得られるすべてのスパンは同じ trace:"trace_id" を共有します。これにより、単一のリフレッシュサイクルで発生したリフレッシュ操作のフルセットを再構築することができます。

各スパンには、各上流依存関係の span_id をリストする record:"links" 配列も含まれます。たとえば、 DT_B が DT_A に依存する場合、 DT_B の record:"links" に DT_A の span_id が表示されます。

record:"status":"code" フィールドは、成功とスキップの場合は STATUS_CODE_OK 、および失敗の場合は STATUS_CODE_ERROR です。

たとえば、1回のリフレッシュサイクルですべての動的テーブルリフレッシュ操作を相関させるには、同じ trace_id のスパンに対してクエリを実行します。

SELECT
    resource_attributes:"snow.executable.name"::STRING AS dt_name,
    record_attributes:"snow.dynamic_table.state"::STRING AS state,
    record:"links" AS upstream_links
  FROM my_event_table
  WHERE record_type = 'SPAN'
    AND record:"name" = 'table_refresh'
    AND trace:"trace_id" = '<trace_id>'
  ORDER BY start_timestamp;

パイプラインのリフレッシュをトレースする¶

このセクションでは、パイプラインスパンを使用してリフレッシュサイクルをエンドツーエンドでトレースする方法について説明します。関連するスパンを見つけ、完全なパイプラインを取得し、失敗またはスキップを診断します。

パイプラインシナリオの例¶

4つの動的テーブルの線形パイプラインを考えてみましょう。

DT1 --> DT2 --> DT3 --> DT4

この例では DT1 および DT2 は正常にリフレッシュされますが、 DT3 はクエリエラーにより失敗します。DT3 は失敗したため、 DT4 は UPSTREAM_FAILURE の理由で自動的にスキップされます。

次のステップは、このシナリオでパイプラインスパンを取得して解釈する方法を示しています。

ステップ1: 動的テーブルのスパンを見つける¶

特定の動的テーブルのリフレッシュを調査するには、その最新のスパンのイベントテーブルをクエリします。データベース、スキーマ、および動的テーブル名でフィルターして、正しいオブジェクトに一致するようにします。

SELECT
    trace:"span_id"::STRING AS span_id,
    trace:"trace_id"::STRING AS trace_id,
    resource_attributes:"snow.executable.name"::STRING AS dt_name,
    record_attributes:"snow.dynamic_table.data_timestamp"::STRING AS data_timestamp,
    record_attributes:"snow.dynamic_table.state"::STRING AS state,
    record_attributes:"snow.dynamic_table.state_reason"::STRING AS state_reason,
    resource_attributes:"snow.query.id"::STRING AS query_id,
    start_timestamp,
    timestamp AS end_timestamp
  FROM my_event_table
  WHERE record_type = 'SPAN'
    AND record:"name" = 'table_refresh'
    AND resource_attributes:"snow.database.name" = 'MY_DB'
    AND resource_attributes:"snow.schema.name" = 'MY_SCHEMA'
    AND resource_attributes:"snow.executable.name" = 'DT3'
  ORDER BY start_timestamp DESC
  LIMIT 5;

+----------+------------------+---------+-------------------------+-----------+--------------+--------------------------------------+-------------------------+-------------------------+
| SPAN_ID  | TRACE_ID         | DT_NAME | DATA_TIMESTAMP          | STATE     | STATE_REASON | QUERY_ID                             | START_TIMESTAMP          | END_TIMESTAMP           |
|----------+------------------+---------+-------------------------+-----------+--------------+--------------------------------------+-------------------------+-------------------------|
| a1b2c3d4 | 4f3e2d1c0b9a8877 | DT3     | 2026-02-13T10:00:00.000 | FAILED    | QUERY_FAILURE| 01ba7614-0107-e56c-0000-a995024f304a | 2026-02-13 10:02:01.000 | 2026-02-13 10:02:20.000 |
| e5f6a7b8 | 7a8b9c0d1e2f3344 | DT3     | 2026-02-13T09:55:00.000 | SUCCEEDED | NULL         | 01ba7614-0107-e56c-0000-a995024f2f9b | 2026-02-13 09:57:01.000 | 2026-02-13 09:57:18.000 |
+----------+------------------+---------+-------------------------+-----------+--------------+--------------------------------------+-------------------------+-------------------------+

trace_id 値はリフレッシュサイクルを識別します。単一のパイプライン内のすべての動的テーブルスパンは、同じ trace_id を共有します。次のステップでこの値を使用して、同じリフレッシュサイクルからすべてのスパンを取得します。

ステップ2：フルパイプラインを取得する¶

同じ trace_id を共有するすべてのスパンのクエリを実行して、リフレッシュサイクルのすべての動的テーブルを表示します。record:"links" 含めて依存関係グラフおよび DATEDIFF をキャプチャし、各リフレッシュ操作の時間を計算します。

SELECT
    trace:"span_id"::STRING AS span_id,
    trace:"trace_id"::STRING AS trace_id,
    resource_attributes:"snow.executable.name"::STRING AS dt_name,
    record_attributes:"snow.dynamic_table.state"::STRING AS state,
    record_attributes:"snow.dynamic_table.state_reason"::STRING AS state_reason,
    resource_attributes:"snow.query.id"::STRING AS query_id,
    start_timestamp,
    timestamp AS end_timestamp,
    DATEDIFF('second', start_timestamp, timestamp) AS duration_sec,
    record:"links" AS upstream_links
  FROM my_event_table
  WHERE record_type = 'SPAN'
    AND record:"name" = 'table_refresh'
    AND trace:"trace_id" = '4f3e2d1c0b9a8877'
  ORDER BY start_timestamp ASC;

+----------+------------------+---------+-----------+-----------------+--------------------------------------+-------------------------+-------------------------+--------------+---------------------------------------------+
| SPAN_ID  | TRACE_ID         | DT_NAME | STATE     | STATE_REASON    | QUERY_ID                             | START_TIMESTAMP          | END_TIMESTAMP           | DURATION_SEC | UPSTREAM_LINKS                              |
|----------+------------------+---------+-----------+-----------------+--------------------------------------+-------------------------+-------------------------+--------------+---------------------------------------------|
| f1e2d3c4 | 4f3e2d1c0b9a8877 | DT1     | SUCCEEDED | NULL            | 01ba7614-0107-e56c-0000-a995024f3001 | 2026-02-13 10:01:00.000 | 2026-02-13 10:01:30.000 |           30 | []                                          |
| b5a6c7d8 | 4f3e2d1c0b9a8877 | DT2     | SUCCEEDED | NULL            | 01ba7614-0107-e56c-0000-a995024f3002 | 2026-02-13 10:01:31.000 | 2026-02-13 10:02:00.000 |           29 | [{"span_id": "f1e2d3c4", ...}]              |
| a1b2c3d4 | 4f3e2d1c0b9a8877 | DT3     | FAILED    | QUERY_FAILURE   | 01ba7614-0107-e56c-0000-a995024f304a | 2026-02-13 10:02:01.000 | 2026-02-13 10:02:20.000 |           19 | [{"span_id": "b5a6c7d8", ...}]              |
| c9d0e1f2 | 4f3e2d1c0b9a8877 | DT4     | SKIPPED   | UPSTREAM_FAILURE| NULL                                 | 2026-02-13 10:02:20.000 | 2026-02-13 10:02:20.000 |            0 | [{"span_id": "a1b2c3d4", ...}]              |
+----------+------------------+---------+-----------+-----------------+--------------------------------------+-------------------------+-------------------------+--------------+---------------------------------------------+

この結果から、リフレッシュサイクルの全体像を見ることができます。

DT1 および DT2 に成功しました（それぞれ30秒と29秒）。
クエリの失敗により、19秒後に DT3 に失敗しました。
DT4 は、上流の依存関係が失敗したため、すぐにスキップされました（期間ゼロスパンで表されました）。
UPSTREAM_LINKS 列は、 span_id によって各動的テーブルの直接依存関係を表示します。

ステップ3：失敗またはスキップの根本的な原因を特定する¶

動的テーブルがスキップされたり失敗したりした場合は、スパンリンクを介して上流の依存関係をトレースし、根本的な原因を見つけることができます。このクエリは、特定の動的テーブルのスパンリンクをパイプライン内の他のスパンに解決します。

WITH pipeline AS (
  SELECT
    trace:"span_id"::STRING AS span_id,
    resource_attributes:"snow.executable.name"::STRING AS dt_name,
    record_attributes:"snow.dynamic_table.state"::STRING AS state,
    record_attributes:"snow.dynamic_table.state_reason"::STRING AS state_reason,
    resource_attributes:"snow.query.id"::STRING AS query_id,
    record:"links" AS upstream_links
  FROM my_event_table
  WHERE record_type = 'SPAN'
    AND record:"name" = 'table_refresh'
    AND record_attributes:"snow.dynamic_table.data_timestamp" = '2026-02-13T10:00:00.000'
),
target_links AS (
  SELECT f.value:"span_id"::STRING AS upstream_span_id
  FROM pipeline,
  LATERAL FLATTEN(input => upstream_links) f
  WHERE dt_name = 'DT4'
)
SELECT
  p.dt_name AS upstream_dt,
  p.state AS upstream_state,
  p.state_reason AS upstream_reason,
  p.query_id AS upstream_query_id
FROM target_links tl
JOIN pipeline p ON tl.upstream_span_id = p.span_id;

+-------------+----------------+-----------------+--------------------------------------+
| UPSTREAM_DT | UPSTREAM_STATE | UPSTREAM_REASON | UPSTREAM_QUERY_ID                    |
|-------------+----------------+-----------------+--------------------------------------|
| DT3         | FAILED         | QUERY_FAILURE   | 01ba7614-0107-e56c-0000-a995024f304a |
+-------------+----------------+-----------------+--------------------------------------+

この例では DT4 は、 QUERY_FAILURE で失敗した上流の依存関係 DT3 のためにスキップされました。query_id を使用して失敗したクエリをさらに調査することができます（例: GET_QUERY_OPERATOR_STATS を呼び出す、または :doc:` クエリ履歴 </sql-reference/account-usage/query_history>` をチェックする）。

より長い依存関係のチェーンの場合は、同じパターンを繰り返します。ターゲットの動的テーブル名を置き換えて、根本的な原因である state = 'FAILED' および state_reason = 'QUERY_FAILURE' のあるスパンに達するまで上流に移動します。

失敗の下流影響を検索する¶

どの動的テーブルが特定の失敗の影響を受けたかを特定するには、スパンリンクの検索を逆にします。このクエリは、record:"links" が失敗した動的テーブルの span_id を参照するすべての動的テーブルを検索します。

WITH pipeline AS (
  SELECT
    trace:"span_id"::STRING AS span_id,
    resource_attributes:"snow.executable.name"::STRING AS dt_name,
    record_attributes:"snow.dynamic_table.state"::STRING AS state,
    record_attributes:"snow.dynamic_table.state_reason"::STRING AS state_reason,
    record:"links" AS upstream_links
  FROM my_event_table
  WHERE record_type = 'SPAN'
    AND record:"name" = 'table_refresh'
    AND record_attributes:"snow.dynamic_table.data_timestamp" = '2026-02-13T10:00:00.000'
)
SELECT p.dt_name, p.state, p.state_reason
FROM pipeline p,
LATERAL FLATTEN(input => p.upstream_links) f
WHERE f.value:"span_id"::STRING = 'a1b2c3d4';

+---------+---------+-----------------+
| DT_NAME | STATE   | STATE_REASON    |
|---------+---------+-----------------|
| DT4     | SKIPPED | UPSTREAM_FAILURE|
+---------+---------+-----------------+

これは失敗した動的テーブルの直接の依存関係を返します。一時的に影響を受けるすべての動的テーブルを見つけるには、各依存関係の span_id でクエリを繰り返し、さらに下流に移動します。

OpenTelemetry 互換ツールを使用する¶

動的テーブルパイプラインのスパンは、標準 OpenTelemetry データモデルに従います。リフレッシュサイクルのすべてのスパンは同じ trace:"trace_id" を共有するため、それらをイベントテーブルから可視化のための OpenTelemetry 互換ツールにエクスポートできます。

これらのツールはパイプラインをトレースタイムラインとしてレンダリングし、各動的テーブルのリフレッシュ操作の期間とステータス、およびスパンリンクにエンコードされた依存関係を表示します。

動的テーブルのイベントテーブル監視とアラート¶

リフレッシュを監視するためにイベントテーブルをクエリします。¶

新しいデータに対するアラートをセットし、更新を監視します。¶

キャプチャするイベントの重大度レベルのセット¶

新しいデータのアラート設定¶

動的テーブルイベントのログ情報¶

イベントテーブル列値¶

resource_attributes 列のキー値・ペア¶

record 列のキー値・ペア¶

value 列のキー値・ペア¶

リフレッシュをトレースするためにパイプラインスパンをクエリする¶

パイプラインのスパンを有効にする¶

スパンデータをクエリする¶

スパン属性（ record_attributes ）¶

トレース IDs およびスパンリンクとパイプラインの相関¶

パイプラインのリフレッシュをトレースする¶

パイプラインシナリオの例¶

ステップ1: 動的テーブルのスパンを見つける¶

ステップ2：フルパイプラインを取得する¶

ステップ3：失敗またはスキップの根本的な原因を特定する¶

失敗の下流影響を検索する¶

OpenTelemetry 互換ツールを使用する¶

`resource_attributes` 列のキー値・ペア¶

`record` 列のキー値・ペア¶

`value` 列のキー値・ペア¶

スパン属性（ `record_attributes` ）¶