---
title: "ClickStackの新機能 - 2026年9月・10月"
date: "2026-11-04T01:09:49.109Z"
author: "The ClickStack Team"
category: "Product"
excerpt: "9月と10月のClickStackリリースでは、アドホックなダッシュボードフィルター、全チャートタイプでのPromQL対応、ClickStackクエリトレース、Trace logsタブ、チャートエクスプローラーからのアラート作成に加え、検索ページとコレクターに関する多数の改善が導入されました。"
---
# ClickStackの新機能 - 2026年9月・10月
ClickStack ではこの2か月間、4回のマイナーリリースや、近々お届けする予定のエキサイティングなお知らせの準備などで慌ただしく過ごしていました。「新機能」記事の更新が少し遅れてしまったため、今回は9月と10月をまとめ、v2.39 から v2.42 までの内容をお届けします。
ダッシュボードには、インタラクティブ性を高めるアドホックフィルター、単一選択および必須のフィルター、保存可能な相対時間範囲、マークダウンタイル内での変数の利用機能が追加されました。8月にプレビュー版として導入された PromQL は、エディター内のすべてのチャートタイプ(数値タイル、テーブル、円グラフ、ヒートマップなど)に対応しました。また、PromQL タイルは Prometheus ダッシュボードをコードとして管理するための外部 API 経由でもサポートされ、ヒートマップにはシリーズモードが追加されました。
すべての ClickStack クエリに発行元(origin)が含まれるようになり、共有の ClickHouse クラスターでの読み取り負荷を追跡しやすくなりました。さらに、Trace ログタブの追加、最新の OpenTelemetry 規約に合わせたスパンパネルの調整、コミュニティの協力を得た検索ページの改善も行いました。その他の追加機能として、チャートエクスプローラーからのアラート作成、エージェント型調査を高速化する MCP サービスヘルスツール、コレクターにおける StatsD およびスパンメトリクスのサポートなどがあります。
2か月も待てないという方は、毎週公開している [Demo Day の動画](https://clickhouse.com/docs/ja/clickstack/demo-days)で最新情報を追うのがおすすめです。開発チームが取り組んでいる内容を披露しているため、このニュースレターに掲載される前に何が形になりつつあるのかを確認できます。動画は [Slack](https://clickhouse.com/slack) の `#o11y-clickstack` チャンネルでも共有しています。
> 私たちは[来週ソルトレイクシティで開催される KubeCon](https://clickhouse.com/campaigns/kubecon-north-america-2026) に参加します。ブース #108 にぜひお立ち寄りください。また、[11月9日の ClickStack トレーニング](https://clickhouse.com/company/events/202611slckubecon)で実際に体験してみることもできます。ドリンクを片手に交流したい方は、[11月10日の Gracie's での集まり](https://luma.com/vgcotljq)や、[11月11日の Keys on Main での AprèsKube](https://luma.com/apreskube-slc) への参加をご申請ください(登録は承認制となります)。
## 新しいコントリビューター {#new_contributors}
オープンソースのコントリビューターの皆様、そしてこれらの機能の多くを形作るフィードバックをくださったユーザーの皆様に感謝いたします。
[Harshul1484](https://github.com/Harshul1484), [DevShoaib78](https://github.com/DevShoaib78), [breken-ai](https://github.com/breken-ai), [krishs01](https://github.com/krishs01), [BilalAtique](https://github.com/BilalAtique), [28Hus](https://github.com/28Hus), [squaredg](https://github.com/squaredg), [archat-hash](https://github.com/archat-hash), [octo47](https://github.com/octo47), [wanjinhao1](https://github.com/wanjinhao1), [felipe-carvalho12](https://github.com/felipe-carvalho12), [adityareddy-dev](https://github.com/adityareddy-dev), [bahltushar](https://github.com/bahltushar), [andrewdunndev](https://github.com/andrewdunndev), [poblahblahblah](https://github.com/poblahblahblah), [marcleblanc2](https://github.com/marcleblanc2)
コントリビューションはコードを書くことだけに限りません。[リポジトリ](https://github.com/hyperdxio/hyperdx/tree/v2)を通じたドキュメントの修正、アイデア、機能リクエスト、バグ報告、全般的なフィードバックなど、すべて大歓迎です。小さな貢献も大切であり、その一つひとつがより広いコミュニティのために ClickStack を向上させています。
## ダッシュボードのアドホックフィルター {#ad_hoc_dashboard_filters}
これまでのダッシュボードフィルターは、ユーザーがあらかじめ定義しておく必要がありました。ダッシュボードを作成した人がカラムを選択し、それ以外の人はそのドロップダウンを利用する形でした。しかし、調査を進める中で、ダッシュボードの作成者が想定していなかったホストやステータスコード、顧客 ID でフィルタリングしたくなることがあります。その場合、個々のタイルを編集するか、別のダッシュボードフィルターを追加しなければなりませんでした。
新しい **Ad hoc keys and values** フィルタータイプを使用すると、調査しながらフィルターを適用するフィールドを選択できます。ログ、トレース、メトリクスのソースにおけるカラムや map キー、および PromQL ソースのラベル名に対応しています。
フィルターバーからキー、演算子、値を選択するだけで、キーと値の両方にサジェストが表示されます。設定した条件は、それらのソースを使用するすべてのタイルに適用されます。
これらのフィルターにより、ダッシュボードのインタラクティブ性もさらに向上し、可視化画面から直接条件を追加できるようになります。検索タイルのセル、テーブルタイルの group-by セル、またはタイムチャートのツールチップ内の系列をクリックすると、その値でフィルターが適用されます。生の SQL タイルでは、ClickStack はクエリの `GROUP BY` 句を使用して、クリックによるフィルターで利用可能なカラムを特定します。クエリをパースできない場合は、代わりに文字列カラムを候補として提示します。特定のサービスでエラーが増加している場合は、タイルを一切編集することなく、そのサービスに絞り込み、さらにリージョンで詳細に絞り込むことができます。SQL と PromQL のプレビューには、各クエリに適用された条件が表示されます。
条件には、完全一致、否定、正規表現による一致、そして SQL ソース向けの `LIKE` を指定できます。選択内容はダッシュボードの URL に保存されるため、フィルターを適用したビューの共有や、既存のフィルターと並べてダッシュボードのデフォルトとして保存することが可能です。ダッシュボードをインポートすると、タイルと同様に、アドホックフィルターも手元のソースへと再マッピングされます。
> アドホックフィルターは現在、実験的機能です。フィードバック収集中につき、環境変数 `NEXT_PUBLIC_ENABLE_ADHOC_FILTERS=true` で有効化してお使いください。
## すべてのチャートタイプで PromQL が利用可能に {#promql_for_every_chart_type}
8月に [PromQL のサポートを発表](https://clickhouse.com/ja/blog/introducing-promql-jp) した時点では、時系列チャートで使える PromQL 式は 1 つだけでした。その後、Prometheus ダッシュボードを ClickStack に移行するチームが必要とするチャートタイプやクエリオプションをより多くサポートできるよう、チャートエディターを拡張しました。
時系列チャートで複数の PromQL 式をサポートし、それぞれにエイリアスを設定できるようになりました。例えば、p50、p95、p99 のレイテンシをまとめてプロットできます。エディターの下にあるクエリプレビューには、ダッシュボード変数が置換された各式が表示されます。
数値タイルは、Grafana の stat パネルを使ったことがある方なら直感的に操作できます。対象期間の末尾で式を 1 回だけ評価するインスタントクエリ (Instant query) か、Last、Min、Max、Avg、Sum、Count を使用して結果を単一の値に集約するレンジクエリ (Range query) を選択します。レンジクエリでは、数値の背後にスパークラインを表示することも可能です。式が依然として複数の値を返す場合は、タイル上に警告が表示されます。
PromQL はテーブル、円グラフ、棒グラフでも機能します。テーブルでは返された各サンプルが行として表示され、各ラベルのカラムが用意されます。円グラフと棒グラフでは、数値タイルと同じインスタントクエリおよびレンジクエリのオプションに加えて、凡例テンプレートもサポートしています。
式内では、Grafana 互換の 3 つのマクロを使用できます。チャートの粒度を表す `$__interval`、選択した期間の長さを表す `$__range`、複数のスクレイプ間隔をカバーするウィンドウを表す `$__rate_interval` です。3 つすべてがオートコンプリートの候補に表示され、ダッシュボード変数と同様にクエリプレビュー内で置換されます。
数百件のシリーズを返すクエリでは、表示設定の「Series Limit」を活用することでチャートの可読性を維持できます。折れ線グラフと積み上げ棒グラフではピーク値が大きい上位のシリーズが保持され、円グラフと棒グラフでは最も大きなスライスやバーが残ります。
> PromQL サポートは引き続き実験的機能です。API 側で `ENABLE_PROMQL=true`、アプリ側で `NEXT_PUBLIC_ENABLE_PROMQL=true` を設定して有効化してください。
## ダッシュボードフィルターの単一選択と必須設定 {#singleselect_and_required_dashboard_filters}
ユーザーからのフィードバックに基づき、8月に導入されたダッシュボード変数にも改善を加えました。
フィルターを**単一選択 (single-select)** として設定できるようになり、新しい値を選ぶと現在の選択内容が置き換わるようになりました。これは、複数選択の変数が正規表現の選択候補 (`|`) に展開され、`=~` マッチャーが必要となる PromQL で特に役立ちます。
単一選択変数は、`instance="$instance"` のような単純な等価比較で使用できます。PromQL 式でデフォルトで使用される新しい PromQL 変数フォーマットは、単一選択と複数選択のどちらの値でもエスケープ処理を適切に行います。
フィルターを必須 (Required) として設定することも可能になりました。以前はダッシュボードを開くと、フィルターを選択する前にすべてのタイルが実行されていたため、関心のない大量のデータに対してクエリが実行される可能性がありました。
必須フィルターを使用するタイルは、値を選択するまで待機するようになりました。この必須要件をダッシュボード上のすべてのタイルに適用することも可能です。タイルの編集中は、プレビューに現在のダッシュボードフィルターの選択内容が適用され、**Apply filters** トグルを使ってフィルター適用前後の結果を比較できます。
ダッシュボードで相対時間範囲も記憶されるようになりました。「過去 6 時間」を選択した状態でダッシュボードを保存すると、保存時の固定された日付ではなく、毎回直近の 6 時間が表示された状態で開きます。
また、Markdown タイルでダッシュボード変数がサポートされ、リンク内でも利用できるようになりました。閲覧中のサービスや環境を表示したり、現在の選択内容をリンク経由で別のページに渡したりする用途に活用できます。値はデフォルトで Markdown 用にエスケープされますが、別の表現が必要な場合は `${var:csv}` などのフォーマットも利用可能です。
## PromQL をサポートした柔軟なヒートマップ {#flexible_heatmaps_with_promql_support}
ClickStack のヒートマップはこれまで、y 軸にスパン期間などのバケット化された値を配置し、色の濃淡で各バケットのイベント数を示す数値分布を表示していました。これはレイテンシの把握には適していますが、より幅広い挙動の調査にこのビジュアルを活用することはできませんでした。
新しい **Series** モードでは、x 軸に時間バケットを維持したまま、group-by の値ごとに行が割り当てられ、選択した集計値が色で表現されます。線の高さの代わりに色で値を示すため、マルチシリーズの折れ線グラフに近い感覚で使用できます。
PromQL ソースの場合、ヒートマップは 3 つのモードをサポートします。**Series** は前述のとおり範囲クエリを使用して動作し、マクロ、変数、凡例テンプレートをサポートします。**Histogram** は、Prometheus によってすでにバケット化されているメトリクスに対応します。バケットの境界は `le` ラベルから取得され、`sum by (le) (...)` を使用してこれらの境界を共有するシリーズを結合できます。
**Distribution** は、線形または対数間隔を使用して、各タイムスタンプにおける全シリーズのサンプル値をバケットにグループ化します。これは、コアごとの CPU 使用率など、まだヒストグラムになっていないデータに役立ちます。
group-by の結果が 50 シリーズを超える場合、ヒートマップには上位 50 件が表示され、警告が示されます。ランキングにはタイムチャートと同じ基準が使用されます。
## PromQL が API のファーストクラスに対応 {#promql_becomes_a_firstclass_api_citizen}
外部ダッシュボード API が PromQL タイルに対応しました。`GET /api/v2/dashboards` のレスポンスに PromQL タイルが含まれるようになり、`POST` および `PUT` では `configType: "promql"`、`sourceId`、および式のリストを使用して受け付けます。従来はレスポンスから PromQL タイルが除外されていたため、API 経由でダッシュボードを保存し直す際に失われる可能性がありました。
他のダッシュボードと同様に、PromQL タイルを含むダッシュボードを [API](https://clickhouse.com/docs/ja/clickstack/api-reference) や Terraform 経由で管理できるようになりました。
また、オンボーディング時の PromQL ソース検出機能も追加しました。PromQL が有効になっている場合、ClickStack は OpenTelemetry テーブルから検出されたログ、トレース、メトリクスソースに加えて、接続上で検出された ClickHouse TimeSeries テーブル用のソースを自動的に作成します。
内部的には、PromQL クエリはサーバーが対応している環境で ClickHouse の Prometheus HTTP API を使用するようになりました。TimeSeries エンジンがプレビュー段階の間、ClickHouse はこのインターフェースの前方互換性を維持します。PromQL タイルおよび /api/v1/prometheus/* ルートは、connectionId の代わりに sourceId を使用するようになり、ソース経由で接続を解決します。
> 同梱の ClickHouse イメージは 26.8 に移行します。自前の ClickHouse サーバーに対して PromQL を実行する場合は、26.8 以降を推奨します。
## ClickStack クエリトレーシング {#clickstack_query_tracing}
多くの ClickStack デプロイメントでは、ClickHouse クラスターを他のワークロードと共有しています。これまでは、`system.query_log` 内の重いクエリを見ても ClickStack から発行されたことしか分からず、読み取り負荷を特定のダッシュボードやアラートまで追跡するには SQL テキストを手作業で突き合わせる必要がありました。
この問題に対処するため、ClickStack が実行するすべてのクエリに、発行元のサーフェス名とそれを特定する ID(ダッシュボードとタイル、保存された検索、アラート、MCP ツール、チャートエクスプローラーなど)を含む小さな JSON 形式の `log_comment` が付与されるようになりました。`query_id` は `hdx-` とサーフェス名で始まるため、JSON をパースすることなく、クエリの実行中であっても `system.processes` 内で識別できます。
> このコメントにはリクエストされた内容のみが記録され、リクエストした人物は記録されないため、ユーザーやチームの識別子が書き込まれることはありません。
以下のクエリを使用すると、ClickStack サービスの負荷がどこから発生しているかを素早く特定できます。
```sql
SELECT
JSONExtractString(log_comment, 'surface') AS surface,
JSONExtractString(log_comment, 'dashboard') AS dashboard,
count() AS queries,
formatReadableSize(sum(read_bytes)) AS read
FROM system.query_log
WHERE (type = 'QueryFinish') AND startsWith(query_id, 'hdx-')
GROUP BY
surface,
dashboard
ORDER BY sum(read_bytes) DESC
```
ClickStack 自体でこれを実行して、内部で何が起きているかを確認することもできます。オブザーバビリティのための、ちょっとしたオブザーバビリティです。
PromQL クエリにも、ClickHouse の Prometheus API 経由で実行されたかテーブル関数経由で実行されたかにかかわらず、同様の帰属情報が含まれます。そのため、他のダッシュボードと並べて負荷を追跡できます。コスト追跡にとどまらず、これによって低速なクエリの発生元となったタイルまで遡って特定できるようになります。また、現在検討中のクエリ推奨機能に向けた基礎づくりにもなっています。
## トレース表示の改善 {#trace_viewing_improvements}
サイドパネルでのトレース確認について、3 つの改善を行いました。3 つとも、すでに収集済みのトレースに対してそのまま機能します。
### 「Trace logs」タブ
これまでは、トレースログを探すにはウォーターフォール内のスパンを調べる必要があり、ログの数が多いトレースでは画面が煩雑になりがちでした。イベントのサイドパネルに **Trace logs** タブが追加され、検索ページと同じページネーション、ソート、展開可能な JSON を備えた時系列のフラットなテーブルでログを表示できるようになりました。
このタブは、トレース ID と関連するログソースを持つすべてのスパンまたはログに表示されます。ログを選択してパネル内で検査するか、**Open in search** を使用して同じソース、トレース、時間枠を維持したまま検索ページでフィルタリングを続行できます。また、ウォーターフォールのコントロールバーにトレースの合計所要時間とスパン数を追加したため、タイムラインから計算しなくても両方を確認できるようになりました。
### 記録場所を問わない例外表示
OpenTelemetry SDK は、スパンイベントだけでなく `exception.*` 属性を持つログとしても例外を記録できます。今回の更新により、`exception.type`、`exception.message`、または `exception.stacktrace` を含むすべてのログやスパンに対して Exception パネルが表示されるようになりました。ウォーターフォール上でもエラーログや例外イベントが赤色でハイライトされ、より見つけやすくなっています。
デフォルトのトレースソースはスパンイベントとリンクを自動的に読み込むため、手動でソース設定を行わなくてもスパンの例外が表示されます。
## 検索ページの改善点 {#search_page_improvements}
過去 2 か月間、私たちは検索ページの改良に注力してきました。コミュニティの皆様も同様です。以下の改善点のいくつかはコミュニティからのコントリビューションによるものであり、深く感謝いたします。PR を送ってくださった方、使いづらい点を指摘してくださった方、日々の業務が少しでも楽になるアイデアを共有してくださった皆様、ありがとうございます。
### フィールドによるヒストグラムのグループ化
検索ヒストグラムでスパイクを見つけ、どのサービスが原因なのか疑問に思ったことはありませんか？以前は、それを突き止めるために別の場所でチャートを作成する必要がありました。現在は、ヒストグラムの **Group by** コントロールを使用することで、フィールドごとにボリュームを内訳表示できます。フィルターサイドバーと同じキー一覧から選択するか、SQL 式を入力してください。互換性のあるグループ化設定は、ソースを切り替えても維持されます。
### 行を選択してコピーまたはダウンロード
同僚と共有するために、数行のログだけが必要になることがあります。チェックボックスを使用して個々の行を選択したり、`Shift` を押しながらクリックして範囲選択したりして、**Download CSV**、**Copy as CSV**、または **Copy as JSON** を選択できるようになりました。エクスポートには、選択した行と現在表示されているカラムのみが含まれます。
チェックボックスはホバー時に表示され、何らかの項目を選択した後は表示されたままになります。
### 行の詳細と行のクリック操作
テーブルに `MATERIALIZED` カラムまたは `ALIAS` カラムを追加している場合、それらが行の詳細に表示されていないことにお気づきだったかもしれません。このパネルは `SELECT *` で行を取得するため、それらのカラムは除外されていました。Column Values の表示オプションメニューで **Show materialized and alias columns** を有効にすることで、これらを含められるようになりました。現時点では、この設定はデフォルトでオフになっています。
同じメニューから **Property order** (プロパティの順序)も選択できるようになりました。A-Z、Z-A、または元の順序(original order)から指定できます。最後のオプションは、`Map` カラムや JSON 本文のキーの順序を保持したい場合に便利です。
また、サイドパネルを開く代わりに行をインラインで展開したいというユーザーからのフィードバックもいただいていました。**Preferences → Search results → Row click** を Expand inline に設定できるようになり、小さなシェブロン(山かっこ)だけでなく行全体をクリック可能にできます。ホバー時に表示されるボタンを使用すれば、引き続きサイドパネルを開くことも可能です。
### 検索可能で高速になったフィルターサイドバー
最近の変更により、属性の長いリストからキーを探す手間が少し軽減されました。`LogAttributes` や `ResourceAttributes` などの Map グループに、通常のフィルターの値検索と同様のキー検索機能が追加されました。また、各 Map カラムに個別のキー取得制限が設定されるようになり、数百のログ属性によって `ResourceAttributes` がサイドバーから押し出されることがなくなりました。
さらに、最も遅いクエリをサイドバー全体が待つ必要もなくなりました。クエリが完了するごとにフィルター値が順次表示されます。長い時間範囲では、まずキーが表示され、値が届くにつれて順次埋まっていくため、残りの読み込み中にもフィルターの適用を開始できます。
## アラート機能の強化 {#alerting_improvements}
ClickStack では皆様からの要望やフィードバックをもとに、アラート機能への投資を続けています。今後ともぜひご意見をお寄せください。
### チャートエクスプローラーから直接アラートを作成
二度と見ないようなダッシュボードタイルを作らずに、アラートだけを設定したいと思ったことはありませんか？ 従来は、ログには保存済み検索、メトリクスにはダッシュボードタイルがアラートごとに必要でした。Grafana から 1,000 件ものルールを移行する場合、これは大きな管理負担になります。
今後は、エクスプローラーでログ、トレース、メトリクスを使用し、クエリビルダーまたは生 SQL でチャートを作成して、直接アラートを追加できるようになりました。このアラートは独自のチャート設定を保持し、アラートページにチャートアイコン付きで表示されます。リンクからエクスプローラーに戻れば、クエリの確認や編集をすぐに行えます。
### Webhook テンプレートの表現力向上
グループ化されたアラートで、どのグループに対処が必要かを通知できるようになりました。`{{var.}}` を使用すると、任意の group-by カラムについて閾値を超えたグループの値を含めることができます。たとえば、`{"summary": "{{var.ServiceName}} has an elevated error rate"}` と設定すれば、各通知に対象のサービス名が含まれます。これらの値は解決通知(resolve notifications)にも含まれます。
また、`{{tags}}` 経由でアラートタグも利用可能です。これは、共有の incident.io Webhook を介して適切なチームにアラートをルーティングしたいというユーザーの要望から実現しました。
アラートが実際にトリガーされる前にテンプレートのミスを検知できる仕組みもいくつか追加しました。Webhook エディタで入力中にエラーが表示され、コンパイルできないボディは API で拒否されます。自動化されたワークフロー向けには、`POST /api/v2/webhooks/validate` で保存せずに Webhook 設定を検証できるようになり、Terraform plan の実行時に役立ちます。また、エディタには利用可能なすべての変数と説明が一覧表示され、「Send test」でサンプル値が入力されます。
## MCPサーバーの改善 {#mcp_server_improvements}
ClickStack MCPサーバーについて、本番環境と独自の評価スイートの両方で徹底的な検証を進めてきました。エージェントがどこで停滞したり遠回りしたりしているかを観察することで、取り組むべき課題が多く見つかりました。
### 1回の呼び出しでサービス健全性レポートを取得
「各サービスの状態はどうなっているか？」は単純な質問に思えます。しかし従来は、テーブルや時系列データを取得し、その結果を統合するためにエージェントが複数の呼び出しを行う必要がありました。
新しい `clickstack_service_health` ツールは、1 回の呼び出しで全サービスのスループット、エラー率、レイテンシパーセンタイル、上位エラーグループを返します。前日の同じ時間枠と結果を比較し、健全でないサービスや新規・増加傾向のエラーをハイライト表示します。サービス健全性チェックの評価において、エージェントはツール呼び出し回数を約半分に抑えながら、より高いスコアを獲得しました。
エージェントがスムーズに調査を開始できるよう支援し、コンテキスト収集で無駄にするトークンを減らし、調査の一貫性と効率を高めて問題解決を迅速化するツールに、今後も継続して注力していきます。
### 動作ヒントとサーバーメタデータ
MCP クライアントがサーバーと連携しやすくなるよう、いくつかの仕様も拡充しました。すべてのツールが 4 つの動作ヒント(読み取り専用か、破壊的か、冪等か、オープンワールドか)を明示するようになりました。クライアントは承認が必要な呼び出しを判断する際にこれらのヒントを使用し、互換性チェックによっては 4 つすべてが必須となります。
また、サーバーの初期化(initialize)レスポンスにタイトル、説明、Web サイト、アイコンが含まれるようになり、MCP ディレクトリやクライアントで一覧表示する際に必要な情報が揃うようになりました。
## コレクターでの StatsD とスパンメトリクス対応 {#statsd_and_span_metrics_in_the_collector}
決済失敗のカウント、キューサイズの追跡、ジョブ所要時間の計測などにアプリケーションですでに StatsD を利用している場合、ClickStack のためにその計装を書き直す必要はありません。[ClickStack コレクター](https://clickhouse.com/docs/ja/clickstack/ingesting-data/collector)に [StatsD レシーバー](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/statsdreceiver)が追加され、これらのメトリクスを直接送信できるようになりました。DogStatsD タグも認識するため、Datadog にカスタムメトリクスを送信しているアプリケーションにも有用です。
また、別の用途ながら関連する機能として、トレースをメトリクスに変換する [スパンメトリクスコネクター](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/spanmetricsconnector)も追加しました。トレースは個々のリクエストを表しますが、サービスが処理したリクエスト数、失敗数、所要時間全体の概要を把握したい場合も多くあります。このコネクターは、Datadog Agent からのトレースを含む受信スパンから呼び出し回数とレイテンシヒストグラムを生成するため、別途メトリクスの計装を追加することなくこれらのビューを構築できます。
これらの追加機能により、既存のアプリケーションメトリクスを ClickStack に取り込み、すでに収集しているトレースからサービスメトリクスを生成できるようになります。Datadog から移行するチームにとっては、事前の計装作業が減り、段階的に移行しやすくなります。既存の環境を停止する前に、両方のシステム間でメトリクスを比較し、ダッシュボードを再構築できます。
どちらのコンポーネントもオプトイン方式で、`CUSTOM_OTELCOL_CONFIG_FILE` を使用したカスタムパイプライン経由で設定します。スパンメトリクスコネクターは `traces.span.metrics.calls` と `traces.span.metrics.duration` を出力し、ClickStack がネイティブに保存する指数ヒストグラムをサポートします。
## 折れ線グラフの補間 {#line_chart_interpolation}
各ラインを自分で足し合わせることなく、合計値とどのサービスが最も寄与しているかを確認したい場合があります。時系列タイルで、積み上げ棒グラフに加えて**積み上げ折れ線**の表示がサポートされるようになりました。各系列には塗りつぶされた領域があり、他の系列の上に積み重なって表示されるため、全体の傾向と個々の寄与度の両方を把握できます。
また、**ライン補間(line interpolation)**設定により、プロット間の線の結び方をスムーズ(smooth)、リニア(linear)、ステップ(step)から選択できます。ステップは、稼働中のレプリカ数など、離散的に変化する値に便利です。この設定はアプリ内、外部 API、MCP サーバーから利用可能です。
## 細かながら便利な改善点 {#little_but_useful_things}
### Terraform エクスポートでのタイルアラート対応
これまでの Terraform エクスポートでは、保存済み検索に紐付いていないアラートがスキップされていました。[ClickHouse Terraform プロバイダー](https://registry.terraform.io/providers/ClickHouse/clickhouse/latest/docs/resources/clickstack_alert)のバージョン 3.28.0 で追加された `source \= "tile"` 形式を使用し、ダッシュボードタイルのアラートも含まれるようになりました。
### タイルの説明文
ダッシュボードタイルに、何を表示しているかや読み方を説明する説明文を追加できるようになりました。タイルエディタでチャート名の横に設定すると、タイルタイトルの横に情報ツールチップとして表示されます。説明文は外部 API からも設定可能です。
### メトリクスソースの最小自動グラニュラリティ
チャートを拡大すると、自動グラニュラリティによってメトリクスのスクレイプ間隔よりも小さいバケットが選択される場合があります。1 分に 1 回収集されるメトリクスが 30 秒のバケットで表示されると、1 つおきに空のバケットができてデータが欠落しているように見えてしまいます。これを防ぐため、**Team Settings → Sources** にある **Minimum auto granularity** を設定して、自動バケットの幅を少なくともスクレイプ間隔と同じ大きさに保てるようになりました。明示的なグラニュラリティが指定されたタイルには影響しません。
PromQL ソースにも最小自動グラニュラリティ設定が用意されており、短い時間範囲でスクレイプ間隔より細かいバケットが生成されるのを防ぎます。この値は、通常 15 秒のスクレイプ間隔を前提とする `$__rate_interval` の計算にも使用されます。
### 任意のタイムゾーンを選択可能に
User Preferences の **Use UTC time** スイッチがタイムゾーンピッカーになり、上部にローカルと UTC が固定表示され、その下にブラウザがサポートするすべてのゾーンが表示されるようになりました。サイドバーのバッジとタイムスタンプのカラムヘッダーに、選択したゾーンが表示されます。
### 各インスタンスへのラベル付け
リージョンごとなど、複数の ClickStack インスタンスを運用している場合に便利です。`NEXT_PUBLIC_INSTANCE_LABEL` に「UK」などの短いラベルを設定すると、ブラウザのタブタイトルとサイドバーに表示され、大量のタブの中から目的のインスタンスを見つけやすくなります。
### 外部 API レートリミットの設定機能
`/api/v2/*` リクエストの上限を `EXTERNAL_API_RATE_LIMIT_MAX` で設定できるようになり、負荷の高い連携やエクスポートジョブに余裕を持たせることが可能になりました。デフォルトは毎分 100 リクエストのままです。
### メトリクス名ピッカーの高速化
データ全体の集約処理を待つ代わりに、テーブルのプライマリインデックスからメトリクス名をストリーミングするようになりました。数千のメトリクスを持つソースでも、最初の候補が数十ミリ秒で表示されます。入力による検索は網羅的に行われるため、インデックスに含まれないメトリクスも引き続き見つけることができます。
### ダッシュボード更新時の読み込み状態の統一
数値、棒、円、テーブル、ヒートマップの各タイルで、時系列チャートと同様に、更新中も以前のデータを表示したままパルス表示されるようになりました。現在の結果を見失うことなく、更新処理中であることを確認できます。本機能を提供してくださったコミュニティに感謝いたします。
### ライブテールのプリセットを最大 6 時間に拡張
ライブテールで、従来の 1 時間の上限から 3 時間と 6 時間のプリセットがサポートされるようになりました。これより長い時間範囲は無効のままで、ピッカー内に「更新ごとにウィンドウ全体を再クエリする」旨の説明が表示されます。
### アラートページのページネーション対応
すべてのアラートをブラウザに取得するのではなく、サーバーサイドのフィルタリングを伴うページ単位での読み込みになりました。数千のアラートを抱えるチームでも、ページの動作を重くすることなく、ステータス、名前、タグによるフィルタリングを行えます。
## まとめ {#conclusion}
9 月と 10 月の新機能は以上です。ぜひこれらの新機能をお試しいただき、感想をお聞かせください。
> セルフホスト環境のアップグレード前に確認すべき点: 認証が有効になっている場合、`EXPRESS_SESSION_SECRET` を明示的に設定する必要があります。API はパブリックなデフォルト値へフォールバックしなくなりました。
フィードバックの共有、使いにくい点の報告、プルリクエストの送信を行ってくださった皆様に心より感謝申し上げます。今回ご紹介した機能の多くは、皆様のご協力によって形作られました。今後も引き続きフィードバックをお寄せいただき、次に期待する機能をお知らせください。
---
## 今すぐ始める
自社データでClickHouseのパフォーマンスを試してみませんか? ClickHouse Cloudならわずか数分で開始でき、300ドル分の無料クレジットも進呈されます。
[サインアップ](https://console.clickhouse.cloud/signUp?loc=blog-cta-2863&utm_blogctaid=2863)
---