メインコンテンツへスキップ
このガイドは既存の ClickHouse Cloud ユーザー向けです。ClickHouse Cloud を初めて利用する場合は、Managed ClickStack 向けの Getting Started ガイドを参照することをお勧めします。 このデプロイパターンでは、ClickHouse と ClickStack UI (HyperDX) の両方が ClickHouse Cloud でホストされるため、ユーザーがセルフホストする必要のあるコンポーネントを最小限に抑えられます。 このデプロイパターンでは、インフラストラクチャ管理の負担が軽減されるだけでなく、認証が ClickHouse Cloud の SSO/SAML と統合されることも保証されます。セルフホストのデプロイとは異なり、ダッシュボード、保存済み検索、ユーザー設定、アラートなどのアプリケーションの状態を保存するための MongoDB インスタンスを用意する必要もありません。さらに、ユーザーは次の利点も得られます。
  • ストレージとは独立したコンピュートの自動スケーリング
  • オブジェクトストレージに基づく低コストかつ実質的に無制限の保持
  • Warehouses により、読み取りワークロードと書き込みワークロードを個別に分離できる
  • 統合された認証
  • 自動バックアップ
  • セキュリティおよびコンプライアンス機能
  • シームレスなアップグレード
このモードでは、データのインジェストは完全にユーザー側で行います。独自にホストした OpenTelemetry Collector、クライアントライブラリからの直接インジェスト、ClickHouse ネイティブのテーブルエンジン (Kafka や S3 など) 、ETL パイプライン、または ClickHouse Cloud のマネージドインジェストサービスである ClickPipes を使用して、Managed ClickStack にデータを取り込むことができます。この方法は、ClickStack を運用するうえで最もシンプルかつ高性能なアプローチです。

適したケース

このデプロイパターンは、次のようなケースに適しています。
  1. すでに ClickHouse Cloud にオブザーバビリティデータがあり、ClickStack を使って可視化したい場合。
  2. 大規模なオブザーバビリティ環境を運用しており、ClickHouse Cloud 上で動作する ClickStack の専用のパフォーマンスとスケーラビリティが必要な場合。
  3. すでに分析用途で ClickHouse Cloud を利用しており、ClickStack のインストルメンテーションライブラリを使ってアプリケーションをインストルメントし、同じクラスターにデータを送信したい場合。この場合は、オブザーバビリティワークロード用のコンピュートを分離するため、warehouses の使用を推奨します。

セットアップ手順

以下のガイドは、すでに ClickHouse Cloud サービスを作成済みであることを前提としています。まだサービスを作成していない場合は、Managed ClickStack の Getting Started ガイドに従ってください。これにより、このガイドと同じ状態、つまり ClickStack が有効になっており、オブザーバビリティデータを受け入れられる状態のサービスが用意されます。

1

新しいサービスを作成する

ClickHouse Cloud のランディングページで New service を選択し、新しいサービスを作成します。
2

プロバイダー、リージョン、リソースを指定する

Scale と Enterpriseほとんどの ClickStack ワークロードには、この Scale tier を推奨します。SAML、CMEK、HIPAA 準拠などの高度なセキュリティ機能が必要な場合は、Enterprise tier を選択してください。また、非常に大規模な ClickStack デプロイメント向けにカスタムのハードウェアプロファイルも利用できます。このような場合は、サポートにお問い合わせいただくことをお勧めします。
Cloud プロバイダーとリージョンを選択します。CPU とメモリを選択する際は、想定される ClickStack のインジェストスループットに基づいて見積もってください。以下の表は、これらのリソースをサイジングする際の目安です。
Monthly ingest volumeRecommended compute
< 10 TB / month2 vCPU × 3 replicas
10–50 TB / month4 vCPU × 3 replicas
50–100 TB / month8 vCPU × 3 replicas
100–500 TB / month30 vCPU × 3 replicas
1 PB+ / month59 vCPU × 3 replicas
これらの推奨値は、次の前提に基づいています。
  • データ量は、月あたりの非圧縮インジェスト量を指し、ログとトレースの両方に適用されます。
  • クエリパターンは、オブザーバビリティの一般的なユースケースを想定しており、ほとんどのクエリは直近のデータ、通常は過去 24 時間を対象とします。
  • インジェストは月全体を通して比較的均一であると想定しています。突発的なトラフィックやスパイクが見込まれる場合は、追加の余裕を持ってプロビジョニングしてください。
  • ストレージは ClickHouse Cloud のオブジェクトストレージで別途処理されるため、保持期間の制約要因にはなりません。長期間保持されるデータは、アクセス頻度が低いことを前提としています。
より長い時間範囲を定期的にクエリするアクセスパターン、負荷の高い集計処理、または多数の同時利用ユーザーをサポートする場合は、さらに多くのコンピュートが必要になることがあります。特定のインジェストスループットに必要な CPU とメモリは 2 つのレプリカでも満たせますが、可能であれば、総容量を同等に保ちながらサービスの冗長性を高めるために 3 つのレプリカを使用することを推奨します。
これらの値はあくまで推定値であり、初期ベースラインとして使用してください。実際に必要なリソースは、クエリの複雑さ、同時実行性、保持ポリシー、インジェストスループットのばらつきによって異なります。常にリソース使用状況を監視し、必要に応じてスケールしてください。
要件を指定すると、Managed ClickStack サービスのプロビジョニングには数分かかります。プロビジョニングの完了を待つ間に、ClickHouse Cloud console の他の部分もご覧ください。プロビジョニングが完了すると、左側メニューの「ClickStack」オプションが有効になります
3

インジェストを設定する

サービスのプロビジョニングが完了したら、そのサービスが選択されていることを確認し、左側のメニューで “ClickStack” をクリックします。「Start Ingestion」を選択すると、インジェストソースを選択するよう求められます。Managed ClickStack では、主要なインジェストソースとして OpenTelemetry と Vector をサポートしています。一方で、ユーザーは ClickHouse Cloud でサポートされているインテグレーション のいずれかを使用して、独自のスキーマでデータを ClickHouse に直接送信することもできます。
OpenTelemetry を推奨インジェスト形式としては、OpenTelemetry の使用を強く推奨します。 ClickStack で効率的に動作するよう特別に設計された、すぐに使えるスキーマが用意されており、最もシンプルかつ最適化された利用体験を提供します。
Managed ClickStack に OpenTelemetry データを送信するには、OpenTelemetry Collector を使用することを推奨します。collector は、アプリケーション (および他の collector) から OpenTelemetry データを受信し、ClickHouse Cloud に転送するゲートウェイとして機能します。まだ collector を実行していない場合は、以下の手順で起動してください。既存の collector がある場合は、設定例も用意されています。

collector を起動する

以下では、追加の処理を含み、ClickHouse Cloud 向けに最適化された、推奨構成である ClickStack distribution of the OpenTelemetry Collector を使用することを前提としています。独自の OpenTelemetry Collector を使用する場合は、“既存の collector を設定する。” を参照してください。すぐに開始するには、表示されている Docker コマンドをコピーして実行してください。このコマンドには、接続 credentials があらかじめ入力されています。
本番環境へのデプロイこのコマンドでは Managed ClickStack への接続に default ユーザーを使用していますが、本番環境に移行する 際は、専用ユーザーを作成し、設定を変更する必要があります。
この 1 つのコマンドを実行すると、ポート 4317 (gRPC) および 4318 (HTTP) で OTLP endpoint を公開した ClickStack collector が起動します。すでに OpenTelemetry のインストルメンテーションと agent がある場合は、すぐにこれらの endpoint へのテレメトリー データ送信を開始できます。

既存の collector を設定する

既存の OpenTelemetry Collectors を設定したり、独自の distribution の collector を使用したりすることも可能です。
ClickHouse exporter が必要独自の distribution を使用する場合、たとえば contrib image を使うなら、ClickHouse exporter が含まれていることを確認してください。
この用途のために、適切な設定で ClickHouse exporter を使用し、OTLP receiver を公開する OpenTelemetry Collector の設定例が提供されています。この設定は、ClickStack distribution で想定されているインターフェイスと動作に合わせています。OpenTelemetry collector の設定について詳しくは、“OpenTelemetry でインジェストする。” を参照してください。

インジェストを開始する (任意)

OpenTelemetry でインストルメントする既存のアプリケーションやインフラストラクチャがある場合は、UI からリンクされている該当ガイドに進んでください。traces と logs を収集するようアプリケーションをインストルメントするには、サポートされている言語 SDKs を使用してください。これらは、Managed ClickStack へのインジェスト用ゲートウェイとして動作する OpenTelemetry Collector にデータを送信します。logs は、agent モードで実行され、同じ collector にデータを転送する OpenTelemetry Collectors を使用して収集 できます。Kubernetes の監視については、専用ガイド を参照してください。その他のインテグレーションについては、quickstart ガイド を参照してください。

デモデータ

既存のデータがない場合は、サンプル dataset のいずれかを試すこともできます。
  • Example dataset - 公開デモからサンプル dataset を読み込みます。単純な問題を診断できます。
  • ローカルファイルとメトリクス - ローカル OTel collector を使用してローカルファイルを読み込み、OSX または Linux 上でシステムを監視します。

4

ClickStack UI に移動する

ClickStack UI (HyperDX) にアクセスするには、[Launch ClickStack] を選択します。自動的に認証され、リダイレクトされます。
OpenTelemetry データ用のデータソースはあらかじめ作成されています。

以上で完了です。🎉さっそく ClickStack を活用してみましょう。ログやトレースを検索し、ログ・トレース・メトリクスの相関をリアルタイムで確認し、ダッシュボードを作成し、サービスマップを確認し、イベントデルタやパターンを見つけ、アラートを設定して問題を未然に把握できます。

その他のタスク

Managed ClickStack へのアクセス権の付与

  1. ClickHouse Cloud コンソールで対象のサービスに移動します
  2. SettingsSQL Console Access に進みます
  3. 各ユーザーに適切な権限レベルを設定します:
    • Service Admin → Full Access - アラートを有効にするために必要です
    • Service Read Only → Read Only - オブザーバビリティデータを表示し、ダッシュボードを作成できます
    • No access - HyperDX にアクセスできません
アラートには管理者アクセスが必要ですアラートを有効にするには、Service Admin 権限を持つユーザー (SQL Console Access のドロップダウンでは Full Access に対応) が少なくとも 1 回 HyperDX にログインする必要があります。これにより、アラートクエリを実行する専用ユーザーがデータベース内に作成されます。

読み取り専用コンピュートで ClickStack を使用する

ClickStack UI は、読み取り専用の ClickHouse Cloud サービス上で完全に実行できます。これは、インジェストとクエリのワークロードを分離したい場合に推奨される構成です。

ClickStack がコンピュートを選択する仕組み

ClickStack UI は常に、ClickHouse Cloud コンソール で起動元となった ClickHouse service に接続します。 これは次のことを意味します。
  • 読み取り専用サービス から ClickStack を開いた場合、ClickStack UI が発行するすべての queries は、その read-only コンピュートで実行されます。
  • read-write service から ClickStack を開いた場合は、ClickStack は代わりにそのコンピュートを使用します。
read-only の動作を実現するために、ClickStack 内で追加の configuration を行う必要はありません。 読み取り専用のコンピュートで ClickStack を実行するには、次の手順に従います。
  1. 読み取り専用として構成された warehouse 内で、ClickHouse Cloud サービスを作成するか、既存のサービスを選択します。
  2. ClickHouse Cloud コンソールで、読み取り専用のサービスを選択します。
  3. 左側のナビゲーションメニューから ClickStack を起動します。
起動後、ClickStack UI は自動的にこの読み取り専用サービスに紐付けられます。

さらにデータソースを追加する

ClickStack は OpenTelemetry をネイティブでサポートしていますが、OpenTelemetry に限定されません。必要に応じて、独自のテーブルスキーマも使用できます。 以下では、自動的に設定されるもの以外に、追加のデータソースをユーザーが追加する方法を説明します。

OpenTelemetry スキーマを使用する

OTel collector を使用して ClickHouse 内にデータベースとテーブルを作成している場合は、ソース作成フォームですべてのデフォルト値をそのまま使用し、ログソースを作成するために Table フィールドに otel_logs を入力します。その他の設定はすべて自動検出されるため、Save New Source をクリックできます。 traces と OTel メトリクスのソースを作成するには、上部メニューから 新しいソースを作成 を選択します。 ここでは、必要なソースタイプを選択してから、適切なテーブルを選択します。たとえば traces の場合は、otel_traces テーブルを選択します。すべての設定は自動検出されます。
ソースの相関付けClickStack 内の異なるデータソース (logs や traces など) は、相互に相関付けることができます。これを有効にするには、各ソースで追加の設定が必要です。たとえば、ログソースでは対応するトレースソースを指定でき、traces ソースではその逆に対応するログソースを指定できます。詳しくは、「相関ソース」を参照してください。

カスタムスキーマの使用

既存のデータを持つサービスに ClickStack を接続する場合は、必要に応じてデータベースとテーブルの設定を行えます。テーブルが ClickHouse 向けの OpenTelemetry スキーマに準拠していれば、設定は自動検出されます。 独自のスキーマを使用する場合は、必要なフィールドが指定されていることを確認したうえで、ログソースを作成することを推奨します。詳細については、「ログソース設定」を参照してください。

スキーマの選択: Map と JSON

ClickStack は、デフォルトで属性を Map(LowCardinality(String), String) カラムとして保存します。これは、オブザーバビリティのワークロードに推奨されるスキーマです。bucketed map serialization と、Map のキーおよび値に対するテキスト索引を組み合わせることで、動的な JSON サブカラムのようにキーごとの取り込みオーバーヘッドを発生させることなく、必要なルックアップだけを効率的に実行できます。 JSON 型のスキーマは、属性キーの集合が小さく安定しているワークロードで評価するためのベータ機能として利用できます。これはデフォルトとしては推奨されません。詳しい比較と、JSON サポートを有効にするために必要な環境変数については、Map と JSON 型の比較 を参照してください。
最終更新日 2026年6月10日