Snowpark Container Services:Monitoring Services¶

<service-name>!SPCS_GET_LOGS 関数の使用¶

<service_name>!SPCS_GET_LOGS テーブル関数は、指定されたジョブのコンテナからログを返します。これらのログはSnowflakeによって収集され、イベントテーブルに格納されます。

次のリストでは、このテーブル関数を使用する利点について説明します。

• 特定のサービスのログを取得できます。

• 指定した時間範囲内のログを取得できます。

• 呼び出し元はイベントテーブル全体にアクセスする必要がありません。これは、情報セキュリティ要件が厳しい顧客にとって有益です。現在のセッションにサービス所有者ロールが含まれている場合、サービス所有者はこれらのログにアクセスできます。

service_name には、サービスの名前を指定します。関数は、そのサービスのコンテナから収集したSnowflakeのログを返します（コンテナログへのアクセス を参照）。

オプションで日付範囲を指定できます。デフォルトでは、関数は1日のログを返します。たとえば、クエリが、Snowflakeが過去1日間の my_test_job ジョブのコンテナから収集したログを取得しました（これがデフォルトです）。

SELECT * FROM TABLE(my_test_job!SPCS_GET_LOGS());

Copy

出力例:

+-------------------------+-------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+
| TIMESTAMP               | INSTANCE_ID | CONTAINER_NAME | LOG                                                                                                                                                                 | RECORD_ATTRIBUTES          |
|-------------------------+-------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------|
| 2025-06-26 00:23:40.281 |           0 | main           | job-tutorial - INFO - Job finished                                                                                                                                  | {                          |
|                         |             |                |                                                                                                                                                                     |   "log.iostream": "stdout" |
|                         |             |                |                                                                                                                                                                     | }                          |
| 2025-06-26 00:23:38.787 |           0 | main           | job-tutorial - INFO - Executing query [select current_time() as time,'hello'] and writing result to table [results]                                                 | {                          |
|                         |             |                |                                                                                                                                                                     |   "log.iostream": "stdout" |
|                         |             |                |                                                                                                                                                                     | }                          |
| 2025-06-26 00:23:38.787 |           0 | main           | job-tutorial - INFO - Connection succeeded. Current session context: database="TUTORIAL_DB", schema="DATA_SCHEMA", warehouse="TUTORIAL_WAREHOUSE", role="TEST_ROLE" | {                          |
|                         |             |                |                                                                                                                                                                     |   "log.iostream": "stdout" |
|                         |             |                |                                                                                                                                                                     | }                          |
| 2025-06-26 00:23:36.852 |           0 | main           | job-tutorial - INFO - Job started                                                                                                                                   | {                          |
|                         |             |                |                                                                                                                                                                     |   "log.iostream": "stdout" |
|                         |             |                |                                                                                                                                                                     | }                          |
+-------------------------+-------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+

このメソッドの呼び出しの詳細については、 <service_name>!SPCS_GET_LOGS をご参照ください。

イベントテーブルの使用¶

Snowflake は、コンテナーから標準出力および標準エラーストリームに送信されたログを、アカウント用に設定されたイベントテーブルに取り込むことができます。イベントテーブルの設定については、 ロギング、トレース、メトリクス をご参照ください。

サービス仕様ファイルの spec.logExporters field を使用して、イベントテーブルに収集するストリーム（すべて、標準エラーのみ、あるいはなし）を制御します。

そして、イベント・テーブルにイベントをクエリすることができます。アカウントのアクティブなイベントテーブルを見つけるには、 SHOW PARAMETERS コマンドを使用して、 EVENT_TABLE パラメーターの値を確認します。

SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

パラメーターは、アカウントのアクティブイベントテーブルを指定します。

次に、そのイベントテーブルをクエリします。次の SELECT ステートメントは、過去 1 時間に記録された Snowflake サービスおよびジョブイベントを取得します。

SELECT TIMESTAMP, RESOURCE_ATTRIBUTES, RECORD_ATTRIBUTES, VALUE
FROM <current_event_table_for_your_account>
WHERE timestamp > dateadd(hour, -1, current_timestamp())
AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<service_name>'
AND RECORD_TYPE = 'LOG'
ORDER BY timestamp DESC
LIMIT 10;

Snowflakeは、この例に示すように、イベントテーブルクエリの WHERE 句にタイムスタンプを含めることを推奨します。さまざまなSnowflakeコンポーネントによって生成される潜在的データ量のため、これは特に重要です。フィルターを適用すると、より小さなデータのサブセットを取得することができ、クエリのパフォーマンスが向上します。

イベントテーブルには以下の列があり、Snowflakeがコンテナーから収集したログに関する有用な情報を提供します。

• TIMESTAMP: Snowflakeがいつログを収集したかを示します。

• RESOURCE_ATTRIBUTES: ログメッセージを生成した Snowflake サービスとサービス内のコンテナーを識別する JSON オブジェクトを提供します。たとえば、サービスの実行時に指定されたサービス名、コンテナー名、コンピューティングプール名などの詳細を提供します。

  {
    "snow.account.name": "SPCSDOCS1",
    "snow.compute_pool.id": 20,
    "snow.compute_pool.name": "TUTORIAL_COMPUTE_POOL",
    "snow.compute_pool.node.id": "a17e8157",
    "snow.compute_pool.node.instance_family": "CPU_X64_XS",
    "snow.database.id": 26,
    "snow.database.name": "TUTORIAL_DB",
    "snow.schema.id": 212,
    "snow.schema.name": "DATA_SCHEMA",
    "snow.service.container.instance": "0",
    "snow.service.container.name": "echo",
    "snow.service.container.run.id": "b30566",
     "snow.service.id": 114,
    "snow.service.name": "ECHO_SERVICE2",
    "snow.service.type": "Service"
  }
  

  Copy

• RECORD_ATTRIBUTES: Snowflakeサービスの場合は、エラーソース（標準出力または標準エラー）を識別します。

  { "log.iostream": "stdout" }
  

  Copy

• VALUE: 標準出力と標準エラーは行に分割され、各行はイベントテーブルに記録を生成します。

  "echo-service [2023-10-23 17:52:27,429] [DEBUG] Sending response: {'data': [[0, 'Joe said hello!']]}"
  

SYSTEM$GET_SERVICE_LOGS の使用¶

SYSTEM$GET_SERVICE_LOGS 関数は、現在実行中のサービスコンテナのログを返します。コンテナが終了した後も、しばらくはシステム関数を使用してログにアクセスできます。システム関数は、開発中やテスト中、サービスやジョブを最初に作成する場合に最も役に立ちます。

ユーザーは、取得するサービス名、インスタンス ID、コンテナー名、またオプションで最新のログ行数を提供します。サービスインスタンスが1つしか実行されていない場合、サービスインスタンス ID は0になります。たとえば、次のステートメント コマンドは、 echo_service という名前のサービスのインスタンス0に属する echo という名前のコンテナーのログから、後続の10行を取得します。

SELECT SYSTEM$GET_SERVICE_LOGS('echo_service', '0', 'echo', 10);

出力例:

+--------------------------------------------------------------------------+
| SYSTEM$GET_SERVICE_LOGS                                                  |
|--------------------------------------------------------------------------|
| 10.16.6.163 - - [11/Apr/2023 21:44:03] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:08] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:13] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:18] "GET /healthcheck HTTP/1.1" 200 - |
+--------------------------------------------------------------------------+
1 Row(s) produced. Time Elapsed: 0.878s

関数を呼び出すために必要なサービスに関する情報（インスタンス ID やコンテナ名など）を持っていない場合は、まず SHOW SERVICE CONTAINERS IN SERVICE コマンドを実行して、各インスタンスで実行されているサービスインスタンスとコンテナに関する情報を取得することができます。

The SYSTEM$GET_SERVICE_LOGS 関数には以下の制限があります。

• 標準出力と標準エラーのストリームをマージします。この関数は、出力がどのストリームから来たかを示すことはできません。

• 単一のサービスインスタンスで、特定のコンテナーのキャプチャデータを報告する。

• 実行中のコンテナーのログのみを報告する。関数は、再起動された以前のコンテナや、停止または削除されたサービスのコンテナからログをフェッチすることはできません。

• 関数は100 KB までのデータを返す。

イベント・テーブル・サービスのメトリクスへのアクセス¶

サービスからのメトリクスをアカウント用に構成されたイベント・テーブルにログに記録するには、サービス仕様に以下のセクションを含めます。

platformMonitor:
  metricConfig:
    groups:
    - <group 1>
    - <group 2>
    - ...

ここで、各 group N は、関心のある 事前に定義されたメトリックグループ を指します（例えば、 system 、 network 、 storage）。詳細については、サービス仕様書の spec.platformMonitor field セクションをご参照ください。

サービスの実行中、Snowflakeはこれらのメトリクスをアカウントのイベントテーブルに記録します。これらのメトリックは次のような方法で読むことができます。

• サービスヘルパーメソッドの使用： <service_name>!SPCS_GET_METRICS テーブル関数は、指定されたサービス用にSnowflakeが収集したメトリックを返します。次のリストは、このテーブル関数を使用する利点を説明しています。

  • 特定のサービスのメトリックを取得できます。

  • 指定した時間範囲内のメトリックを取得できます。

  • 呼び出し元はイベントテーブル全体にアクセスする必要がありません。これは、情報セキュリティ要件が厳しい顧客にとって有益です。

  次の SELECT ステートメントは、テーブル関数を使用して過去1時間に記録された指定サービスのプラットフォームイベントを取得します。

  SELECT *
    FROM TABLE(echo_service!SPCS_GET_METRICS(start_time => dateadd('hour', -1, current_timestamp())));
  

  Copy

• イベントテーブルを直接クエリする： イベントテーブルをクエリして、メトリックを読み取ることができます。次のクエリは、 my_service サービスに対して過去 1 時間に記録されたサービス・メトリクスを検索します。

  SELECT timestamp, value
    FROM my_event_table_db.my_event_table_schema.my_event_table
    WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP())
      AND RESOURCE_ATTRIBUTES:"snow.service.name" = 'MY_SERVICE'
      AND RECORD_TYPE = 'METRIC'
      ORDER BY timestamp DESC
      LIMIT 10;
  

  Copy

  アカウントのアクティブなイベントテーブルの名前がわからない場合は、 SHOW PARAMETERS コマンドを実行し、アカウントレベル EVENT_TABLE パラメーターの値を表示します。

  SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;
  

  Copy

  イベントテーブルの詳細については、 イベントテーブルの使用 をご参照ください。

例

アカウント用に構成されたイベントテーブルにメトリックを記録するサービス例を作成するには、以下のステップを完了します。

1. チュートリアル1 の手順に従って、1つ変更を加えて echo_service という名前のサービスを作成します。サービスを作成するステップ3で、以下の CREATE SERVICE コマンドを使用し、変更したサービス仕様に platformMonitor フィールドを追加します。

   CREATE SERVICE echo_service
     IN COMPUTE POOL tutorial_compute_pool
     FROM SPECIFICATION $$
       spec:
         containers:
         - name: echo
           image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
           env:
             SERVER_PORT: 8000
             CHARACTER_NAME: Bob
           readinessProbe:
             port: 8000
             path: /healthcheck
         endpoints:
         - name: echoendpoint
           port: 8000
           public: true
         platformMonitor:
           metricConfig:
             groups:
             - system
             - system_limits
         $$
       MIN_INSTANCES=1
       MAX_INSTANCES=1;
   

   Copy

サービスが実行されると、Snowflakeは指定されたメトリックグループのメトリックをイベントテーブルに記録し始めます。

1. <service_name>!SPCS_GET_METRICS 関数を呼び出しすか、イベントテーブルをクエリしてメトリックにアクセスします。たとえば、echo_serviceサービスによって過去1時間にレポートされたメトリックを取得します。

   • <service_name>!SPCS_GET_METRICS ヘルパー関数を使用します。

     Copy

     SELECT * FROM TABLE(echo_service!SPCS_GET_METRICS(START_TIME => DATEADD('hour', -1, CURRENT_TIMESTAMP())));

   • イベントテーブルを直接クエリします。

     SELECT timestamp, value
      FROM my_events
      WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP())
        AND RESOURCE_ATTRIBUTES:"snow.service.name" = 'ECHO_SERVICE'
        AND RECORD_TYPE = 'METRIC'
        AND RECORD:metric.name = 'container.cpu.usage'
        ORDER BY timestamp DESC
        LIMIT 100;
     

     Copy

コンピューティングプールメトリックへのアクセス¶

コンピューティング・プール メトリクスは、コンピューティング・プール内のノードとその上で実行されているサービスに関する洞察を提供します。各ノードは、コンテナー用に利用可能なメモリ量などのノード固有のメトリクスや、個々のコンテナーによるメモリ使用量などのサービス・メトリクスを報告します。コンピューティング・プールのメトリクスは、ノードの視点からの情報を提供します。

各ノードには、 TCP ポート 9001 でリッスンするメトリクス・パブリッシャーがあります。他のサービスは、ノードのポート9001にパス /metrics を使って HTTP GET リクエストを出すことができます。ノードの IP アドレスを発見するには、 discover.monitor.compute_pool_name.cp.spcs.internal ホスト名について DNS から SRV 記録（またはA記録）を取得します。次に、各ノードをアクティブにポーリングしてメトリクスを取得する別のサービスをアカウントに作成します。

応答の本文では、以下のメトリクス例に示すように、 Prometheus形式 を使用してメトリクスを提供します。

# HELP node_memory_capacity Defines SPCS compute pool resource capacity on the node
# TYPE node_memory_capacity gauge
node_memory_capacity{snow_compute_pool_name="MY_POOL",snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"} 1
node_cpu_capacity{snow_compute_pool_name="MY_POOL",snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"} 7.21397383168e+09

次の点に注意してください。

• 各メトリクスは、 # HELP と # TYPE で始まり、短い説明とメトリクスの型を提供します。この例では、 node_memory_capacity メトリクスは gauge 型です。

• その後に、メトリクスの名前、特定のリソース（データポイント）を説明するラベルのリスト、およびその値が続きます。この例では、メトリクス（名前は node_memory_capacity）がメモリ情報を提供し、ノードには使用可能なメモリが7.2 GB あることを示しています。メトリクスには、図のようなラベル形式のメタデータも含まれます。

  snow_compute_pool_name="MY_POOL",
  snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"
  

これらのメトリクスは、どのような形で処理しても構いません。たとえば、メトリクスをデータベースに格納し、 UI (Grafana ダッシュボードのような)を使用して情報を表示することができます。

利用可能なコンピューティングプールメトリクスのリストについては、 利用可能なプラットフォーム・メトリクス をご参照ください。

例

Prometheusがコンピューティング・プールにメトリクスをポーリングするように設定する例については、 コンピューティングプール・メトリクス・チュートリアル をご参照ください。

利用可能なプラットフォーム・メトリクス¶

以下は、使用可能なプラットフォーム・メトリクス・グループと、各グループ内のメトリクスの一覧です。ストレージ メトリクスは現在、ブロック・ストレージ・ボリュームからのみ収集されることにご注意ください。

OTLP アプリケーションメトリックとトレースの公開¶

Snowflakeは OTel コレクターを実行し、サービスコンテナーが OTLP アプリケーションメトリックとトレースを公開するために使用できます。つまり、サービスコンテナーは、 OTel コレクターエンドポイントにメトリックをプッシュすることができます。その後、Snowflakeは、元のサービスの詳細とともに、Snowflakeアカウントに構成されたイベントテーブルに書き込みます。

仕組みは次のとおりです。

• Snowflakeは、コンテナーがアプリケーションメトリックとトレースを公開できる OTel コレクターエンドポイントを提供するサービスコンテナーの以下の環境変数を自動的に入力します。

  • OTEL_EXPORTER_OTLP_METRICS_ENDPOINT

  • OTEL_EXPORTER_OTLP_TRACES_ENDPOINT

• 標準の OTLP クライアント は、これらの環境変数を検索して、 OTel コレクターを自動的に検出します。これにより、サービスコンテナーは、このクライアントを使用してメトリックとトレースを公開できるようになります。

from opentelemetry.sdk.trace import TracerProvider
from snowflake.telemetry.trace import SnowflakeTraceIdGenerator


trace_id_generator = SnowflakeTraceIdGenerator()
tracer_provider = TracerProvider(
    resource=Resource.create({"service.name": SERVICE_NAME}),
    id_generator=trace_id_generator
)

import io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk;
import com.snowflake.telemetry.trace.SnowflakeTraceIdGenerator;

static OpenTelemetry initOpenTelemetry() {
  return AutoConfiguredOpenTelemetrySdk.builder()
      .addPropertiesSupplier(
          () ->
              Map.of(...config options...)
      .addTracerProviderCustomizer(
          (tracerProviderBuilder, configProperties) -> {
            tracerProviderBuilder.setIdGenerator(SnowflakeTraceIdGenerator.INSTANCE);
            return tracerProviderBuilder;
          })
      .build()
      .getOpenTelemetrySdk();

Prometheusアプリケーションメトリックの公開¶

SnowflakeはPrometheusメトリックをサポートしており、アプリケーションは OTLP メトリックをプッシュする代わりに、Snowflakeが提供するコレクターによってポーリングされるPrometheusメトリックを公開する場合があります。Snowflakeがこれらのアプリケーションメトリックをサービスから収集し、イベントテーブルに公開するには、以下の手順に従います。

• Prometheusメトリックを公開するポートでサービスをリッスンしてください。

• Snowflakeが提供するコンテナー（「サイドカー」コンテナーとも呼ばれます）をサービスに組み込み、サービスコンテナーからメトリックを取得するために必要な構成を行います。

Prometheusサイドカーは、スケジュールされた頻度でコンテナーからアプリケーションメトリックを取得し、Prometheus形式を OTLP 形式に変換し、メトリックを OTel コレクターにプッシュします。その後、 OTel コレクターは、Snowflakeアカウントに構成されたイベントテーブルにこれらのメトリックを公開します。

Prometheusサイドカーコンテナーを別のコンテナーとしてサービス仕様に追加し、コンテナーが公開する HTTP エンドポイントを指定する引数を以下の形式で含めます。

localhost:{PORT}/{METRICS_PATH}, {SCRAPE_FREQUENCY}

サイドカーがメトリックを取得するポート番号、パス、頻度を指定します。

サービス仕様のフラグメントの例は、サイドカーコンテナーがポート8000からサービスコンテナーから1分ごとにメトリックをスクレイピングし、パス「/metrics」からメトリックを取得していることを示しています。

spec:
  containers:
  - name: <name>
    image: <image-name>
    .....
  - name: prometheus
    image: /snowflake/images/snowflake_images/monitoring-prometheus-sidecar:0.0.1
    args:
      - "-e"
      - "localhost:8000/metrics,1m"

仕様で、

• image はSnowflake提供のサイドカーコンテナーイメージです。

• args は、prometheusコンテナーがメトリックをスクレイピングするために必要な構成を提供します。

  • コンテナーが提供するポート8000から。このprometheusコンテナーの構成では、ポートは必須です。

  • パス「/metrics」を使用しています。オプションです。指定がない場合、「/metrics」がデフォルトパスとなります。

  • 毎分。オプションです。指定がない場合、「1m」がデフォルトとなります。

  デフォルトを活用する場合、これはメトリックをスクレイピングするための同等の構成です。

  spec:
      ...
      args:
        - "-e"
        - "localhost:8000"
  

  Copy

イベントテーブルのアプリケーションメトリックとトレースへのアクセス¶

イベントテーブルをクエリして、アプリケーションメトリックを取得できます。以下のクエリは、過去1時間に収集されたアプリケーションメトリックを取得します。

SELECT timestamp, record:metric.name, value
  FROM <current_event_table_for_your_account>
  WHERE timestamp > dateadd(hour, -1, CURRENT_TIMESTAMP())
    AND resource_attributes:"snow.service.name" = <service_name>
    AND scope:"name" != 'snow.spcs.platform'
    AND record_type = 'METRIC'
  ORDER BY timestamp DESC
  LIMIT 10;

イベントテーブルの詳細については、 イベントテーブルの概要 をご参照ください。これらのメトリックは、 Snowflakeダッシュボード で可視化できます。

イベントテーブルをクエリしてアプリケーショントレースを表示することもできます。例えば、過去1時間のアプリケーショントレースを取得するには、前述のクエリで record_type 条件を以下のように置き換えます。

AND record_type = 'SPAN' OR record_type = 'SPAN_EVENT'

トレースは、 Snowflake trail ビューアで可視化できます。

メトリックとトレースには、リソース属性と記録属性として、ユーザー定義属性とSnowflake定義属性の両方が含まれます。プレフィックス snow. はSnowflakeが生成した属性用に予約されています。Snowflakeはこのプレフィックスを使用するカスタム属性を無視します。Snowflakeで定義されている属性のリストについては、 利用可能なプラットフォーム・メトリクス を参照してください。

サンプルコード はPythonとJavaの両方で提供されており、 OTLP SDK を使用したカスタムメトリックとトレースによるアプリケーションのインスツルメンテーションを実演しています。例では、トレース用のSnowflake trailビューアとの互換性のために、Snowflake Trace ID の生成を構成する方法を示します。

クエリプラットフォームイベント¶

リソースのログレベルを構成すると、SnowflakeはプラットフォームイベントをSnowflakeアカウントのアクティブなイベントテーブルに記録します。これらのイベントには以下の方法でアクセスできます。

• サービスヘルパーメソッドの使用： <service_name>!SPCS_GET_EVENTS テーブル関数は、指定されたサービスのコンテナからSnowflakeが収集したイベントを返します。

  次のリストでは、このテーブル関数を使用する利点について説明します。

  • 特定のサービスのイベントを取得できます。

  • 指定された時間範囲内のイベントを取得できます。

  • 呼び出し元はイベントテーブル全体にアクセスする必要がありません。これは、情報セキュリティ要件が厳しい顧客にとって有益です。

  次の SELECT ステートメントは、テーブル関数を使用して、過去1時間に記録された指定サービスのプラットフォームイベントを取得します。

  SELECT *
  FROM TABLE(echo_service!SPCS_GET_EVENTS(START_TIME => DATEADD('hour', -1, CURRENT_TIMESTAMP())));
  

  Copy

• **イベントテーブルを直接使用する： ** イベントテーブルを直接クエリできます。アカウントのアクティブなイベントテーブルを見つけるには、 SHOW PARAMETERS コマンドを使用して、 EVENT_TABLE パラメーターの値を確認します。

  SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;
  

  Copy

  パラメーターは、アカウントのアクティブイベントテーブルを指定します。

  次に、そのイベントテーブルをクエリします。次の SELECT ステートメントは、過去1時間に記録された、指定されたサービスのプラットフォームイベントを取得します。

  SELECT TIMESTAMP, RESOURCE_ATTRIBUTES, RECORD, VALUE
    FROM <your_event_table>
    WHERE TIMESTAMP > DATEADD(hour, -1, CURRENT_TIMESTAMP())
      AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<your_service_name>'
      AND RECORD_TYPE = 'EVENT'
      AND SCOPE:"name" = 'snow.spcs.platform'
    ORDER BY TIMESTAMP DESC
    LIMIT 10;
  

  Copy

  イベントテーブルの詳細については、 イベントテーブルの使用 をご参照ください。

  イベントテーブルの次の列は、プラットフォームイベントに関する有用な情報を提供します。

  • TIMESTAMP： イベントがいつ記録されたかを示します。

  • **RESOURCE_ATTRIBUTES：**サービス、コンテナ、コンピューティングプールなど、イベントソースに関するメタデータを含む JSON オブジェクトを提供します。次の resource_attribute 列の値の例では、イベントが記録される特定のサービスを識別します

    {
      "snow.compute_pool.name": "TUTORIAL_COMPUTE_POOL",
      "snow.compute_pool.id": 123,
      "snow.database.name": "TUTORIAL_DB",
      "snow.database.id": 456,
      "snow.schema.name": "DATA_SCHEMA",
      "snow.schema.id": 789,
      "snow.service.container.name": "echo",
      "snow.service.name": "ECHO_SERVICE2",
      "snow.service.id": 212,
      "snow.service.type": "Service"
    }
    

    Copy

  • SCOPE： イベントの基点を示します。プラットフォームイベントの場合、次の例に示すようにスコープの名前は snow.spcs.platform になります

    { "name": "snow.spcs.platform" }
    

    Copy

  • RECORD_TYPE： プラットフォームイベントの場合 EVENT は RECORD_TYPE です。

  • RECORD： 特定のイベントに関するメタデータを提供します。次のメタデータは、プラットフォームイベントの名前と重大度レベルを示します。

    { "name": "CONTAINER.STATUS_CHANGE", "severity_text": "INFO" }
    

    Copy

  • VALUE： イベントの詳細を提供します。次の例は、ステータスと、コンテナのステータスに関するメッセージを示しています。

    { "message": "Running", "status": "READY" }
    

    Copy

サポートされているイベント¶

現在Snowflakeはコンテナステータス変更イベントのみをサポートしています。

次のテーブルは、Snowflakeが記録するプラットフォームイベントのリストです。列名の RECORD および VALUE は、イベントテーブルの列を指します（前のセクションで説明）。