オールインワン
この包括的な Docker イメージには、ClickStack のすべてのオープンソースコンポーネントがバンドルされています:
- ClickHouse
- HyperDX
- OpenTelemetry (OTel) collector(ポート
4317および4318で OTLP をエクスポート) - MongoDB(アプリケーション状態の永続化用)
このオプションでは認証が有効になっており、セッションやユーザーをまたいでダッシュボード、アラート、保存済み検索を永続的に保持できます。
適している用途
- デモ
- フルスタックのローカル環境でのテスト
デプロイ手順
Docker を使用してデプロイする
次のコマンドは、OpenTelemetry collector(ポート 4317 および 4318)と HyperDX UI(ポート 8080)を起動します。
ClickStack のイメージは現在 clickhouse/clickstack-*(以前は docker.hyperdx.io/hyperdx/*)として公開されています。
HyperDX UI にアクセスする
http://localhost:8080 にアクセスして HyperDX UI を開きます。
ユーザーを作成し、要件を満たすユーザー名とパスワードを入力します。
Create をクリックすると、組み込みの ClickHouse インスタンス用のデータソースが作成されます。

別の ClickHouse インスタンスを使用する例については、「ClickHouse Cloud を使用する」を参照してください。
データと設定の永続化
コンテナの再起動後もデータと設定を保持するには、上記の docker コマンドを変更し、/data/db、/var/lib/clickhouse、/var/log/clickhouse-server のパスをマウントします。例えば次のようにします:
本番環境へのデプロイ
次の理由から、このオプションを本番環境にデプロイすることは推奨されません。
- 永続化されないストレージ: すべてのデータは Docker ネイティブのオーバーレイファイルシステムを用いて保存されます。この構成は大規模環境でのパフォーマンス要件を満たせず、コンテナが削除または再起動された場合、ユーザーが必要なファイルパスをマウントしない限りデータは失われます。
- コンポーネントの分離がされていない: すべてのコンポーネントは単一の Docker コンテナ内で実行されます。このため、独立したスケーリングや監視ができず、さらに任意の
cgroup制限がすべてのプロセスに対してグローバルに適用されます。その結果、コンポーネント間で CPU やメモリを奪い合う可能性があります。
ポートのカスタマイズ
HyperDX Local が使用するアプリケーション (8080) や API (8000) のポートをカスタマイズする必要がある場合は、適切なポートをポートフォワードし、いくつかの環境変数を設定するように docker run コマンドを変更する必要があります。
OpenTelemetry のポートは、ポートフォワード用のオプションを変更するだけでカスタマイズできます。たとえば、OpenTelemetry の HTTP ポートを 4999 に変更するには、-p 4318:4318 を -p 4999:4318 に置き換えます。
ClickHouse Cloud を使用する
このディストリビューションは ClickHouse Cloud と併用できます。ローカルの ClickHouse インスタンスも引き続きデプロイされますが(処理には使用されません)、環境変数 CLICKHOUSE_ENDPOINT、CLICKHOUSE_USER、CLICKHOUSE_PASSWORD を設定することで、OTel collector が ClickHouse Cloud インスタンスを使用するように構成できます。
例:
CLICKHOUSE_ENDPOINT には、ポート 8443 を含む ClickHouse Cloud の HTTPS エンドポイントを指定します。例: https://mxl4k3ul6a.us-east-2.aws.clickhouse.com:8443
HyperDX UI に接続したら、Team Settings に移動し、ClickHouse Cloud サービスへの接続を作成し、その後で必要なソースを追加します。
OpenTelemetry collector の設定
必要に応じて OTel collector の設定を変更できます。詳細は "設定の変更" を参照してください。
schema の選択: Map vs JSON
ClickStack では、デフォルトで属性を Map(LowCardinality(String), String) カラムに格納します。これはオブザーバビリティのワークロードに推奨される schema です。バケット化された map のシリアライゼーション と、map のキーおよび値に対するテキスト索引を組み合わせることで、動的な JSON subcolumns で発生するキーごとの取り込みオーバーヘッドなしに、必要な項目を選択的に検索できます。
JSON 型の schema は、属性キーの集合が小さく安定しているワークロードでの評価用として、ベータで利用できます。ただし、デフォルトとしては推奨されません。完全な比較と、JSON サポートを有効にするために必要な環境変数については、Map vs JSON type を参照してください。