ClickHouse の新しい TimeSeries エンジンのご紹介: Prometheus のドロップイン代替

TL;DR: チームがすでに頼りにしている PromQL クエリを書き直すことなく、Prometheus のメトリクスを ClickHouse Cloud に保存してクエリできます。プライベートプレビューでは、Prometheus のリモートライトでメトリクスを送信し、ClickStack、Grafana、または ClickHouse から PromQL でクエリできます。

本日、ClickHouse Cloud における PromQL と TimeSeries テーブルエンジンのプライベートプレビューを、ClickStack での PromQL サポートとあわせて発表します。

ClickHouse は、すでに多くのチームがログやトレースを保管している場所です。今回、Prometheus を使うチームも、既存の PromQL クエリを SQL に書き直すことなく、同じ場所にメトリクスを保存してクエリできるようになります。

Prometheus のリモートライトでメトリクスを送信すると、TimeSeries テーブルに格納されます。このテーブルは、時系列データ専用に設計された ClickHouse のストレージエンジンの上に構築されています。クエリは ClickStack、Grafana、または ClickHouse から PromQL で実行します。言語は変わりません。変えられるのはストレージです。

しかし、PromQL のサポートとは、新しいクエリ構文を受け付けるだけのことではありません。この言語には、メトリクスの公開とスクレイプから、エンコードと解釈に至るまで、Prometheus メトリクスのライフサイクル全体で下された設計上の判断が反映されています。ClickHouse が何を保持すべきかを理解するには、まず Prometheus のメトリクスに専用のクエリ言語が向いている理由を理解する必要があります。

PromQL プライベートプレビューのウェイトリストに登録できます。

Prometheus のメトリクスに専用のクエリ言語が向いている理由 #

PromQL は SQL の省略形ではありません。PromQL が存在する理由は、データの形と、Prometheus 自体の設計、そしてメトリクス仕様としての設計で下された判断にあります。それぞれの判断は、分散システムの監視に求められる規模と協調を扱えるように、10 年にわたって培われてきた設計の上に築かれています。

Prometheus は 2012 年に SoundCloud で始まりました。Google を離れたばかりのエンジニアたちが、社内で使っていたのと同じ特性、つまりディメンショナルなデータモデル、プル型の収集経路、そしてその両方を理解するクエリ言語を求めて開発したものです。Julius Volz は同じ年に PromQL の最初の形を書き上げました。これは、すでにスクレイプ、保存、グラフ描画ができるプロトタイプの一部でした。一般向けの発表は 2015 年 1 月でした。言語と型はそれ以来ずっと対をなしてきました。だからこそ、今日はじめて PromQL に触れる人は、10 年以上前に生まれたデータモデルに触れていることになります。

このモデルが広まったのには理由があります。2016 年 5 月、Cloud Native Computing Foundation は Kubernetes の直後に、Prometheus を 2 番目のホストプロジェクトとして受け入れました。Prometheus は、インスタンスが短命で、アイデンティティがホスト名ではなくラベルの集合である環境向けに作られていました。それはまさに、Kubernetes がその後あらゆる場所に生み出した環境です。プラットフォームチームの一世代が、この両方をまとめて受け継ぎました。だからこそ、多くの組織が、自ら意図して選んだわけではない PromQL のダッシュボードやアラートを運用しているのです。

Prometheus のメトリクスに専用のクエリ言語が向いている理由を理解するには、そのライフサイクルを理解する必要があります。Prometheus メトリクスのライフサイクルを順に見ていきましょう。

プル用の公開 #

Prometheus の設計では、アプリケーションは明示的にメトリクスを受信側へ送りません。HTTP エンドポイントに現在の状態を公開し、待つだけです。そのペイロードにはタイムスタンプも履歴もなく、誰かがいつか読み取るという保証もありません。

この 1 つの判断が、Prometheus のデータの収集、保存、クエリのあり方をほぼ決めています。計装されたサービスには、送信バッファも、バックエンドのアドレスも、監視システムが遅い、あるいは利用できない場合の対処も必要ありません。現在の状態を公開するだけです。収集、タイミング、保存、障害処理といった難しい仕事を下流に移すことで、アプリケーションの計装が簡単になります。

その代償として、アプリケーションは時間について何も知りません。そのため、時間に関するあらゆる問いには、別の何かが、別の場所で答えることになります。単純な収集方式の選択として始まったものが、システム全体の土台になるのです。

収集とスクレイプ #

コレクターが各エンドポイントを一定間隔でプルし、その瞬間にタイムラインが生まれます。アプリケーションが提供するのは値です。値は、単調に増加するカウンター、任意に増減するゲージ、バケットに分けた計測値であるヒストグラム、集約済みの計測値であるサマリーのいずれかです。Prometheus の 4 つの基本メトリクス型については、公式ドキュメントのこちらで詳しく確認できます。ただし、いずれにもタイムスタンプはありません。タイムスタンプは、スクレイプの時点でコレクターが付与します。

プル型には、ターゲットディスカバリー、スクレイプ自体が持つヘルスシグナル、そしてメトリクスシステムが劣化した際にアプリケーションを自然に守る設計という利点があります。その代償として、規則的なタイムラインは得られません。負荷がかかると間隔はずれ、スクレイプは失敗して欠落を残し、デプロイのたびにターゲットが現れたり消えたりします。同じリクエストパスを表す 2 つの系列が、同じ期間で異なる数のサンプルを持つこともあります。

保存時のエンコード #

スクレイプが運ぶのは現在の状態だけなので、残りの意味は型が担わなければなりません。Prometheus の型が、通常の数値カラムと並べると奇妙に見えるのはこのためです。

ゲージは単純なケースで、読み取った値そのままの意味を持ちます。カウンターは違います。カウンターは増えるだけで、2 回の読み取りの差分としてしか意味を持たず、プロセスが再起動するとゼロに戻ります。ヒストグラムはさらに複雑です。1 回のスクレイプでは分布を運べないため、ヒストグラムは le ラベル(「less than or equal to」の略)を共有する累積バケット系列の一群として公開され、それらの兄弟系列を再結合したときにはじめて分布が存在します。

型は契約です。その数値をどう解釈してよいかを定め、カラム定義では運べない情報を運びます。

観測用のクエリ #

クエリが実行される時点で、先の 3 つの判断がすでにその条件を決めています。

irate(http_requests_total[5m]) を例にとります。リセットは、数百万の減少ではなく再起動として読まなければなりません。サンプルがウィンドウの境界にちょうど乗ることはまれなので、結果は外挿で範囲の端まで延ばす必要があります。間隔はばらつくため、ウィンドウは固定のサンプル数を前提にできません。これらはいずれも、公開、スクレイプ、エンコードの各段階から直接導かれるものです。

histogram_quantile(0.95, ...) は、逆の方向から同じ負債を引き継ぎます。兄弟のバケット系列を le で再グループ化し、そのカウントを順に結合し、目標の順位を含むバケットの内部で補間します。

これが、Prometheus のメトリクスに専用の言語が向いている理由であり、PromQL が独立した言語として存在する理由です。 PromQL には、データがいつどう届くか予測できないことを前提としたデータモデルの知見が蓄積されており、キーボードの前にいる人がそれを意識せずとも、すべてのクエリにその知見が適用されます。

このプレビューの前には、ClickHouse で Prometheus のメトリクスを PromQL でクエリする標準的な方法がありませんでした。チームはクエリを SQL に書き直すか、独自の PromQL から SQL への変換レイヤーを構築して維持するしかありませんでした。

これらはすべて SQL で表現できますが、正しく変換するのは難しいことです。PromQL のあらゆる関数には境界条件があり、リセット処理のわずかな違いでも、もっともらしく見えて異なる結果を返すクエリが生まれます。移行の最中には、こうした不整合が、最悪のタイミングで信頼を損ないます。

PromQL を ClickHouse の内部で評価することで、その責任はサーバーが担うことになります。これにより、言語の正確なセマンティクスを保ち、ユーザーが Prometheus で慣れ親しんだのと同じ結果を返せます。この一貫性があるからこそ、チームはダッシュボード、アラート、クエリの意味を知らぬ間に変えてしまうことなく移行できると確信できます。ClickHouse がこれをいかに効率的に実現しているかは、それ自体が 1 つのテーマなので、別の記事で取り上げます。

私たちはパフォーマンスにこだわっており、それは SQL の枠を越えても変わりません。私たちの責任は、PromQL を SQL に変換することだけではなく、PromQL を高性能な SQL に変換することであり、その責任を喜んで引き受けます。

プライベートプレビューに含まれるもの #

Prometheus のデプロイメントには 4 つの役割があります。ターゲットをスクレイプするもの、サンプルを保存するもの、クエリに応答するもの、ルールを評価するものです。

このプレビューは、保存とクエリを引き受けます。

収集は変わりません。すでに運用している Prometheus サーバー、エージェント、OpenTelemetry Collector をそのまま使い、調整済みのスクレイプ設定もそのまま維持できます。ClickHouse は、それらが生成するデータを Prometheus のリモートライト v1 プロトコルで受け付けます。

サンプルは TimeSeries テーブルに格納されます。このテーブルは、メトリクスのメタデータ、ラベルの集合、タイムスタンプ付きの値を保存します。PromQL が登場するのは取得の段階です。Prometheus HTTP API を対象とする既存のツールはどれも、このサービスに向けてクエリできます。Prometheus サーバーは、このテーブルをリモートリードのバックエンドとして読めます。clickhouse-client は promql ダイアレクトで PromQL を直接評価します。SQL からは prometheusQuery と prometheusQueryRange テーブル関数で到達できます。この 4 つはすべてサーバー内の同じ PromQL 実装を実行するため、どこに送ってもクエリの意味は同じです。

そして最後に、Alerting Rules と Recording Rules を ClickHouse に持ち込むためのアラート評価ツールをお探しの方は、後日の発表をお待ちください。

メトリクスを取り込むにはどうすればよいですか? #

サポートチームが ClickHouse Cloud のサービスをアップグレードしたら、TimeSeries テーブルを作成します。カラムリストは省略可能で、デフォルトが手頃な出発点になります。

1CREATE DATABASE prometheus;
2CREATE TABLE prometheus.metrics ENGINE = TimeSeries;

Prometheus を運用している場合は、エンドポイントをリモートライトのターゲットとして追加します。

1remote_write:
2  - url: https://your-service.clickhouse.cloud:8443/prometheus/api/v1/write?database=prometheus&table=metrics
3    basic_auth:
4      username: default
5      password: <password>

OpenTelemetry Collector でメトリクスを収集している場合は、Prometheus リモートライトエクスポーターを使います。

1extensions:
2  basicauth/demo:
3    client_auth: { username: default, password: "<password>" }
4...
5exporters:
6  prometheusremotewrite:
7    endpoint: https://your-service.clickhouse.cloud:8443/prometheus/api/v1/write?database=prometheus&table=metrics
8    auth:
9      auth: { authenticator: basicauth/demo }

クエリするにはどうすればよいですか? #

Prometheus サーバーをクエリする方法は多数あり、それぞれに長所と短所があります。以下に、利用できるすべての方法を示します。

Grafana から #

Grafana の Prometheus データソースをサービスに向けます。URL は /api/v1 の手前で終わり、テーブルの選択はクエリパラメーターとして渡します。

1apiVersion: 1
2datasources:
3  - name: ClickHouse Prometheus
4    type: prometheus
5    access: proxy
6    url: https://your-service.clickhouse.cloud:8443/prometheus
7    basicAuth: true
8    basicAuthUser: default
9    jsonData:
10      httpMethod: GET
11      customQueryParameters: database=prometheus&table=metrics

Curl から #

1curl --user default:<password> --get \
2  "https://your-service.clickhouse.cloud:8443/prometheus/api/v1/query" \
3  --data-urlencode "query=rate(http_requests_total[5m])" \
4  --data-urlencode "database=prometheus" \
5  --data-urlencode "table=metrics"

clickhouse-client CLI から #

1clickhouse-client \
2  --dialect promql \
3  --promql_database prometheus \
4  --promql_table metrics \
5  --query 'rate(http_requests_total[5m])'

ClickHouse セッション内の SQL から #

1SELECT
2    tags['service'] AS service,
3    time_series
4FROM prometheusQueryRange(
5    prometheus.metrics,
6    'sum by (service) (rate(http_requests_total[5m]))',
7    now() - INTERVAL 1 HOUR,
8    now(),
9    INTERVAL 1 MINUTE
10);

ClickStack からの新たな発表 #

ClickStack は、同じプライベートプレビューの一部として、TimeSeries テーブルを PromQL データソースとして公開します。ソースを設定すれば、チャートエディターで PromQL を書くだけで、ClickStack がそのクエリを ClickHouse ベースの Prometheus 互換インターフェースに送ります。

プレビューでは、チャート、ダッシュボード、系列クエリ、スカラークエリに対応しています。ClickStack は外部の Prometheus 互換エンドポイントに PromQL をプロキシすることもできるため、ClickHouse の外に保存されたメトリクスも同じインターフェースで読めます。

プライベートプレビューは、チャートとダッシュボードによるメトリクスの探索に焦点を当てています。PromQL はチャートエディターに直接記述します。ビジュアルな PromQL クエリビルダーと、PromQL クエリに基づくアラートはまだサポートされていません。

ClickStack は PromQL クエリ内の変数にも対応しており、式にフィルター値を渡して、メトリクス、ログ、トレースをまたいだフィルタリングを連動させられます。この統合は現在も積極的に拡張を進めています。

TimeSeries テーブルへメトリクスを取り込むには、上で示した Prometheus リモートライトのパイプラインが必要です。ClickStack の標準的な OTLP パイプラインでは、これらのテーブルにデータは入りません。すでに OpenTelemetry Collector を使っている場合は、その Prometheus リモートライトエクスポーターを設定して、メトリクスをテーブルに送信してください。

注: ClickStack は、専用のソースタイプを通じて OpenTelemetry メトリクスにも対応しており、こちらは変更ありません。今後は、TimeSeries エンジン経由での OpenTelemetry メトリクスのサポートを検討しています。これにより、Prometheus と OpenTelemetry のメトリクスを単一のソースタイプに統合し、OTel メトリクスを PromQL でクエリできるようになります。

今後のサポート予定 #

ダイアレクトのカバレッジは 85% を超えており、動かせるダッシュボードが一度に最も多く増える順に 100% へ向けて進めています。お気に入りの関数や演算子がまだ対応していない場合、そのクエリをお知らせいただくことが、対応を実現する最善の方法です。サポート対象と非対象の一覧は、ドキュメントのこちらで確認できます。

ダウンサンプリングはよく話題に上がるテーマですが、テーブルに TTL を付けて機能完成と呼ぶのとは、複雑さの次元が異なります。私たちは、より粗い粒度でデータのコピーを保存するのではなく、時が来たら設定可能なコンパクションを行うダウンサンプリング機能をリリースしたいと考えています。

ネイティブヒストグラムは Prometheus エコシステムに新たに導入されたデータ構造であり、最初から正しく実装するには十分な注意が必要です。

RecordingRules と AlertingRules は Prometheus エコシステムの中核要素であり、これらのルールを移行するための私たちのソリューションを、後日のブログ記事で発表する予定です。

OpenMetrics とリモートライト v2 プロトコルは類似の技術で採用され始めており、サポートするプロトコルの一覧を拡充する予定です。あわせて、公式の OTEL ClickHouse Exporter による直接インサート方式にも対応する予定です。

詳細について #

PromQL インターフェースに関する資料は公式ドキュメントのこちらに、サポートしている PromQL の関数と演算子の一覧はこちらにあります。

TimeSeries テーブルエンジンの技術的な内部構造は後日のブログ記事で取り上げますが、先に知りたい方は、テーブルエンジンの公式ドキュメントをこちらで読めます。

ご質問、気になる点、フィードバックは、コミュニティ Slack の #promql チャンネルでお寄せください。

プライベートプレビューに参加するにはどうすればよいですか? #

このプレビューは、ユーザーがすでに期待している PromQL のセマンティクスを保ったまま、Prometheus のメトリクスを ClickHouse に持ち込み、保存とクエリを可能にします。

プライベートプレビューは本日から受付を開始しており、枠は限られています。こちらから登録し、次の点をお知らせください。

• メトリクス環境全体の規模とカーディナリティ。
• ダッシュボードとアラートに実際に含まれている PromQL。
• 現在運用しているメトリクスシステムから移行するには、何が必要か。

すでに ClickHouse のアカウントチームとやり取りがある場合は、そのチームにもプレビューについて伝えてください。機能の詳細は、PromQL ドキュメントをご覧ください。

皆さんのフィードバックが、次に何を作るかを形作ります。

それでは、よいモニタリングを!