マネージド版

Beta feature. Learn more.

ベータ機能

この機能は ClickHouse Cloud のベータ版です。

このガイドは既存の ClickHouse Cloud ユーザー向けです。ClickHouse Cloud を初めて利用する場合は、Managed ClickStack 向けの 入門ガイド を参照してください。

このデプロイメントパターンでは、ClickHouse と ClickStack UI (HyperDX) の両方が ClickHouse Cloud 上でホストされ、ユーザーがセルフホストする必要があるコンポーネント数を最小限に抑えられます。

インフラ管理を削減するだけでなく、このデプロイメントパターンでは認証が ClickHouse Cloud の SSO/SAML と統合されます。セルフホスト型のデプロイメントとは異なり、ダッシュボード、保存済み検索、ユーザー設定、アラートといったアプリケーション状態を保存するための MongoDB インスタンスをプロビジョニングする必要もありません。ユーザーは次のような利点も得られます:

• ストレージとは独立したコンピュートの自動スケーリング
• オブジェクトストレージに基づいた低コストかつ事実上無制限の保持期間
• Warehouse を用いて読み取りと書き込みのワークロードを個別に分離できる機能
• 統合された認証
• 自動バックアップ
• セキュリティおよびコンプライアンス機能
• シームレスなアップグレード

このモードでは、データのインジェストは完全にユーザー側で行います。Managed ClickStack へのデータのインジェストには、独自にホストした OpenTelemetry collector、クライアントライブラリからの直接インジェスト、ClickHouse ネイティブのテーブルエンジン (Kafka や S3 など)、ETL パイプライン、あるいは ClickHouse Cloud のマネージドインジェストサービスである ClickPipes を利用できます。このアプローチは、ClickStack を運用するうえで最もシンプルかつ高性能な方法です。

適しているケース

このデプロイメントパターンは、次のようなシナリオに最適です。

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

セットアップ手順

このガイドでは、すでに ClickHouse Cloud サービスを作成済みであることを前提としています。まだサービスを作成していない場合は、Managed ClickStack 用の はじめに ガイドに従ってください。これにより、本ガイドと同じ状態、すなわち ClickStack が有効化され、オブザーバビリティデータをインジェストする準備が整ったサービスが用意されます。

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

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

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

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

Scale vs Enterprise

ほとんどの ClickStack ワークロードには、この Scale ティア を推奨します。SAML、CMEK、HIPAA 準拠などの高度なセキュリティ機能が必要な場合は、Enterprise ティアを選択してください。Enterprise ティアでは、非常に大規模な ClickStack デプロイメント向けのカスタムハードウェアプロファイルも提供されます。そのような場合は、サポートまでお問い合わせください。

Cloud プロバイダーとリージョンを選択します。

CPU とメモリを指定する際は、想定される 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 のオブジェクトストレージによって個別に処理され、保持期間の制約要因にはなりません。長期間保持されるデータは、頻繁にはアクセスされないことを前提としています。

より長い期間にわたるクエリ、重い集約処理、大量の同時ユーザー数を定常的にサポートするアクセスパターンがある場合は、さらに多くのコンピュートリソースが必要になる可能性があります。

2 つのレプリカでも、特定のインジェストスループットに対する CPU およびメモリ要件を満たすことはできますが、可能であれば 3 つのレプリカを使用して同じ合計キャパシティを確保しつつ、サービスの冗長性を高めることを推奨します。

注記

これらの値はあくまで推定値であり、初期のベースラインとして使用してください。実際の要件は、クエリの複雑さ、同時実行数、保持ポリシー、およびインジェストスループットの変動に依存します。常にリソース使用状況を監視し、必要に応じてスケールしてください。

要件を指定すると、Managed ClickStack サービスのプロビジョニングに数分かかります。プロビジョニングを待つ間、ClickHouse Cloud コンソール の他の部分を自由に閲覧できます。

プロビジョニングが完了すると、左側メニューの 'ClickStack' オプションが有効になります。

インジェストをセットアップする

サービスのプロビジョニングが完了したら、対象のサービスが選択されていることを確認し、左側のメニューから「ClickStack」をクリックします。

「Start Ingestion」を選択すると、インジェストソースの選択を求められます。Managed ClickStack は、主なインジェストソースとして OpenTelemetry と Vector をサポートしています。ただし、ユーザーは任意の ClickHouse Cloud support integrations を利用して、独自のスキーマで ClickHouse に直接データを送信することもできます。

OpenTelemetry の利用を推奨

インジェスト形式としては、OpenTelemetry の利用を強く推奨します。 ClickStack と効率的に連携するよう特別に設計された、すぐに利用可能なスキーマを備えており、もっともシンプルかつ最適化された利用体験を提供します。

OpenTelemetry

Managed ClickStackにOpenTelemetryデータを送信する場合は、OpenTelemetry Collectorを使用することを推奨します。コレクターは、アプリケーション(および他のコレクター)からOpenTelemetryデータを受信し、それを ClickHouse Cloud に転送するゲートウェイとして機能します。

まだコレクターが動作していない場合は、以下の手順でコレクターを起動してください。既存のコレクターがある場合は、設定例も提供しています。

コレクターを起動する

以下では、追加の処理を含み、ClickHouse Cloud向けに最適化された ClickStack distribution of the OpenTelemetry Collector を使用する推奨パスを前提としています。独自のOpenTelemetry Collectorを使用する場合は、「既存のコレクターの設定」を参照してください。

すぐに開始するには、表示されているDockerコマンドをコピーして実行します。

このコマンドには、接続認証情報があらかじめ埋め込まれています。

本番環境へのデプロイ

このコマンドはManaged ClickStackへの接続にdefaultユーザーを使用していますが、本番環境に移行する際には専用ユーザーを作成し、設定を変更してください。

このコマンドを1回実行するだけで、ポート4317(gRPC)および4318(HTTP)でOTLPエンドポイントが公開されたClickStackコレクターが起動します。既にOpenTelemetryインストルメンテーションとエージェントを使用している場合は、これらのエンドポイントへのテレメトリデータ送信を直ちに開始できます。

既存のコレクターの設定

既存のOpenTelemetryコレクターを設定したり、独自のコレクターディストリビューションを使用したりすることも可能です。

ClickHouse exporter required

独自のディストリビューション(例: contrib イメージ)を使用している場合は、ClickHouse exporter が含まれていることを確認してください。

この目的のために、適切な設定でClickHouseエクスポーターを使用し、OTLPレシーバーを公開するOpenTelemetry Collectorの設定例が提供されています。この設定は、ClickStackディストリビューションが期待するインターフェースと動作に一致します。

この構成の例を次に示します（UI からコピーした場合、環境変数はあらかじめ設定されています）。

receivers:
  otlp/hyperdx:
    protocols:
      grpc:
        include_metadata: true
        endpoint: "0.0.0.0:4317"
      http:
        cors:
          allowed_origins: ["*"]
          allowed_headers: ["*"]
        include_metadata: true
        endpoint: "0.0.0.0:4318"
processors:
  batch:
  memory_limiter:
    # 80% of maximum memory up to 2G, adjust for low memory environments
    limit_mib: 1500
    # 25% of limit up to 2G, adjust for low memory environments
    spike_limit_mib: 512
    check_interval: 5s
connectors:
  routing/logs:
    default_pipelines: [logs/out-default]
    error_mode: ignore
    table:
      - context: log
        statement: route() where IsMatch(attributes["rr-web.event"], ".*")
        pipelines: [logs/out-rrweb]
exporters:
  debug:
    verbosity: detailed
    sampling_initial: 5
    sampling_thereafter: 200
  clickhouse/rrweb:
    database: default
    endpoint: <clickhouse_cloud_endpoint>
    password: <your_password_here>
    username: default
    ttl: 720h
    logs_table_name: hyperdx_sessions
    timeout: 5s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s
  clickhouse:
    database: default
    endpoint: <clickhouse_cloud_endpoint>
    password: <your_password_here>
    username: default
    ttl: 720h
    timeout: 5s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s

service:
  pipelines:
    traces:
      receivers: [otlp/hyperdx]
      processors: [memory_limiter, batch]
      exporters: [clickhouse]
    metrics:
      receivers: [otlp/hyperdx]
      processors: [memory_limiter, batch]
      exporters: [clickhouse]
    logs/in:
      receivers: [otlp/hyperdx]
      exporters: [routing/logs]
    logs/out-default:
      receivers: [routing/logs]
      processors: [memory_limiter, batch]
      exporters: [clickhouse]
    logs/out-rrweb:
      receivers: [routing/logs]
      processors: [memory_limiter, batch]
      exporters: [clickhouse/rrweb]

OpenTelemetryコレクターの設定の詳細については、「OpenTelemetryでのデータ取り込み」を参照してください。

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

既存のアプリケーションやインフラストラクチャでOpenTelemetryによるインストルメンテーションを行う場合は、UIからリンクされている該当ガイドに進んでください。

アプリケーションをインストルメントしてトレースとログを収集するには、サポートされている言語SDKを使用します。これらは、Managed ClickStackへのインジェストのためのゲートウェイとして動作するOpenTelemetry Collectorにデータを送信します。

ログは、エージェントモードで動作し同じコレクターにデータを転送するOpenTelemetry Collectorを使用して収集できます。Kubernetesの監視については、専用ガイドに従ってください。他のインテグレーションについては、クイックスタートガイドを参照してください。

デモデータ

あるいは、既存データがない場合は、サンプルデータセットのいずれかを試すこともできます。

• Example dataset - 公開デモからサンプルデータセットをロードし、簡単な問題の診断を行います。
• Local files and metrics - ローカルのOTel collectorを使用して、OSXまたはLinux上でローカルファイルを読み込み、システムを監視します。

Vector

Vector は、高性能でベンダーに依存しないオブザーバビリティデータパイプラインであり、柔軟性とリソース消費の少なさから、特にログのインジェスト用途で広く利用されています。

ClickStack と併用する場合、Vector ではスキーマ定義をユーザー自身が行う必要があります。これらのスキーマは OpenTelemetry の規約に従ってもよいですし、ユーザー定義イベント構造を表す完全にカスタムなものでも構いません。

タイムスタンプ必須

Managed ClickStack における唯一の厳密な要件は、データに タイムスタンプカラム（または同等の時刻フィールド）が含まれていることです。これは ClickStack UI でデータソースを設定する際に宣言できます。

以下では、データを配信するためのインジェストパイプラインが事前に設定された Vector インスタンスが稼働していることを前提とします。

データベースとテーブルを作成する

Vector では、データをインジェストする前にテーブルとスキーマを定義しておく必要があります。

まずデータベースを作成します。これは ClickHouse Cloud console から行えます。

たとえば、ログ用のデータベースを作成します。

CREATE DATABASE IF NOT EXISTS logs

次に、ログデータの構造に対応したスキーマを持つテーブルを作成します。以下の例では、クラシックな Nginx アクセスログ形式を想定しています。

CREATE TABLE logs.nginx_logs
(
    `time_local` DateTime,
    `remote_addr` IPv4,
    `remote_user` LowCardinality(String),
    `request` String,
    `status` UInt16,
    `body_bytes_sent` UInt64,
    `http_referer` String,
    `http_user_agent` String,
    `http_x_forwarded_for` LowCardinality(String),
    `request_time` Float32,
    `upstream_response_time` Float32,
    `http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);

テーブルは、Vector によって生成される出力スキーマと一致している必要があります。推奨されるスキーマ設計のベストプラクティスに従い、データに合わせてスキーマを調整してください。

ClickHouse におけるPrimary keysの動作を理解し、アクセスパターンに基づいて順序キーを選択することを強く推奨します。主キーの選択については、ClickStack 固有のガイダンスを参照してください。

テーブルを作成したら、表示されている設定スニペットをコピーします。既存のパイプラインを取り込めるよう入力を調整し、必要に応じて対象テーブルおよびデータベースも変更してください。認証情報は事前に入力されているはずです。

Vector を用いたデータ取り込みの例については、"Ingesting with Vector" または高度なオプションについて Vector ClickHouse sink documentation を参照してください。

ClickStack UI に移動する

'Launch ClickStack' を選択して ClickStack UI (HyperDX) にアクセスします。自動的に認証が行われ、リダイレクトされます。

OpenTelemetry

OpenTelemetry のデータについては、データソースがあらかじめ作成されています。

Vector

Vector を使用している場合は、データソースを自分で作成する必要があります。初回ログイン時にデータソース作成を促すメッセージが表示されます。以下に、ログ用データソースの設定例を示します。

この設定は、タイムスタンプとして使用される time_local カラムを持つ Nginx 形式のスキーマを前提としています。可能であれば、これは PRIMARY KEY で定義されているタイムスタンプカラムであるべきです。このカラムは必須です。

また、Default SELECT を更新し、ログビューで返されるカラムを明示的に指定することを推奨します。サービス名、ログレベル、または body カラムなどの追加フィールドがある場合は、それらも設定できます。テーブルの PRIMARY KEY で使用しているカラムと異なる場合は、表示用のタイムスタンプカラムも上書き設定できます。

上記の例では、データに Body カラムは存在しません。その代わり、利用可能なフィールドから Nginx のログ行を再構築する SQL 式として定義しています。

他に利用可能なオプションについては、configuration reference を参照してください。

作成が完了すると、検索ビューに遷移し、すぐにデータの探索を開始できます。

以上で完了です。🎉

ClickStack を使って、ログやトレースの検索を開始し、ログ・トレース・メトリクスがリアルタイムにどのように相関付けられるかを確認し、ダッシュボードを構築し、サービスマップを探索し、イベントの差分やパターンを発見し、アラートを設定して問題を先回りで検知できるようにしましょう。

既存のサービスを使用する

サービスを選択する

ClickHouse Cloud のランディングページから、マネージド ClickStack を有効化したいサービスを選択します。

リソースの見積もり

本ガイドは、ClickStackで取り込みとクエリを実行する予定のオブザーバビリティデータ量を処理するために、十分なリソースがプロビジョニング済みであることを前提としています。必要なリソースを見積もるには、本番環境ガイドを参照してください。

ClickHouseサービスが既にリアルタイムアプリケーション分析などの既存のワークロードをホストしている場合は、ClickHouse Cloudのウェアハウス機能を使用して子サービスを作成し、オブザーバビリティワークロードを分離することを推奨します。これにより、既存のアプリケーションを中断することなく、両方のサービスからデータセットへのアクセスを維持できます。

ClickStack UI に移動する

左側のナビゲーションメニューから'ClickStack'を選択します。ClickStack UIにリダイレクトされ、ClickHouse Cloudの権限に基づいて自動的に認証されます。

サービス内に OpenTelemetry テーブルが既に存在する場合、自動的に検出され、対応するデータソースが作成されます。

データソースの自動検出

自動検出は、ClickStack ディストリビューションの OpenTelemetry コレクターが提供する標準 OpenTelemetry テーブルスキーマに依存しています。最も完全なテーブルセットを持つデータベースに対してソースが作成されます。必要に応じて、追加のテーブルを個別のデータソースとして追加することができます。

自動検出が成功すると、検索ビューに遷移し、すぐにデータの探索を開始できます。

このステップが成功した場合、これで完了です 🎉。そうでない場合は、インジェストのセットアップに進んでください。

インジェストをセットアップする

自動検出が失敗した場合、または既存のテーブルが存在しない場合は、インジェストの設定を求められます。

"Start Ingestion"を選択すると、インジェストソースの選択を求められます。マネージドClickStackは、主なインジェストソースとしてOpenTelemetryとVectorをサポートしています。ただし、ユーザーはClickHouse Cloudサポート統合のいずれかを使用して、独自のスキーマでClickHouseに直接データを送信することも可能です。

OpenTelemetry推奨

インジェスト形式としてOpenTelemetryの使用を強く推奨します。 ClickStackで効率的に動作するように特別に設計された標準スキーマを備えており、最もシンプルで最適化されたエクスペリエンスを提供します。

OpenTelemetry

Managed ClickStack に OpenTelemetry データを送信するには、OpenTelemetry Collector を使用することが推奨されます。Collector はゲートウェイとして動作し、アプリケーション（および他の Collector）から OpenTelemetry データを受信し、それを ClickHouse Cloud に転送します。

まだ Collector を稼働させていない場合は、以下の手順に従って Collector を起動してください。既存の Collector がある場合は、設定例も用意されています。

Collector を起動する

以下では、ClickStack ディストリビューション版 OpenTelemetry Collector を使用する推奨パスを前提とします。このディストリビューションには追加の処理が含まれており、ClickHouse Cloud 向けに最適化されています。独自の OpenTelemetry Collector を使用したい場合は、「既存の Collector を設定する」を参照してください。

すぐに開始するには、表示されている Docker コマンドをコピーして実行します。

このコマンドは、サービス作成時に記録したサービス認証情報に置き換えてから実行してください。

本番環境へのデプロイ

このコマンドでは default ユーザーを使って Managed ClickStack に接続していますが、本番環境に移行する際には専用のユーザーを作成し、それに合わせて設定を変更する必要があります。

この 1 つのコマンドを実行すると、ClickStack Collector が起動し、ポート 4317（gRPC）および 4318（HTTP）で OTLP エンドポイントが公開されます。すでに OpenTelemetry のインストルメンテーションやエージェントがある場合は、すぐにこれらのエンドポイントにテレメトリーデータを送信し始めることができます。

既存の Collector を設定する

既存の OpenTelemetry Collector を設定したり、独自のディストリビューションの Collector を使用したりすることも可能です。

ClickHouse exporter が必須

独自のディストリビューションを使用する場合、たとえば contrib イメージ を使う場合は、ClickHouse exporter が含まれていることを確認してください。

この目的のために、ClickHouse exporter を適切な設定で使用し、OTLP receiver を公開する OpenTelemetry Collector のサンプル設定を用意しています。この設定は、ClickStack ディストリビューションが想定するインターフェースと動作に一致しています。

この構成の例を次に示します（UI からコピーした場合、環境変数はあらかじめ設定されています）。

receivers:
  otlp/hyperdx:
    protocols:
      grpc:
        include_metadata: true
        endpoint: "0.0.0.0:4317"
      http:
        cors:
          allowed_origins: ["*"]
          allowed_headers: ["*"]
        include_metadata: true
        endpoint: "0.0.0.0:4318"
processors:
  batch:
  memory_limiter:
    # 80% of maximum memory up to 2G, adjust for low memory environments
    limit_mib: 1500
    # 25% of limit up to 2G, adjust for low memory environments
    spike_limit_mib: 512
    check_interval: 5s
connectors:
  routing/logs:
    default_pipelines: [logs/out-default]
    error_mode: ignore
    table:
      - context: log
        statement: route() where IsMatch(attributes["rr-web.event"], ".*")
        pipelines: [logs/out-rrweb]
exporters:
  debug:
    verbosity: detailed
    sampling_initial: 5
    sampling_thereafter: 200
  clickhouse/rrweb:
    database: default
    endpoint: <clickhouse_cloud_endpoint>
    password: <your_password_here>
    username: default
    ttl: 720h
    logs_table_name: hyperdx_sessions
    timeout: 5s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s
  clickhouse:
    database: default
    endpoint: <clickhouse_cloud_endpoint>
    password: <your_password_here>
    username: default
    ttl: 720h
    timeout: 5s
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s

service:
  pipelines:
    traces:
      receivers: [otlp/hyperdx]
      processors: [memory_limiter, batch]
      exporters: [clickhouse]
    metrics:
      receivers: [otlp/hyperdx]
      processors: [memory_limiter, batch]
      exporters: [clickhouse]
    logs/in:
      receivers: [otlp/hyperdx]
      exporters: [routing/logs]
    logs/out-default:
      receivers: [routing/logs]
      processors: [memory_limiter, batch]
      exporters: [clickhouse]
    logs/out-rrweb:
      receivers: [routing/logs]
      processors: [memory_limiter, batch]
      exporters: [clickhouse/rrweb]

OpenTelemetry Collector の詳細な設定方法については、「OpenTelemetry を使ったインジェスト」を参照してください。

インジェストを開始する（任意）

すでに OpenTelemetry でインストルメントする対象となるアプリケーションやインフラストラクチャがある場合は、「Connect an application」からリンクされている関連ガイドを参照してください。

アプリケーションをインストルメントしてトレースやログを収集するには、サポートされている言語 SDKs を使用します。これらはテレメトリーデータを、Managed ClickStack へのインジェストのゲートウェイとして動作する OpenTelemetry Collector に送信します。

ログは、エージェントモードで稼働し、同じ Collector にデータを転送する OpenTelemetry Collector を使用して収集できます。Kubernetes の監視については、専用ガイド に従ってください。その他の連携については、クイックスタートガイド を参照してください。

Vector

Vector は高性能でベンダーニュートラルなオブザーバビリティデータパイプラインであり、柔軟性と小さいリソースフットプリントにより、特にログのインジェストで高い人気があります。

Vector を ClickStack と併用する場合、スキーマの定義はユーザーの責任となります。これらのスキーマは OpenTelemetry の規約に従っていてもよいですし、完全にカスタムで、ユーザー定義のイベント構造を表現していてもかまいません。

タイムスタンプが必須

Managed ClickStack における唯一の厳格な要件は、データに timestamp column（または同等の時刻フィールド）が含まれていることです。これは ClickStack UI でデータソースを設定する際に宣言できます。

以下では、Vector のインスタンスがすでに稼働しており、事前に設定されたインジェストパイプラインを通じてデータを送信しているものとします。

データベースとテーブルを作成する

Vector では、データのインジェスト前にテーブルとスキーマを定義しておく必要があります。

まずデータベースを作成します。これは ClickHouse Cloud コンソール から実行できます。

たとえば、ログ用のデータベースを作成します。

CREATE DATABASE IF NOT EXISTS logs

次に、ログデータの構造に合致したスキーマを持つテーブルを作成します。以下の例では、一般的な Nginx アクセスログ形式を想定しています。

CREATE TABLE logs.nginx_logs
(
    `time_local` DateTime,
    `remote_addr` IPv4,
    `remote_user` LowCardinality(String),
    `request` String,
    `status` UInt16,
    `body_bytes_sent` UInt64,
    `http_referer` String,
    `http_user_agent` String,
    `http_x_forwarded_for` LowCardinality(String),
    `request_time` Float32,
    `upstream_response_time` Float32,
    `http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);

テーブルは、Vector が生成する出力スキーマに合致している必要があります。データに合わせて、必要に応じてスキーマを調整し、推奨されるスキーマのベストプラクティスに従ってください。

ClickHouse におけるPrimary keysの仕組みを理解し、アクセスパターンに基づいて並び替えキーを選択することを強く推奨します。Primary key の選択については、ClickStack 固有のガイドラインを参照してください。

テーブルが作成できたら、表示されている設定スニペットをコピーします。既存のパイプラインを取り込めるように input セクションを調整し、必要に応じて対象テーブルおよびデータベースも変更します。クレデンシャルは事前に自動的に入力されているはずです。

Vector を使ってデータを取り込む他の例については、「Ingesting with Vector」または高度なオプションについての Vector ClickHouse sink ドキュメント を参照してください。

ClickStack UI に移動する

インジェストの設定を完了し、データの送信を開始したら、"Next"を選択してください。

OpenTelemetry

このガイドに従って OpenTelemetry データを取り込んでいる場合、データソースは自動的に作成されるため、追加のセットアップは不要です。すぐに ClickStack の探索を開始できます。検索ビューに、自動的にデータソースが選択された状態で遷移するため、直ちにクエリを実行し始めることができます。

以上で完了です — これですべての準備が整いました 🎉。

Vector

Vector 経由でデータを取り込んだ場合や、別のソースから取り込んでいる場合は、データソースの設定を行うよう求められます。

上記の設定は、time_local カラムをタイムスタンプとして使用する Nginx 形式のスキーマを前提としています。可能であれば、これはプライマリキーで宣言されているタイムスタンプカラムであるべきです。このカラムは必須です。

また、Default SELECT を更新して、ログビューで返されるカラムを明示的に定義することを推奨します。サービス名、ログレベル、本文カラムなど、追加のフィールドが利用可能な場合は、それらも設定できます。テーブルのプライマリキーで使用しているカラムと異なる場合には、タイムスタンプの表示に使用するカラムも上書き可能です。

上記の例では、データ内に Body カラムは存在しません。その代わりに、利用可能なフィールドから Nginx のログ行を再構成する SQL 式として定義しています。

その他に利用可能なオプションについては、configuration reference を参照してください。

データソースの設定が完了したら、「Save」をクリックして、データの探索を開始します。

追加の作業

Managed ClickStack へのアクセス権を付与する

1. ClickHouse Cloud コンソールで対象のサービスに移動します
2. Settings → SQL Console Access を開きます
3. 各ユーザーに対して適切な権限レベルを設定します:
   • Service Admin → Full Access - アラートを有効化するために必須
   • Service Read Only → Read Only - オブザーバビリティデータの閲覧とダッシュボードの作成が可能
   • No access - HyperDX にアクセスできない

アラートには管理者アクセスが必要です

アラートを有効化するには、少なくとも 1 人の Service Admin 権限を持つユーザー（SQL Console Access のドロップダウンで Full Access にマッピング）が、少なくとも一度は HyperDX にログインしている必要があります。これにより、アラートクエリを実行する専用ユーザーがデータベース内にプロビジョニングされます。

読み取り専用コンピュート環境での ClickStack の利用

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

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

ClickStack UI は、ClickHouse Cloud コンソール内で起動元となった ClickHouse サービスに常に接続します。

これは次のことを意味します。

• 読み取り専用サービスから ClickStack を開いた場合、ClickStack UI が発行するすべてのクエリは、その読み取り専用コンピュート上で実行されます。
• 読み書き可能サービスから ClickStack を開いた場合は、ClickStack は代わりにそのコンピュートを使用します。

読み取り専用動作を強制するために、ClickStack 内で追加の設定を行う必要はありません。

推奨セットアップ

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 をクリックできます。

トレースおよび OTel メトリクス用のソースを作成するには、上部メニューから Create New Source を選択します。

ここから、必要なソースタイプを選択し、続いて適切なテーブルを選択します。例えばトレースの場合は、テーブル otel_traces を選択します。すべての設定は自動検出されます。

ソースの相関付け

ClickStack 内の異なるデータソース（ログやトレースなど）は、互いに相関付けることができます。これを有効にするには、各ソースで追加の設定が必要です。例えば、ログソースでは対応するトレースソースを指定でき、逆にトレースソース側でもログソースを指定できます。詳細は 「相関ソース」 を参照してください。

カスタムスキーマの使用

既存のサービスの既存データに ClickStack を接続したいユーザーは、必要に応じてデータベースおよびテーブルの設定を行えます。テーブルが ClickHouse 向けの OpenTelemetry スキーマに準拠している場合、設定は自動検出されます。

独自スキーマを使用する場合は、必須フィールドが指定されていることを確認したうえで Logs ソースを作成することを推奨します。詳細は「Log source settings」を参照してください。

JSON 型サポート

Beta feature. Learn more.

ベータ機能 - 本番環境向けではありません

ClickStack における JSON 型サポートは ベータ機能 です。JSON 型自体は ClickHouse 25.3+ では本番環境向けとして利用可能ですが、ClickStack との統合はまだ積極的に開発中であり、制限があったり、将来的に変更されたり、不具合を含む可能性があります。

ClickStack では、バージョン 2.0.4 以降で JSON 型 をベータ機能としてサポートしています。

この型の利点については JSON 型の利点 を参照してください。

JSON 型のサポートを有効にするには、以下の環境変数を設定する必要があります。

• OTEL_AGENT_FEATURE_GATE_ARG='--feature-gates=clickhouse.json' - OTel collector でのサポートを有効にし、スキーマが JSON 型を使用して作成されるようにします。
• BETA_CH_OTEL_JSON_SCHEMA_ENABLED=true (ClickStack オープンソース版のみ) - ClickStack UI アプリケーションでのサポートを有効にし、JSON データに対してクエリを実行できるようにします。

加えて、ClickHouse Cloud サービスで JSON が有効化されていることを確認するため、[email protected] にお問い合わせください。