Snowpark Container Services: Monitoring Services¶

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 までのデータを返す。

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

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!']]}"
  

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

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

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

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

サービスの実行中、Snowflakeはこれらのメトリクスをアカウントのイベントテーブルに記録します。イベント・テーブルをクエリして、メトリクスを読み取ることができます。次のクエリは、 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;

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

SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

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

例

以下の手順に従って、アカウント用に構成されたイベントテーブルにメトリクスを記録するサービス例を作成します。

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

2. サービスが実行されると、Snowflakeは指定されたメトリクスグループのメトリクスをイベントテーブルに記録し始め、クエリできるようになります。次のクエリは、Echo サービスによって過去 1 時間に報告されたメトリクスを取得します。

   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 の生成を構成する方法を示します。