Table of Contents
- はじめに
- Snowflakeにおける観測可能性の重要性を理解する
- Step 1: Snowflakeを始める
- Step 2: OpenTelemetryのインストールと設定
- Step 3: MetricFireのHosted Graphiteを使用してカスタムダッシュボードとアラートを作成
- 効果的なモニタリングのベストプラクティス
- まとめ
はじめに
Snowflakeは、高性能分析用に設計された強力なクラウドベースのデータプラットフォームです。大規模な分析クエリの実行、構造化データおよび半構造化データの管理、データパイプラインの最適化のいずれにおいても、Snowflakeインスタンスの可視化は不可欠です。パフォーマンスのボトルネック、クエリ実行の遅延、予期せぬコストの急上昇は、適切な監視を行わないとすぐに問題になってしまいます。
Snowflakeは、ストレージとコンピュートリソースを分離したスケーラブルなクラウドネイティブプラットフォームを提供することで、データウェアハウスに革命をもたらしました。クリティカルな分析ワークロードにおいてSnowflakeへの依存度が高まる中、最適なパフォーマンスと信頼性を確保することが最重要課題となっています。OpenTelemetry (OTel) を Snowflake 環境に統合することで、システムの挙動を深く可視化し、プロアクティブな監視とトラブルシューティングを可能にします。
このガイドでは、OpenTelemetry（contrib）をSnowflakeに統合して、クエリのパフォーマンス、実行時間、キューイング、ストレージの使用率、課金への影響を可視化する方法を説明します。SnowflakeメトリクスをスクレイピングするためのOpenTelemetry Collectorをセットアップし、データをエクスポートするためのエンドポイントを設定し、よくある落とし穴のトラブルシューティングを行います。最後には、クエリとリソースのパフォーマンスに関する実用的な洞察を提供する、Snowflake用のスケーラブルで自動化されたモニタリングの設定ができるようになります。
Snowflakeにおける観測可能性の重要性を理解する
可観測性（Observability）は、メトリクス、ログ、トレースを通じてシステムの内部状態に関する洞察を提供することで、従来のモニタリングの枠を超えて拡張されます。Snowflakeのコンテキストでは
- メトリクス： メトリクス：クエリの実行時間、ウェアハウスの負荷、ストレージの使用量などの定量的なデータポイント。
- ログ： イベント、エラー、システムメッセージの詳細な記録。
- トレース： 様々なコンポーネントを経由したリクエストのエンドツーエンドのトラッキング。
観測可能性を実装することで、チームは以下のことが可能になります：
Step 1: Snowflakeを始める
本番環境またはテスト環境ですでにSnowflakeインスタンスを実行している場合は、OTel設定のセクションに直接ジャンプできます。そうでない場合、次のセクションでは、テスト目的でCLIツールを使用してSnowflakeの無料トライアルアカウントを設定するためのクイックセットアップガイドを提供します。
スノーフレーク無料トライアルアカウントの作成
Snowflakeは30日間の無料トライアルを提供しており、ウェアハウスの立ち上げ、クエリの実行、パフォーマンスの分析が可能です。こちらからトライアルアカウントを作成し、ログインしたらアカウントのURLを取得してください（これは後で必要になります）：
Snowflake CLIのインストール（Linux）
Snowflake CLI (snow)は、クエリの実行、ユーザーの管理、倉庫の設定をサーバー環境から行うためのコマンドラインインターフェイスを提供します。SnowflakeのCLIインストールのドキュメントはこちらにありますが、Pythonのpipパッケージマネージャを使うのも簡単です：
pip3 install snowflake-cli
SnowSQLをシステムPATHに追加する
デフォルトでは、snowは~/.local/bin/にインストールされます。このディレクトリをサーバーのシステムPATHに追加して、どこからでも（bashで）snowを呼び出せるようにします
export PATH=$HOME/.local/bin:$PATH
echo 'export PATH=$HOME/.local/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
これでバージョンを確認することができます：：
snow --version
Snowflake URLを探す
Snowflake アカウントの URL は、CLI 認証および OTel 設定に必要です。これは、トライアルアカウントの設定（左下）で確認できます：
その後、同様の SQL クエリで Snowflake アカウントへのサーバー接続をテストできます：
snow sql --account <account-name> --user <user-name> -q "SHOW WAREHOUSES;"
サーバーにSnowflake接続をセットアップ
毎回認証情報を手動で入力する代わりに、持続的接続プロファイルを作成することができます。アカウント（ロケータ）とユーザ名のオプションは、Snowflake アカウントの UI にあります：
snow connection add --accountname <account-name> --username <username>
-
いくつかの接続パラメータを定義するよう求められます。そのほとんどは任意だが、Name、Password、Warehouseは必須です。
-
Password（これはあなたのトライアルアカウントのPWです）、Warehouse（デフォルト：COMPUTE_WH）。
- 地域、スキーマ、TLS 設定などのオプションのフィールドは省略できます。
これで、接続が正常に作成されたことを確認し、デフォルト接続として設定することができます：
snow connection list
snow connection set-default <connection-name>
サンプルデータベースとテーブルの作成
テスト用に、サーバーからサンプル売上データセットを作成することができます：
snow sql --connection <connection-name> -q "
CREATE OR REPLACE TABLE MY_TEST_DB.PUBLIC.sales_data (
sale_id INT AUTOINCREMENT PRIMARY KEY,
sale_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
customer_name STRING,
product_name STRING,
quantity INT,
price DECIMAL(10,2)
);"
snow sql --connection <connection-name> -q "
INSERT INTO MY_TEST_DB.PUBLIC.sales_data (customer_name, product_name, quantity, price) VALUES
('Alice Johnson', 'Laptop', 1, 1200.00),
('John Smith', 'Keyboard', 2, 45.00),
('Emily Brown', 'Monitor', 1, 250.00);"
その後、snow sqlのサンプルクエリをいくつか実行することで、DB/テーブルが正常に作成されたことを確認できます：
snow sql --connection <connection-name> -q "
SELECT COUNT(*) FROM MY_TEST_DB.PUBLIC.sales_data;"
snow sql --connection <connection-name> -q "
SELECT SUM(quantity * price) AS total_revenue
FROM MY_TEST_DB.PUBLIC.sales_data;"
Step 2: OpenTelemetryのインストールと設定
OpenTelemetry は、コレクターとして、HAProxy、NGINX、PostgreSQL、Redis、MongoDB、Kafka、Elasticsearch、RabbitMQ、その他多くのためのビルトイン・レシーバー・プラグインを持っています。これらのReceiverは、手動での解析やカスタムスクリプトを必要とすることなく、主要なパフォーマンスメトリクスをサービスから直接取得します。この記事では、あなたのテクノロジースタックで OpenTelemetry を既に使用していることを前提としていますが、以下にシステムレベルのメトリクスを収集し、ストレージエンドポイントにエクスポートするための otelcol-contrib のインストールと設定方法の例を示します。
OpenTelemetry Collector Contrib (Linux) をインストール
パッケージとファイルは通常
/etc/otelcol-contrib/ にインストールされます。Ubuntu/Debian (AMD)
wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.119.0/otelcol-contrib_0.119.0_linux_amd64.deb
sudo dpkg -i otelcol-contrib_0.119.0_linux_amd64.deb
RedHat/CentOS (AMD)
wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.119.0/otelcol-contrib_0.119.0_linux_amd64.rpm
sudo rpm -ivh otelcol-contrib_0.119.0_linux_amd64.rpm
インストールの確認
otelcol-contrib --version
Snowflake ReceiverとCarbon Exporterの設定
OpenTelemetry の Snowflake Receiver は DB のパフォーマンスメトリクスを収集し、処理し、選択したエクスポーターに転送します。
Carbon Exporter はこれらのメトリクスを受け取り、Graphite 互換のバックエンドに直接送信します。これにより、最小限のセットアップで OTel を既存の監視スタックに簡単に統合することができます。
現在、独自のGraphiteデータソースをホスティングしていない場合は、MetricFireのHosted Graphiteで14日間の無料トライアルを開始し、この例に沿って続けてください！
MetricFireアカウントは、Graphiteデータソースを提供し、堅牢なアラート機能、統合機能、チーム機能とともに、可視化ツールとしてHosted Grafanaを含みます。
- まず、一般的に次の場所にある設定ファイルを見つけます： /etc/otelcol-contrib/config.yamlにある設定ファイルを見つけ、お好みのテキストエディタで開きます。
- 次に、ファイルを置き換えるか、現在の設定に以下のセクションを追加します。
- Snowflakeアカウントの認証情報、HG-API-KEY、サーバのHOSTNAMEを必ず含めてください。
receivers:
snowflake:
account: "<account-name>"
username: "<user-name>"
password: "<account-password>"
warehouse: "COMPUTE_WH"
metrics:
snowflake.billing.cloud_service.total: { enabled: true }
snowflake.billing.total_credit.total: { enabled: true }
snowflake.billing.virtual_warehouse.total: { enabled: true }
snowflake.billing.warehouse.cloud_service.total: { enabled: true }
snowflake.billing.warehouse.total_credit.total: { enabled: true }
snowflake.billing.warehouse.virtual_warehouse.total: { enabled: true }
snowflake.logins.total: { enabled: true }
snowflake.pipe.credits_used.total: { enabled: true }
snowflake.query.bytes_spilled.local.avg: { enabled: true }
snowflake.query.bytes_spilled.remote.avg: { enabled: true }
snowflake.query.data_scanned_cache.avg: { enabled: true }
snowflake.query.partitions_scanned.avg: { enabled: true }
snowflake.rows_deleted.avg: { enabled: true }
snowflake.rows_inserted.avg: { enabled: true }
snowflake.rows_produced.avg: { enabled: true }
snowflake.rows_unloaded.avg: { enabled: true }
snowflake.rows_updated.avg: { enabled: true }
snowflake.session_id.count: { enabled: true }
snowflake.storage.failsafe_bytes.total: { enabled: true }
processors:
batch: {}
metricstransform:
transforms:
- include: ".*"
match_type: regexp
action: update
new_name: "<HG-API-KEY>.opentel.$$0"
operations:
- action: add_label
new_label: host
new_value: <HOSTNAME>
exporters:
carbon:
endpoint: "carbon.hostedgraphite.com:2003"
timeout: 10s
service:
pipelines:
metrics:
receivers:
- snowflake
processors:
- batch
- metricstransform
exporters:
- carbon
あとはファイルを保存して、otelcol-contrib サービスを再起動するだけです：
sudo systemctl restart otelcol-contrib
sudo systemctl status otelcol-contrib
あるいは、設定エラーの可能性をトラブルシューティングするために、手動でファイルをサーバーに保存することもできます：
otelcol-contrib --config /etc/otelcol-contrib/config.yaml
snowflake メトリクスがデフォルトのメトリック・エンドポイント（ポート 8888）で収集されていることを確認します：
curl http://localhost:8888/metrics | grep snowflake
考慮すべきこと
- 上記のconfig.yamlファイルは、OTel Snowflake Receiverのドキュメントで定義されているように、すべてのOptional Metricsを有効にします。
- Snowflakeはデータを24時間のバケットに集約するため、特定のメトリクス値は即座に更新されません。
タグされたGraphiteメトリクス
otelcol-contrib サービスを再起動してから 2 分以内に、Tagged Graphite メトリクスのセットが Hosted Graphite アカウントに転送されます（prefixは opentel.snowflake）。
なぜ OpenTelemetry は Tagged メトリクスを Carbon にエクスポートするのか？
- 「そのコアモデルは、Graphiteの 」ドット記法 「フォーマットよりも、Prometheusスタイルの 」ラベル "に適しているからです。データを長いメトリック名にフラット化する代わりに、Graphiteタグを使用することでラベルを保持し、Graphiteバックエンドでのリッチなフィルタリングを可能にします。"
ホストされたGraphiteタグ検索UIで、ホストタグの下にあるこれらのタグ付きメトリクスを見つけることができます：
そうでない場合は、別のエクスポータを構成して、別のデータ・ソースにメトリックを転送できます。
Step 3: MetricFireのHosted Graphiteを使用してカスタムダッシュボードとアラートを作成
Hosted Graphite by MetricFireは、サーバ、データベース、ネットワーク、プロセス、デバイス、アプリケーションからメトリクスやデータを収集、可視化、分析できる監視プラットフォームです。MetricFireを使用することで、インフラストラクチャ内の問題を簡単に特定し、リソースを最適化することができます。
パブリックカーボンエンドポイントに送信されたメトリクスは、タイムスタンプされ、Hosted Graphiteバックエンドに集約されます。
- OpenTelemetryのメトリクスは、Graphiteタグのフォーマットで送信・保存されます。my.series;tag1=value1;tag2=value2 metric_value (timestamp)
- タグはフィルタリングオプションを提供し、メトリクスをクエリのために効率的にします。
- メトリクスは2年間Hosted Graphiteアカウントに保存され、カスタムダッシュボードやアラートの作成に使用できます。
MetricFireのホスト型Grafanaでカスタムダッシュボードを構築する
Hosted Graphite UIで、Dashboardsに移動し、+ New Dashboardを選択して新しい可視化を作成します。
次に、編集モードに移動し、クエリUIを使用してGraphiteメトリックパスを選択します（HGアカウント経由でGrafanaにアクセスしている場合、デフォルトのデータソースはHostedGraphiteになります）。
注：タグ付きメトリクスをクエリするには、seriesByTag Graphite関数を適用する必要があります - aliasByTags関数はオプションですが、メトリクス名をより読みやすくするのに便利です。
Grafanaは、様々なビジュアライゼーション、表示のカスタマイズ、測定単位の設定、ダッシュボード変数やイベントアノテーションの構成などのより高度な機能など、多数の追加オプションを提供します。以下は、OTel Snowflake Receiverによって収集されたメトリクスを使用するプロダクションレベルのダッシュボードの例です：
カスタムGrafanaビジュアライゼーションの構築の詳細については、Hosted Graphite Dashboardのドキュメントを参照してください。
Graphiteアラートの作成
Hosted Graphite UIで、Alerts => Graphite Alertsに移動し、新しいアラートを作成します。アラートに名前を付け、アラートのメトリックフィールドに Tagged Snowflake Metric を追加します：
次に、Alert Criteria タブを選択し、しきい値を設定し、通知チャネルを選択します。デフォルトの通知チャネルは、Hosted Graphiteアカウントにサインアップする際に使用したメールです。それでも、Slack、PagerDuty、Microsoft Teams、OpsGenie、カスタムWebhooksなどのチャンネルを簡単に設定することができます。詳細はHosted Graphiteの通知チャンネルのドキュメントを参照してください：
効果的なモニタリングのベストプラクティス
-
粒度の細かいメトリクス： きめ細かなレベルでメトリクスを収集し、システム動作に関する詳細な洞察を得る。
-
定期的な監査：ワークロードやシステム・アーキテクチャの変化に対応するため、監視設定を定期的に見直し、更新します。
-
セキュリティへの配慮： 適切なアクセス制御と暗号化を行い、遠隔測定データが安全に取り扱われるようにします。
まとめ
OpenTelemetry を Snowflake とセットアップすることで、データウェアハウスのパフォーマンスに対する可視性が強化されます。日々の洞察を Snowflake UI に依存する代わりに、OTel を使用すると、重要なメトリクス（クエリ実行時間、キュー遅延、ストレージ使用量、計算コストなど）をお好みの監視スタックに直接ストリーミングすることができます。これは、パフォーマンスの傾向を追跡し、遅いクエリを早期に特定し、手動による介入を必要とせずにウェアハウスの使用を最適化できることを意味します。クエリの遅延のデバッグ、ウェアハウスのスケーリング、あるいは単純な課金監視のいずれにおいても、OTel はそれをより簡単に、より速く、より自動化します。
OpenTelemetry を Snowflake と統合することで、組織は包括的な観測可能性を獲得し、プロアクティブなパフォーマンス管理と迅速な問題解決を促進することができます。このガイドに記載されたステップに従い、ベスト・プラクティスを遵守することで、チームはSnowflake環境に対するより深い洞察を解き放ち、データ運用の効率性と信頼性を促進することができます。
無料トライアルに登録して、今すぐインフラストラクチャの監視を開始してください。デモを予約して、モニタリングのニーズについてMetricFireチームに直接相談することもできます。
