マネージド版 ClickStack 入門

Beta feature. Learn more.

Managed ClickStack を ClickHouse Cloud 上にデプロイする方法が、最も簡単な始め方です。これにより、インジェスト、スキーマ、オブザーバビリティのワークフローを完全に制御しつつ、フルマネージドでセキュアなバックエンドが提供されます。これによって自前で ClickHouse を運用する必要がなくなり、次のような多くの利点が得られます。

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

ClickHouse Cloud にサインアップする

ClickHouse Cloud で Managed ClickStack サービスを作成するには、まず ClickHouse Cloud クイックスタートガイド の 最初のステップ を完了してください。

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

次のステップ

デフォルト認証情報を記録する

上記の手順の中でデフォルトの認証情報を記録していない場合は、サービスに移動して Connect を選択し、パスワードおよび HTTP/ネイティブエンドポイントを記録してください。これらの管理者認証情報は安全に保管し、他のガイドでも再利用できるようにしておきます。

新しいユーザーのプロビジョニングや追加のデータソースの追加などの作業を行うには、Managed ClickStack のデプロイガイド を参照してください。