- ストレージとは独立したコンピュートの自動スケーリング
- オブジェクトストレージに基づく低コストかつ実質的に無制限の保持
- Warehouses により、読み取りワークロードと書き込みワークロードを個別に分離できる
- 統合された認証
- 自動バックアップ
- セキュリティおよびコンプライアンス機能
- シームレスなアップグレード
適したケース
- すでに ClickHouse Cloud にオブザーバビリティデータがあり、ClickStack を使って可視化したい場合。
- 大規模なオブザーバビリティ環境を運用しており、ClickHouse Cloud 上で動作する ClickStack の専用のパフォーマンスとスケーラビリティが必要な場合。
- すでに分析用途で ClickHouse Cloud を利用しており、ClickStack のインストルメンテーションライブラリを使ってアプリケーションをインストルメントし、同じクラスターにデータを送信したい場合。この場合は、オブザーバビリティワークロード用のコンピュートを分離するため、warehouses の使用を推奨します。
セットアップ手順
- 新しいサービスを作成
- 既存のサービスを使用する
新しいサービスを作成する
ClickHouse Cloud のランディングページでNew service を選択し、新しいサービスを作成します。プロバイダー、リージョン、リソースを指定する
Scale と Enterpriseほとんどの ClickStack ワークロードには、この Scale tier を推奨します。SAML、CMEK、HIPAA 準拠などの高度なセキュリティ機能が必要な場合は、Enterprise tier を選択してください。また、非常に大規模な ClickStack デプロイメント向けにカスタムのハードウェアプロファイルも利用できます。このような場合は、サポートにお問い合わせいただくことをお勧めします。

| Monthly ingest volume | Recommended compute |
|---|---|
| < 10 TB / month | 2 vCPU × 3 replicas |
| 10–50 TB / month | 4 vCPU × 3 replicas |
| 50–100 TB / month | 8 vCPU × 3 replicas |
| 100–500 TB / month | 30 vCPU × 3 replicas |
| 1 PB+ / month | 59 vCPU × 3 replicas |
- データ量は、月あたりの非圧縮インジェスト量を指し、ログとトレースの両方に適用されます。
- クエリパターンは、オブザーバビリティの一般的なユースケースを想定しており、ほとんどのクエリは直近のデータ、通常は過去 24 時間を対象とします。
- インジェストは月全体を通して比較的均一であると想定しています。突発的なトラフィックやスパイクが見込まれる場合は、追加の余裕を持ってプロビジョニングしてください。
- ストレージは ClickHouse Cloud のオブジェクトストレージで別途処理されるため、保持期間の制約要因にはなりません。長期間保持されるデータは、アクセス頻度が低いことを前提としています。
これらの値はあくまで推定値であり、初期ベースラインとして使用してください。実際に必要なリソースは、クエリの複雑さ、同時実行性、保持ポリシー、インジェストスループットのばらつきによって異なります。常にリソース使用状況を監視し、必要に応じてスケールしてください。
インジェストを設定する
サービスのプロビジョニングが完了したら、そのサービスが選択されていることを確認し、左側のメニューで “ClickStack” をクリックします。

OpenTelemetry を推奨インジェスト形式としては、OpenTelemetry の使用を強く推奨します。
ClickStack で効率的に動作するよう特別に設計された、すぐに使えるスキーマが用意されており、最もシンプルかつ最適化された利用体験を提供します。
- OpenTelemetry
- Vector
Managed ClickStack に OpenTelemetry データを送信するには、OpenTelemetry Collector を使用することを推奨します。collector は、アプリケーション (および他の collector) から OpenTelemetry データを受信し、ClickHouse Cloud に転送するゲートウェイとして機能します。まだ collector を実行していない場合は、以下の手順で起動してください。既存の collector がある場合は、設定例も用意されています。
このコマンドには、接続 credentials があらかじめ入力されています。この 1 つのコマンドを実行すると、ポート 4317 (gRPC) および 4318 (HTTP) で OTLP endpoint を公開した ClickStack collector が起動します。すでに OpenTelemetry のインストルメンテーションと agent がある場合は、すぐにこれらの endpoint へのテレメトリー データ送信を開始できます。この用途のために、適切な設定で ClickHouse exporter を使用し、OTLP receiver を公開する OpenTelemetry Collector の設定例が提供されています。この設定は、ClickStack distribution で想定されているインターフェイスと動作に合わせています。
OpenTelemetry collector の設定について詳しくは、“OpenTelemetry でインジェストする。” を参照してください。
collector を起動する
以下では、追加の処理を含み、ClickHouse Cloud 向けに最適化された、推奨構成である ClickStack distribution of the OpenTelemetry Collector を使用することを前提としています。独自の OpenTelemetry Collector を使用する場合は、“既存の collector を設定する。” を参照してください。すぐに開始するには、表示されている Docker コマンドをコピーして実行してください。
本番環境へのデプロイこのコマンドでは Managed ClickStack への接続に
default ユーザーを使用していますが、本番環境に移行する 際は、専用ユーザーを作成し、設定を変更する必要があります。既存の collector を設定する
既存の OpenTelemetry Collectors を設定したり、独自の distribution の collector を使用したりすることも可能です。ClickHouse exporter が必要独自の distribution を使用する場合、たとえば contrib image を使うなら、ClickHouse exporter が含まれていることを確認してください。

インジェストを開始する (任意)
OpenTelemetry でインストルメントする既存のアプリケーションやインフラストラクチャがある場合は、UI からリンクされている該当ガイドに進んでください。traces と logs を収集するようアプリケーションをインストルメントするには、サポートされている言語 SDKs を使用してください。これらは、Managed ClickStack へのインジェスト用ゲートウェイとして動作する OpenTelemetry Collector にデータを送信します。logs は、agent モードで実行され、同じ collector にデータを転送する OpenTelemetry Collectors を使用して収集 できます。Kubernetes の監視については、専用ガイド を参照してください。その他のインテグレーションについては、quickstart ガイド を参照してください。デモデータ
既存のデータがない場合は、サンプル dataset のいずれかを試すこともできます。- Example dataset - 公開デモからサンプル dataset を読み込みます。単純な問題を診断できます。
- ローカルファイルとメトリクス - ローカル OTel collector を使用してローカルファイルを読み込み、OSX または Linux 上でシステムを監視します。
ClickStack UI に移動する
ClickStack UI (HyperDX) にアクセスするには、[Launch ClickStack] を選択します。自動的に認証され、リダイレクトされます。- OpenTelemetry
- Vector
OpenTelemetry データ用のデータソースはあらかじめ作成されています。

以上で完了です。🎉さっそく ClickStack を活用してみましょう。ログやトレースを検索し、ログ・トレース・メトリクスの相関をリアルタイムで確認し、ダッシュボードを作成し、サービスマップを確認し、イベントデルタやパターンを見つけ、アラートを設定して問題を未然に把握できます。
その他のタスク
Managed ClickStack へのアクセス権の付与
- ClickHouse Cloud コンソールで対象のサービスに移動します
- Settings → SQL Console Access に進みます
- 各ユーザーに適切な権限レベルを設定します:
- Service Admin → Full Access - アラートを有効にするために必要です
- Service Read Only → Read Only - オブザーバビリティデータを表示し、ダッシュボードを作成できます
- No access - HyperDX にアクセスできません
読み取り専用コンピュートで ClickStack を使用する
ClickStack がコンピュートを選択する仕組み
- 読み取り専用サービス から ClickStack を開いた場合、ClickStack UI が発行するすべての queries は、その read-only コンピュートで実行されます。
- read-write service から ClickStack を開いた場合は、ClickStack は代わりにそのコンピュートを使用します。
推奨構成
- 読み取り専用として構成された warehouse 内で、ClickHouse Cloud サービスを作成するか、既存のサービスを選択します。
- ClickHouse Cloud コンソールで、読み取り専用のサービスを選択します。
- 左側のナビゲーションメニューから ClickStack を起動します。
さらにデータソースを追加する
OpenTelemetry スキーマを使用する
Table フィールドに otel_logs を入力します。その他の設定はすべて自動検出されるため、Save New Source をクリックできます。
traces と OTel メトリクスのソースを作成するには、上部メニューから 新しいソースを作成 を選択します。
ここでは、必要なソースタイプを選択してから、適切なテーブルを選択します。たとえば traces の場合は、otel_traces テーブルを選択します。すべての設定は自動検出されます。
ソースの相関付けClickStack 内の異なるデータソース (logs や traces など) は、相互に相関付けることができます。これを有効にするには、各ソースで追加の設定が必要です。たとえば、ログソースでは対応するトレースソースを指定でき、traces ソースではその逆に対応するログソースを指定できます。詳しくは、「相関ソース」を参照してください。
カスタムスキーマの使用
スキーマの選択: Map と JSON
Map(LowCardinality(String), String) カラムとして保存します。これは、オブザーバビリティのワークロードに推奨されるスキーマです。bucketed map serialization と、Map のキーおよび値に対するテキスト索引を組み合わせることで、動的な JSON サブカラムのようにキーごとの取り込みオーバーヘッドを発生させることなく、必要なルックアップだけを効率的に実行できます。
JSON 型のスキーマは、属性キーの集合が小さく安定しているワークロードで評価するためのベータ機能として利用できます。これはデフォルトとしては推奨されません。詳しい比較と、JSON サポートを有効にするために必要な環境変数については、Map と JSON 型の比較 を参照してください。
