ClickStackの新機能 - 2026年6月+7月

ClickStack の新機能、6月と7月の合併号へようこそ。2 回分のリリースを 1 つのアップデートにまとめたため、取り上げる内容は通常より少し多くなっています。

この 2 か月の作業の多くはトレースに集中しており、ユーザーからのフィードバックが直接のきっかけになっています。ウォーターフォールはサービスごとに別の色を使うようになりました。新しいミニマップは、トレースの一部を調べている間もトレース全体の形を表示し続けます。また、OpenTelemetry のスパンリンクがスパン詳細パネルに表示され、トレース間を容易に移動できます。

メトリクスでは、指数ヒストグラムの分位数対応を追加し、より軽量なデフォルトスキーマを導入し、外部の Prometheus 互換エンドポイントへの接続を可能にしました。これで ClickStack は、自身に保存したデータだけを見るツールではなくなります。TimeSeries Engine の評価や既存の Prometheus ワークロードの移行にも、新しい可能性が開けます。詳しくは後述します。

ダッシュボードのフィルターは、ファセット検索のように互いに絞り込めるようになりました。イベントパターンはダッシュボードのタイル種別として利用でき、キオスクモードはダッシュボードを壁面ディスプレイ向けの読み取り専用表示に固定できます。

フィルター値の取得方法も変更しました。オートコンプリートとフィルターのドロップダウンは、ソーステーブルをスキャンする代わりに、利用可能な場合は ClickHouse のテキストインデックスを使うようになりました。

新しいコントリビューター #

オープンソースのコントリビューターの皆さん、そしてフィードバックによってこれらの機能の多くを形作ってくれたユーザーの皆さんに感謝します。

Aryan Inguz, Marco Frömbgen, heyparth, kumburovicbranko682-boop, Rachit Mittal, Matt Kaye, zoov-xavier, tsushanth, Saksham Goyal, Prince Rawat, Shuvam Kumar, Minh Vu, Niladri Adhikary, xob0t

コントリビューションはコードを書くことだけではありません。ドキュメントの修正、アイデア、機能リクエスト、バグ報告、一般的なフィードバックはすべてリポジトリで歓迎します。小さな貢献も大切で、その一つひとつがより広いコミュニティのために ClickStack を改善します。

トレースウォーターフォールの改善 #

トレースビューは ClickStack ユーザーが最も長く使う画面です。Jaeger から移行するチームは、このワークフローを念入りに確かめる傾向があります。6月と7月はここに大きく投資し、ビューを再設計してスパンリンクに対応しました。

再設計されたトレースウォーターフォール #

先月は、スパンを調べている間もウォーターフォールが見えるように、スパンの詳細を分割ペインへ移しました。今月はウォーターフォールそのものに取り組みました。

各サービスには固定の色が割り当てられ、オペレーションとサービスのラベルの横に縦のバーとして表示されます。以前は、スパンバー内の文字の背景色として表示していました。緑は相関するログ行、赤はエラースパンの専用色のままなので、どちらもサービスの色と見分けがつかなくなることはありません。

スパンの所要時間はバーの外側に控えめな文字で表示されるようになりました。ホバーすると、カーソルの左右のうち余白の広い側にスパンの本文が表示されます。

ズーム時の非常に短いスパンの挙動も修正しました。従来、その最小幅はウォーターフォール領域に対する割合で定義されており、ズームに伴って広がっていました。このため、非常に短いスパンが数秒続くスパンと同じ幅に見えることがありました。最小幅は固定のピクセル幅になったため、どのズームレベルでもスパンの比率が保たれ、1 ピクセル未満のスパンも引き続きクリックできます。

深いトレースの移動も容易になりました。展開と折りたたみのコントロールは 1 階層のみ、またはトレース全体に対して操作できるようになり、折りたたむノードがあるときだけ表示されます。

長いトレースのためのミニマップ #

トレースビューの改善は大きなトレースの移動に役立ってきましたが、それでも 1 画面に収まらないことがあります。ある区間にズームインすると、その区間がトレース全体のどこに位置するのか分かりにくいことがありました。全体表示に戻るには、以前はスクロールで戻すか、表示を完全にリセットする必要がありました。

これに対応するため、ウォーターフォールの上にミニマップを置きました。ミニマップはトレース全体の範囲を時間軸として示し、スパンごとに 1 本のバーを表示します。枠付きの矩形が現在のビューポートを示し、それ以外の範囲は暗いオーバーレイで区別されます。ミニマップ上をなぞってズーム、ビューポートをドラッグしてパン、どちらかの端をドラッグしてサイズ変更ができます。

トレースビューアーのスパンリンク #

スパンリンクは、あるスパンを別のトレース内のスパンと結び付ける OpenTelemetry の仕組みです。プロデューサーがコンシューマーに仕事を渡す場合、バッチジョブが元のレコードを参照する場合、再試行されたリクエストが新しいトレースを開始する場合などを扱います。これらのスパンはトレース ID を共有していなくても因果関係があります。

ClickStack はこれまでもスパンリンクを標準の Links 列に取り込んでいましたが、表示はしていませんでした。そのためファンアウトやバッチのワークフローでは、関連するスパンが孤立して表示され、それを引き起こした処理とのつながりが見えませんでした。

スパン詳細パネルには、選択したスパンにリンクがあるときに Span Links セクションが表示されるようになりました。各リンクはコンパクトな行として表示され、トレース状態とリンク属性はチップで示されます。完全なトレース ID とスパン ID はホバーで確認できます。Open trace アクションを使うと、その場でリンク先のトレースへ移動します。

外部の Prometheus データストアへの接続(実験的機能) #

先月は、ClickHouse TimeSeries Engine を使った実験的なPromQL対応をリリースしました。これにより、ClickHouse に保存した Prometheus 形式のメトリクスを、多くのエンジニアがすでに知っている言語でクエリできます。しかし多くのチームでは、Prometheus や Prometheus 互換のシステムがすでに稼働しています。

こうしたシステムを、ClickStack の UI からメトリクスソースとして設定できるようになりました。PromQL クエリは設定したエンドポイントへプロキシされ、同じチャートエディターがどちらのバックエンドでも動作します。そのため、既存の Prometheus メトリクスを、元データを先に移動することなくログやトレースと並べてチャート化できます。

これで ClickStack は、自身に保存したデータ以外も扱えるようになります。ネイティブのメトリクス対応が成熟していく間も、チームは既存の Prometheus デプロイメントを使って ClickStack を評価し、完全な移行に踏み切らずにダッシュボードを移せます。

ハイブリッドな進め方も可能です。カーディナリティの高いワークロードを Prometheus から ClickHouse TimeSeries Engine へ移すチームは、段階的に移行し、既存のダッシュボードを使い続け、両システムの結果を比較できます。移行を完了する前に、両バックエンドが同等の結果を返すことを確認しやすくなります。

完全な移行が全員の目標というわけではありません。Prometheus 互換のデプロイメントに満足しているチームはそれをそのまま残し、ClickStack でそのメトリクスをログやトレースと相関付けられます。

Prometheus 接続はまだ非常に実験的な段階で、デフォルトでは無効です。環境変数 NEXT_PUBLIC_ENABLE_PROMQL=true を設定すると、ソースフォームに PromQL のソース種別が現れます。リリース間で機能の範囲が変わることが見込まれるため、まず非本番環境で有効にしてください。

フィルター値とオートコンプリートの高速化 #

オートコンプリートとフィルターのドロップダウンは、コストの高い問いに答える必要があります。この列にはどんな値が含まれているのか、という問いです。

大量データのソースでは、テーブルをスキャンすると、一瞬で開くはずのドロップダウンで長く待たされることになりかねません。ClickStack は以前からこのコストを減らすためにメタデータのマテリアライズドビューを使ってきましたが、何をクエリするかを選ぶロジックは、重なり合う複数の経路に膨らんでいました。

フィルター値の取得方式を選ぶロジックを作り直し、利用できる選択肢をコストの低い順に試すようにしました。

最初の選択肢は ClickHouse のテキストインデックスで、mergeTreeTextIndex() テーブル関数を通して読み取ります。これは、元のデータパートを読まずに、インデックスにすでに格納されている語を列挙します。マップに対するテキストインデックスでも、TraceId のようなネイティブ列でも動作します。

適切なテキストインデックスがない場合、ルーターはメタデータのロールアップ用マテリアライズドビューにフォールバックします。ソーステーブルを直接クエリするのは、どちらも利用できないときだけです。

オートコンプリートも同じ経路を使うようになり、候補の提示とフィルター値の取得が実装を共有します。

mergeTreeTextIndex() の経路には ClickHouse 26.3 以降が必要です。それより前のバージョンではルーターがこの経路をスキップしてメタデータのロールアップを使うため、フィルターはどちらの場合でも動作します。

連動するダッシュボードフィルター #

ダッシュボードのフィルター機能はこの数か月で大きく改善してきました。フィルターに表示する値を制限する機能から始まり、5月にはソースを限定したフィルターに対応しました。しかしこれまでは、すでに適用されているフィルターに関係なく、各ドロップダウンがその列のすべての値を列挙していました。Kubernetes ダッシュボードでクラスターを選んでも、ネームスペースのドロップダウンには他のクラスターのネームスペースが並んだままで、その大半は選んでも結果が返らないものでした。

ダッシュボードのフィルターバーと Kubernetes ビューに「Link filters」トグルが追加されました。有効にすると、各ドロップダウンには現在の選択と組み合わせて実際に存在する値だけが並びます。たとえばクラスターを選ぶと、ネームスペースの一覧はそのクラスターに存在するものへ絞り込まれます。Kubernetes フィルターバーのフリーテキスト検索も、同じ絞り込みに効きます。

リンクはクエリコストがかかるため、デフォルトでは無効です。絞り込まれた値は現在の選択に依存するため、通常のドロップダウンが使う安価なキー単位のロールアップからは得られません。この検索はソースが大きくなるにつれてかなり高コストになります。

このコストを抑えるため、絞り込まれた値はドロップダウンを開いたときにだけ取得します。1 つのダッシュボードが発生させる追加の検索回数に上限がかかります。

連続ウィンドウによるアラート #

評価ウィンドウ 1 回分のノイズは、アラートが午前 3 時に誰かを呼び出すよくある原因です。しかもその問題は一時的なもので、すでに収まっています。短いレイテンシのスパイク、リトライの集中、エラー率を一時的に上げるデプロイは、しきい値を超えてアラートを発報し、誰かが通知を読み終える前に回復してしまいます。

アラートは、条件が連続する複数のウィンドウで成立するまで発報を待てるようになりました。1 分間のウィンドウ 3 回連続を要求するアラートなら、しきい値を 3 回続けて超えたときにだけ通知を送ります。これにより、しきい値を上げて継続的な問題への感度を下げることなく、短時間のスパイクを除外できます。

必要なウィンドウ数を積み上げている間、アラートは新しい PENDING 状態を報告します。まもなく発報するかもしれないアラートと、条件が成立していないアラートを区別できます。

numConsecutiveWindows 設定はアラートエディターと外部 API の両方で利用できるため、コードとして管理しているアラートでも使えます。

指数ヒストグラムメトリクス #

指数ヒストグラムは、OpenTelemetry にある 2 種類のヒストグラムのうちコンパクトな方です。固定のバケット境界を事前に定義する代わりに、各バケットをスケール係数とインデックスで表現します。これにより、有用なレイテンシの境界がどこになるかを計装の作者が予測しなくても、1 つのメトリクスで広い値の範囲を高い解像度でカバーできます。

指数ヒストグラムへの対応は、メトリクス対応への要望の中でも特に多かったものです。

クエリビルダーは、指数ヒストグラムメトリクスに対する分位数と合計の集計に対応しました。これらのメトリクスは、メトリクス名セレクターにも他のメトリクス種別と並んで表示されます。

分位数の計算は、固定バケットのヒストグラムより手順が多くなります。スケールはシリーズ間でも、同じシリーズ内のデータポイント間でも異なりえます。集計を始める前に、ClickStack はカウントを存在する中で最小のスケールに正規化します。この正規化は、オフセットの整合を保ちながら細かいバケットを粗いバケットへまとめます。

オフセットもデータポイント間で移動することがあります。累積カウントを差分に変換するため、ClickStack は各バケットインデックスを同じシリーズの直前のデータポイントに揃えたうえでカウントを減算します。

揃えた後は、各時間バケット内でシリーズをまたいでバケットを合計します。ClickStack は累積カウントから要求された分位数を含むバケットを見つけ、そのバケット内で対数線形補間を使って値を推定します。これは Prometheus の挙動と一致します。

カテゴリ別の棒グラフ #

ClickStack は長らく棒グラフに対応してきましたが、時間軸に沿ってバケットごとに 1 本のバーを置く時系列としてだけでした。「今日最も多くエラーを出したエンドポイント上位 10 件はどれか」のような問いに答えるには円グラフを使う必要があり、比較する値が多いと読みにくくなっていました。

カテゴリ別の棒グラフは、Chart Explorer、ダッシュボード、MCP サーバー、外部ダッシュボード API で独自の表示タイプになりました。各バーは時間バケットではなくグループを表すため、順位付けした比較がはるかに読みやすくなります。

新しい棒グラフと既存の円グラフは、時系列チャートですでに利用できるシリーズ数の上限にも対応します。ただしカテゴリ別チャートでは実装が異なります。上限はクエリ内の ORDER BY と LIMIT になりますが、時系列チャートではすべての時間バケットにわたる上位シリーズを計算するために CTE が必要です。

並び順も設定できます。カテゴリ別チャートは以前は値の降順に固定されていました。任意の SQL 式で並び替えを指定できるようになり、デフォルトは引き続き値の降順です。

ダッシュボードタイルとしてのイベントパターン #

イベントパターンは、似たメッセージを少数の代表的なパターンにまとめます。多くの場合、これがサービスの出力内容を把握する最も手早い方法です。

以前、パターンは Search ページに限られていました。調査中には使えても、その結果をダッシュボードに保存して、パターンが説明の手がかりになったチャートの横に置くことはできませんでした。

イベントパターンはダッシュボードのタイル種別として利用できるようになりました。タイルエディターには専用のセクションがあり、分析対象の列の式(デフォルトはログでは Body、トレースソースでは SpanName)と、Lucene または SQL で書く任意のフィルターを指定できます。フィルターは、パターン抽出をデータの一部に限定するのに便利です。

対応範囲は UI、MCP サーバー、外部 API に及ぶため、エージェントも displayType: "event_patterns" を使ってパターンのタイルを作成できます。

読み取り専用のキオスクモード #

多くのチームがオフィスの画面にダッシュボードを表示しています。これまでは、編集可能なダッシュボードを開いたままにして、誰もマウスを持って通りかからないことを願うしかありませんでした。誰も操作しないはずのディスプレイで、編集用のインターフェースが場所を取ってもいました。

ダッシュボードにキオスクモードが追加され、オーバーフローメニューから利用できます。インターフェースはダッシュボード名、ライブの読み取り専用インジケーター、タイルそのものだけに絞られます。編集用のコントロールはすべて無効になります。自動更新は常に有効で、トレースと検索のタイルもライブで更新され続けます。

キオスクモードは URL に kiosk=true として保存されます。壁面ディスプレイはその URL を直接開けるため、再起動後も誰かが設定し直すことなくキオスクモードに戻れます。

External API による保存済み検索と Webhook #

ClickStack のリソースをクリック操作で組み立てるのではなくコードとして管理できるように、External API v2 を着実に拡充してきました。アラートとダッシュボードにはすでに完全な CRUD がありました。保存済み検索は /api/v2/search がクエリを実行するだけで CRUD がまったくなく、Webhook は読み取り専用でした。

どちらも一通り揃いました。新しい /api/v2/saved-searches ルーターは list、get、create、update、delete に対応し、/api/v2/webhooks には既存の list エンドポイントに加えて POST、PUT、DELETE が追加されました。

いずれもチーム単位のスコープを持ち、保存済み検索のリクエストはソースを埋め込みのソースオブジェクトではなく sourceId で参照します。保存済み検索のピン留めフィルターは書き込み時に検証されます。保存されたあと黙って無視されるのではなく、実際にサイドバーのファセットとして描画されるかをその時点で確かめます。

この作業と併せて、アラート、保存済み検索、Webhook の v2 の list エンドポイントはページネーションに対応し、limit と offset を受け取り、総数を含む meta ブロックを返すようになりました。一覧に上限がないことを前提にしていたクライアントがある場合は、総数を読み取ってページをたどる必要があります。

より軽量で高速なメトリクススキーマ #

メトリクステーブルには特徴的な形があります。シリーズの数は比較的少なく、各シリーズには多数のデータポイントが時系列で記録されます。シリーズは属性で識別されます。

元のデフォルトスキーマは、属性のマップそのものをソートキーにしていました:

ORDER BY (ServiceName, MetricName, Attributes, toUnixTimestamp64Nano(TimeUnix))

マップをソートキーに直接入れるのは高コストです。主キーインデックスはそのマップの値をメモリに保持する必要があり、リソース属性とメトリクス属性を含むマップは大きくなりえます。

新しいデフォルトスキーマは次を使います:

ORDER BY (ServiceName, MetricName, toStartOfHour(TimeUnix), cityHash64(Attributes), TimeUnix)

属性をハッシュ化することで、マップ全体をソートキーに格納する代わりに、各シリーズにコンパクトで固定幅の識別子を与え、インデックスのメモリ使用量を減らします。

1 時間単位のバケットを属性ハッシュの前に置くことで、時間で絞り込むクエリは属性を調べる前にグラニュール全体をスキップできます。TimeUnix に対する min-max インデックスは、データを刈り込むもう 1 つの安価な手段になります。

これらの変更を合わせると、メトリクスクエリが読むデータ量とインデックスが使うメモリ量が減ります。

これはコレクターが作成するデフォルトスキーマの変更であり、新しく作成されるメトリクステーブルに適用されます。主キーはその場で変更できないため、既存のデプロイメントは現在のソートキーを維持します。新しい主キーへの移行方法は現在のガイドを参照してください。

OpenTelemetry Collector 向けの Datadog レシーバー #

ClickStack が配布する OpenTelemetry Collector に、オプトインの Datadog レシーバーが含まれるようになりました。既存の Datadog Agent から、計装をすぐに変更することなくトレース、メトリクス、ログを ClickStack へ送信できます。

ENABLE_DATADOG_RECEIVER を設定すると、OpAMP コントローラーが contrib の datadogreceiver を 0.0.0.0:8126 でトレース、メトリクス、ログの各パイプラインに追加します。コレクター認証が有効な場合、レシーバーは DD-API-KEY ヘッダーをチームの API キーと照合します。

これにより、既存のワークロードを使った ClickStack の評価がはるかに容易になります。段階的な移行経路にもなります。チームはすぐに ClickStack へデータを送り始め、その後すべてを一度に変えるのではなく、時間をかけて計装を OpenTelemetry の SDK と Collector へ移せます。

両システムを並行して動かすという選択肢もあります。たとえば、全シグナルの計装を置き換えなくても、ログやトレースは ClickStack へ移し、メトリクスは Datadog に残せます。運用面やコスト面で利点が見合うワークロードを、個別に移せます。

レシーバーが変換するものと変換しないものを含む移行経路については、専用のブログで解説しています。

MCP サーバーの改善 #

Open House でClickStack MCPサーバーを発表して以来、エージェントができることを広げ続けてきました。私たちの評価フレームワークで見ると、エージェントは生の SQL から調査ワークフローを組み立て直すよう求められるより、オブザーバビリティのプリミティブを与えられた方が目立って良い成績を出します。今月は、特に際立つ改善が 2 点あります。

第一級のソースとしてのメトリクス #

MCP サーバーに、OpenTelemetry メトリクスを発見してクエリするための一貫したワークフローが揃いました。

メトリクスの発見は、新たに追加した 2 種類のツールが担います。clickstack_list_metrics は、メトリクスの種類、名前のパターン、時間範囲でフィルターできる、ページネーション付きのメトリクス名カタログを返します。clickstack_describe_metric は、選択したメトリクスの単位、説明、属性キー、サンプル値を返します。

clickstack_describe_source もメトリクスを認識します。メトリクスの種類に応じて代表的なテーブルを選び、他のソース種別と同じ手順で列を調べ、値をサンプリングします。

clickstack_timeseries と clickstack_table のツールは metricType と metricName を受け付けるようになり、メトリクスをクエリできます。

ソースと Webhook の管理 #

複数のユーザーから、データが流れ始めた後の調査だけでなく、ClickStack の初期セットアップにもエージェントを使いたいという要望がありました。以前は、エージェントが関わる前にソースと Webhook が設定済みであることが前提でした。

MCP サーバーはソースと Webhook を作成、更新、削除できるようになりました。エージェントは初期化の段階から始めて、ソースを作成し、シッパーを ClickStack へ向けてデータの取り込みを開始できます。そこから同じデータに対して検索、ダッシュボード、アラートを構築できます。

このワークフローを支えるツールは clickstack_save_source、clickstack_delete_source、clickstack_save_webhook、clickstack_delete_webhook です。

小さいけれど便利な改善 #

チャートツールチップのピン留め #

時系列チャートにホバーするとシリーズごとの値と前期間からの変化が表示されます。クリックするとツールチップがピン留めされ、View All Events に加えて、各シリーズに対する Drill in、Copy name、Focus のアクションが追加されます。

ビルダーのチャートを生の SQL へ変換 #

チャートをクエリビルダーから SQL エディターへ切り替えると、以前は空のエディターが渡され、ソースもリセットされていました。切り替え時に現在のビルダー設定が SQL へ変換され、選択したソースも維持されるようになったため、ビジュアルエディターは捨てるものではなく、手書きクエリの出発点になります。

テーブルのスタイル設定 #

テーブルの可視化に列ごとの色が加わりました。列に固定色を付けるか、順序付きの条件ルールを設定できます。たとえば所要時間の列で 500ms を超える値のセルを赤くする、といった指定です。また、区切り線を常時表示し、テーブルの固定ヘッダーをその下をスクロールする行と区別するようにしました。

タイルチャートへのアラート注釈 #

アラートを調査するときは、監視対象のチャート上で、いつ発報していつ回復したかを確かめる必要があります。ダッシュボードメニューから Show alert annotations を有効にすると、関連する各タイルに、アラートの発報時に赤、回復時に緑のマーカーが追加されます。

Browser RUM ダッシュボードの強化 #

先月リリースしたBrowser RUMダッシュボードは、タイルを値で色分けするようになりました。Core Web Vitals は Google の good、needs-improvement、poor のしきい値で色分けします。ページ読み込みはレイテンシの帯域で、エラーのタイルはエラーが 1 件でもあればアンバー色です。各しきい値は凡例で説明します。単一値のタイルには、文脈を示す薄い背景スパークラインも含まれます。新しい Sessions セクションは、最近のセッションを rum.sessionId ごとに一覧します。ページビュー、エラー、個別トレース数、ユーザー、サービス、最終アクティブ時刻を含み、各行はそのセッションで絞り込んだトレースへリンクします。Memory セクションは、documentLoad スパンの performance.memory.* 属性からページごとの JavaScript ヒープのタイルを追加します。

テーブルタイルからの外部リンク #

5月にリリースしたダッシュボードアクションが拡張され、テーブルタイルのクリック時の動作で外部リンクを開けるようになりました。たとえば、失敗したデプロイの一覧テーブルから各行を該当する CI ビルドへリンクしたり、サービス別の内訳からランブックへリンクしたりできます。

タイル移動中のスナップグリッド #

ダッシュボードタイルをドラッグまたはサイズ変更すると、タイルの背後にグリッドが描かれ、タイルが実際に配置されるセルが強調表示されるようになりました。

メトリクスによるサービスマップの色分け #

先月のサービスマップの改善に続き、レイテンシ、エラー率、スループットのいずれかでグラフを色分けするメトリクスモードが追加されました。色のスケールと、ノードのサイズがスループットをどう表すかを説明する凡例も付きます。