マネージド | ClickHouse Docs

このガイドは既存の 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 を運用するうえで最もシンプルかつ高性能なアプローチです。

適したケース

このデプロイパターンは、次のようなケースに適しています。

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

セットアップ手順

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

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

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

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

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 のオブジェクトストレージで別途処理されるため、保持期間の制約要因にはなりません。長期間保持されるデータは、アクセス頻度が低いことを前提としています。

より長い時間範囲を定期的にクエリするアクセスパターン、負荷の高い集計処理、または多数の同時利用ユーザーをサポートする場合は、さらに多くのコンピュートが必要になることがあります。

特定のインジェストスループットに必要な CPU とメモリは 2 つのレプリカでも満たせますが、可能であれば、総容量を同等に保ちながらサービスの冗長性を高めるために 3 つのレプリカを使用することを推奨します。

要件を指定すると、Managed ClickStack サービスのプロビジョニングには数分かかります。プロビジョニングの完了を待つ間に、ClickHouse Cloud console の他の部分もご覧ください。

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

インジェストを設定する

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

「Start Ingestion」を選択すると、インジェストソースを選択するよう求められます。Managed ClickStack では、主要なインジェストソースとして OpenTelemetry と Vector をサポートしています。一方で、ユーザーは ClickHouse Cloud でサポートされているインテグレーションのいずれかを使用して、独自のスキーマでデータを ClickHouse に直接送信することもできます。

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 があらかじめ入力されています。

この 1 つのコマンドを実行すると、ポート 4317 (gRPC) および 4318 (HTTP) で OTLP endpoint を公開した ClickStack collector が起動します。すでに OpenTelemetry のインストルメンテーションと agent がある場合は、すぐにこれらの endpoint へのテレメトリーデータ送信を開始できます。

既存の collector を設定する

既存の OpenTelemetry Collectors を設定したり、独自の distribution の collector を使用したりすることも可能です。

この用途のために、適切な設定で ClickHouse exporter を使用し、OTLP receiver を公開する OpenTelemetry Collector の設定例が提供されています。この設定は、ClickStack distribution で想定されているインターフェイスと動作に合わせています。

endpoint と password のプレースホルダーを、ClickStack で生成された認証情報に置き換えます：

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:
  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 でインストルメントする既存のアプリケーションやインフラストラクチャがある場合は、UI からリンクされている該当ガイドに進んでください。

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

logs は、agent モードで実行され、同じ collector にデータを転送する OpenTelemetry Collectors を使用して収集できます。Kubernetes の監視については、専用ガイドを参照してください。その他のインテグレーションについては、quickstart ガイドを参照してください。

デモデータ

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

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

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

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

以下では、インジェストパイプラインがあらかじめ設定され、データを送信している 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 における主キーの仕組みを理解し、アクセスパターンに基づいてソートキーを選ぶことを強く推奨します。主キーの選び方については、ClickStack 向けのガイダンスを参照してください。

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

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

ClickStack UI に移動する

ClickStack UI (HyperDX) にアクセスするには、[Launch ClickStack] を選択します。自動的に認証され、リダイレクトされます。

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

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

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

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

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

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

作成が完了すると、Search view に移動し、すぐにデータの確認を開始できます。

以上で完了です。🎉

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

サービスを選択

ClickHouse Cloud のランディングページで、Managed ClickStack を有効にする対象のサービスを選択します。

Caution - Warning

リソースの見積もり

このガイドでは、ClickStack で取り込みおよびクエリする予定のオブザーバビリティデータ量を処理できる十分なリソースが、あらかじめプロビジョニングされていることを前提としています。必要なリソースを見積もるには、Estimating Resources ガイドを参照してください。

ClickHouse サービスが、リアルタイムのアプリケーション分析などの既存のワークロードをすでにホストしている場合は、オブザーバビリティのワークロードを分離するために、ClickHouse Cloud's warehouses feature を使用して子サービスを作成することをおすすめします。これにより、既存のアプリケーションに影響を与えることなく、両方のサービスからデータセットにアクセスできる状態を維持できます。

ClickStack UI に移動する

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

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

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

この手順が成功したら、これで完了です。準備はすべて整いました 🎉。失敗した場合は、インジェストの設定に進んでください。

インジェストを設定する

自動検出に失敗した場合、または既存のテーブルがない場合は、インジェストのセットアップを行うよう求められます。

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

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

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

collector を起動する

以下では、推奨される方法である ClickStack distribution of the OpenTelemetry Collector の使用を前提としています。これには追加の processing が含まれており、ClickHouse Cloud 向けに最適化されています。独自の OpenTelemetry Collector を使用したい場合は、「既存の collector を設定する」を参照してください。

すばやく始めるには、表示されている Docker コマンドをコピーして実行してください。

このコマンドは、service の作成時に記録した service credentials に合わせて変更してください。

この 1 つのコマンドを実行すると、ポート 4317 (gRPC) および 4318 (HTTP) で OTLP endpoint を公開した ClickStack collector が起動します。すでに OpenTelemetry のインストルメンテーションと agents がある場合は、すぐにこれらの endpoint へのテレメトリーデータ送信を開始できます。

既存の collector を設定する

既存の OpenTelemetry Collectors を設定することも、独自の collector distribution を使用することもできます。

この目的のために、適切な設定で ClickHouse exporter を使用し、OTLP receiver を公開する OpenTelemetry Collector configuration の例が用意されています。この configuration は、ClickStack distribution で想定されるインターフェイスと動作に一致しています。

endpoint と password のプレースホルダーを、ClickStack で生成された認証情報に置き換えます：

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:
  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 collectors の設定の詳細については、「OpenTelemetry でインジェストする」を参照してください。

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

OpenTelemetry でインストルメントする既存のアプリケーションやインフラストラクチャがある場合は、「Connect an application」からリンクされている関連ガイドに進んでください。

アプリケーションをインストルメントして traces と logs を収集するには、サポートされている language SDKs を使用してください。これらは、Managed ClickStack へインジェストするためのゲートウェイとして機能する OpenTelemetry Collector にデータを送信します。

logs は、agent モードで実行される OpenTelemetry Collectors を使用して収集し、同じ collector に転送できます。Kubernetes の監視については、専用ガイドを参照してください。その他のインテグレーションについては、quickstart ガイドを参照してください。

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

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

以下では、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 での主キーの仕組みを理解し、アクセスパターンに基づいてソートキーを選ぶことを強く推奨します。主キーの選び方については、ClickStack 向けのガイダンスを参照してください。

テーブルを作成したら、表示されている設定スニペットをコピーしてください。必要に応じて、既存のパイプラインを使用するように input を調整し、ターゲットテーブルやデータベースも変更してください。認証情報はあらかじめ入力されているはずです。

Vector でデータを取り込むその他の例については、"Vector での取り込み"を参照してください。高度なオプションについては、Vector ClickHouse sink documentationも参照してください。

ClickStack UI に移動する

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

このガイドを使用して OpenTelemetry データを取り込んだ場合、データソースは自動的に作成されるため、追加の設定は不要です。すぐに ClickStack を使い始められます。ログソースが自動的に選択された検索ビューに移動するので、すぐにクエリを開始できます。

これで完了です。準備はすべて整いました 🎉。

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

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

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

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

その他のオプションについては、設定リファレンスを参照してください。

ログソースを設定したら、"Save" をクリックしてデータの確認を開始します。

その他のタスク

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

ClickHouse Cloud コンソールで対象のサービスに移動します
Settings → SQL Console Access に進みます
各ユーザーに適切な権限レベルを設定します:
- Service Admin → Full Access - アラートを有効にするために必要です
- Service Read Only → Read Only - オブザーバビリティデータを表示し、ダッシュボードを作成できます
- No access - 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 を実行するには、次の手順に従います。

読み取り専用として構成された warehouse 内で、ClickHouse Cloud サービスを作成するか、既存のサービスを選択します。
ClickHouse Cloud コンソールで、読み取り専用のサービスを選択します。
左側のナビゲーションメニューから ClickStack を起動します。

起動後、ClickStack UI は自動的にこの読み取り専用サービスに紐付けられます。

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

ClickStack は OpenTelemetry をネイティブでサポートしていますが、OpenTelemetry に限定されません。必要に応じて、独自のテーブルスキーマも使用できます。

以下では、自動的に設定されるもの以外に、追加のデータソースをユーザーが追加する方法を説明します。

OpenTelemetry スキーマを使用する

OTel collector を使用して ClickHouse 内にデータベースとテーブルを作成している場合は、ソース作成フォームですべてのデフォルト値をそのまま使用し、ログソースを作成するために Table フィールドに otel_logs を入力します。その他の設定はすべて自動検出されるため、Save New Source をクリックできます。

traces と OTel メトリクスのソースを作成するには、上部メニューから 新しいソースを作成 を選択します。

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

カスタムスキーマの使用

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

独自のスキーマを使用する場合は、必要なフィールドが指定されていることを確認したうえで、ログソースを作成することを推奨します。詳細については、「ログソース設定」を参照してください。

スキーマの選択: Map と JSON

ClickStack は、デフォルトで属性を Map(LowCardinality(String), String) カラムとして保存します。これは、オブザーバビリティのワークロードに推奨されるスキーマです。bucketed map serialization と、Map のキーおよび値に対するテキスト索引を組み合わせることで、動的な JSON サブカラムのようにキーごとの取り込みオーバーヘッドを発生させることなく、必要なルックアップだけを効率的に実行できます。

JSON 型のスキーマは、属性キーの集合が小さく安定しているワークロードで評価するためのベータ機能として利用できます。これはデフォルトとしては推奨されません。詳しい比較と、JSON サポートを有効にするために必要な環境変数については、Map と JSON 型の比較を参照してください。