ClickStackの新機能 - 2026年8月

毎月の ClickStack アップデートを待ちきれない方のために、毎週 Demo Day 動画 を公開しています。開発チームが開発中の機能のデモを録画しているため、このニュースレターで取り上げられる前に、開発中の機能を一足先にご覧いただけます。Slack の #o11y-clickstack チャンネルでも共有しています。

ClickStack の新機能 8 月号へようこそ。v2.34 から v2.38 までの間に 5 つのリリースが提供され、主にダッシュボードに注力しました。

ダッシュボード変数が一般提供 (GA) となりました。フィルターの選択内容は、未加工の SQL やビルダーのフィールドから Lucene や PromQL に至るまで、タイルの任意の場所で参照でき、あるドロップダウンで別のドロップダウンを絞り込むことも可能です。また、チャートで計算式がサポートされ、チャート上の 2 つの系列を組み合わせてレートや比率を算出できるようになりました。

さらに 2 つの機能追加により、ダッシュボードの構築がより迅速になり、可読性も向上しました。チャートエディタ内のメトリクスエクスプローラーを使用すると、メトリクスを選択する前に、デプロイ環境が実際に発行している内容を確認できます。

リリースマーカーにより、サービスの各バージョンが最初に登場した瞬間がオーバーレイ表示されるため、レイテンシの急増とその原因となったデプロイを照らし合わせることができます。

また、LLM オブザーバビリティダッシュボードのベータ版をリリースしたほか、Alerting には多数の改善を加えました。そのうちのいくつかは、ユーザーからの直接の要望によるものです。アラートあたり最大 10 個の通知先、アラート名とタグ、API 経由で読み取り可能な評価履歴、より詳細な Webhook ペイロードなどが含まれます。

以下では、これらすべてに加えて、新しいダッシュボードフィルタータイプ、コレクター向けの OIDC 認証、さらに強化された MCP サーバーの改善点についても取り上げます。

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

オープンソースコントリビューターの皆様、そしてこれらの多くの機能の形作りにつながるフィードバックを寄せてくださったユーザーの皆様に感謝いたします。

arj22、Vansh98789、truehazker、RIP21、espenloov、MFA-G, milansanjeev、Tyagiquamar、bsosnader、motsc

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

そのまま使えるPrometheusサポートを提供するTimeSeriesエンジン #

すでに多くのチームがログやトレースをClickHouseに保存していますが、Prometheusのワークロードを移行するには、PromQLクエリをSQLに書き直すか、変換レイヤーを維持する必要がありました。既存のPrometheusダッシュボードやツールを利用しているチームのために、すでに使われているクエリ言語をそのままサポートする方法が必要でした。

現在、TimeSeriesエンジンとPromQLサポートがManaged ClickStackでプライベートプレビューとして、オープンソースでは実験的機能として提供されており、ClickHouseでPrometheusのストレージとクエリを置き換えられるようになりました。既存のコレクターやスクレイプ設定はそのまま維持し、Prometheus remote write経由でメトリクスを送信して、ClickStackやGrafana、あるいはClickHouse内で直接PromQLを使ってクエリを実行できます。

ClickStack では、TimeSeries テーブルを PromQL データソースとして設定し、チャートエディター内で直接 PromQL を記述できます。これにより、ログやトレースと並べて Prometheus メトリクスを使用したダッシュボードを構築できます。後述のダッシュボード変数を使えば、フィルターをそれらのクエリに紐付けられるため、個々のクエリ式を編集することなくサービスや環境を探索できます。また、ClickStack を外部の Prometheus 互換エンドポイントに接続することも可能です。

今回のプレビューでは、ストレージ、クエリ実行、ダッシュボードに重点を置いています。PromQL の対応範囲は順次拡大中であり、視覚的な PromQL クエリビルダーや PromQL クエリに基づくアラートはまだサポートされていません。

アーキテクチャや設定の詳細、手元のメトリクスで試すためのプライベートプレビューへの参加方法については、発表の全文をご覧ください。

ダッシュボード変数 #

従来、ダッシュボードのフィルターでは、値を選択すると、ClickStack がそのフィルターの適用対象となるすべてのタイルに WHERE 条件を追加していました。これは大半のケースをカバーできますが、すべてではありません。

選択した値が SELECT 式や HAVING 句で必要になったり、ドロップダウンがクエリするカラムとは別のカラムに対するフィルターとして扱ったりしたい場合があります。Prometheus データソースのサポートに伴い、ダッシュボードでの選択内容を PromQL クエリにも反映させる必要が生じました。PromQL のフィルタリングでは、SQL の WHERE 句ではなくラベルマッチャーを使用するためです。同一ダッシュボード上で、SQL でクエリするログと PromQL でクエリするメトリクスの両方を 1 つのサービスドロップダウンで絞り込みたいケースなどが該当します。

ダッシュボード変数を利用すると、各タイルがクエリ内の必要な場所で選択値を参照できるようになり、これを実現できます。

既存・新規を問わず、どのフィルターでもフィルターダイアログで「Available as variable」に設定できます。設定すると、現在の選択内容が $variableName としてタイルのクエリに公開され、タイルごとにその値をどこでどのように使用するかを決められます。ブロードキャストモードと変数モードは個別に有効化できるため、フィルターの既存の動作を維持したまま変数としても利用できます。

ここでは、ログの重大度 (Severity) ドロップダウンが、選択された重大度をトレースステータスにマッピングすることで、サービスごとのトレースボリュームの時系列推移を絞り込んでいます。何も選択されていない場合はすべてのステータスが含まれます。

Raw SQL タイルでは、クエリ内の任意の場所で変数を参照できます。参照形式によって展開方法を制御できます。$name は選択された値を SQL 文字列として展開し、${name:csv}、${name:regex}、${name:lucene} はそれぞれカンマ区切りリスト、正規表現の選択候補、引用符付き用語の OR 結合として展開します。

選択値が空の場合は扱いが難しくなります。何も選択されていない状態で $name をそのまま使うと NULL として展開され、チャートが気付かないうちに空になってしまいます。まさにこのケースのために 2 つのマクロが用意されています。$__filter($var) は値が選択されているときは IN 条件に、それ以外の場合は 1=1 に展開されます。$__conditionalAll(condition, $var) は、上記の例で使われているように、変数で値が選択されている場合にのみ任意の条件を含めます。

1SELECT
2    $__timeInterval(TimestampTime) AS ts,
3    ServiceName,
4    count() AS count
5FROM otel_traces
6WHERE $__timeFilter(TimestampTime)
7    AND $__filter(ServiceName, $service)
8    AND $__conditionalAll(
9        StatusCode = transform(
10            $Log_Severity,
11            ['error', 'info', 'information', 'trace', 'warn'],
12            ['Error', 'Ok', 'Ok', 'unset', 'unset'],
13            'unset'
14        ),
15        $Log_Severity
16    )
17GROUP BY ServiceName, ts
18ORDER BY ts ASC;

上記の例のように、条件付きマクロを使用することでソース間のマッピングが可能になります。ダッシュボード側でトレースのステータスコードを error や info にマッピングできるため、ログテーブルに対して定義された重大度フィルターでトレーステーブルを絞り込めます。ダッシュボード上で error を選択すると、トレースクエリは error ステータスで絞り込まれます。

ビルダータイルでも、すべての SQL 式の入力欄で同様の置換が可能です。SELECT、WHERE、GROUP BY、HAVING、ORDER BY のすべてで変数がサポートされており、Lucene クエリでも同様に利用できます。

オートコンプリートは利用可能なすべての変数とマクロを提案します。また、現在の選択値を使って実際にどのように展開されるかもインラインで表示されるため、実行前にどのようなクエリになるかを確認できます。

フィルター同士を連動させることも可能で、連鎖フィルター (chained filters) を作成できます。たとえば、フィルターの WHERE 句から他の変数を参照できるため、サービスフィルターを参照する重大度ドロップダウンには、選択されたサービスで発生した重大度のみを表示させることができます。

変数のサポートは、Prometheus ダッシュボードでフィルターを機能させ、PromQL による可視化をインタラクティブかつフィルターに連動させるために不可欠です。上記で紹介した Prometheus サポートの一環として、ダッシュボード変数がフィルターをこれらのクエリに結び付け、手動で PromQL を編集することなく、さまざまなサービスや環境を探索できるようになります。

PromQL チャートはクエリの実行前に変数を置換し、変数参照のオートコンプリート機能や、既存の生成 SQL パネルと並んで生成された PromQL のプレビューを提供します。

外部ダッシュボード API、MCPサーバー、そして API を介した ClickHouse Terraform プロバイダーはいずれも変数の設定に対応しています。エージェントは、変数フィルター、依存関係のあるドロップダウン、それらを参照するタイルを備えたダッシュボードを構築し、ダッシュボードを引き渡す前にクエリタイルのツールを使って自らの置換内容を確認できます。

チャートでの数式利用 #

エラー数と成功リクエスト数を同じチャートにプロットすると、2 つのカウントが表示されます。失敗率を確認するには、これらを組み合わせる必要があります。チャートの数式機能を使えば、チャートエディター内で直接計算できます。

時系列、テーブル、数値チャートに「Add Formula」行が追加されました。各系列には A や B などの文字参照が割り当てられ、算術式の中で利用できます。たとえば、A がエラー数で B が成功リクエスト数の場合、A / (A + B) * 100 で失敗したリクエストの割合を算出できます。数式はメトリクス、ログ、トレースの各ソースで機能し、同じチャートに複数追加することも可能です。

各数式には独自のエイリアスと数値フォーマットを設定できます。Show input series トグルを使うと、計算結果と一緒に元の系列を表示するか、計算値のみを表示するかを切り替えられます。

ClickHouse はチャートクエリの一部として数式を計算します。数式を使ったチャートに対するアラートは計算結果を評価するため、失敗率に対して直接アラートを設定できます。数式はダッシュボード API や MCP サーバー経由でもサポートされています。

数式では系列参照に対する算術演算をサポートしています。ClickHouse の関数や他の数式への参照は現時点ではサポートされていません。

チャートエディターでのメトリクス探索 #

ClickStack のメトリクスセレクターは、メトリクス名が事前に分かっている場合に最適化されていました。名前が分からない場合、フラットなドロップダウンではサービスが実際に何を出力しているのかを把握しにくい状態でした。TimeSeries エンジンのリリースに伴い、メトリクスワークロードを ClickHouse に移行するユーザーが増加したため、そうしたメトリクスを探索するより優れた方法が必要になりました。

これに対処するため、メトリクスセレクターの横にメトリクスエクスプローラーを開く Browse metrics コントロールを追加しました。メトリクス名はツリー構造にグループ化されているため、system.cpu.utilization は system、次に cpu の下に表示されます。名前や説明全体を検索したり、フラットなリスト表示に切り替えたりすることもできます。

メトリクスを選択すると、そのタイプ、単位、説明、レポート元のサービス、利用可能なタグが表示されます。タグ値の確認、フィルターやグループ化の選択を行い、それらをメトリクスと一緒にチャートへ適用できます。また、エクスプローラーはメトリクスのタイプに適した集計方法を設定します(ゲージは平均、カウンターは合計、ヒストグラムは p95)。

ダッシュボードチャートのリリースマーカー #

ClickStack のダッシュボードではレイテンシやエラー率の変化を確認できましたが、サービスがいつ更新されたかを示す情報はありませんでした。スパイクの原因がリリースにあるかどうかを確認するには、デプロイツールを確認し、手作業でタイムスタンプを突き合わせる必要がありました。

そのコンテキストをダッシュボード上に取り込むため、リリースマーカーを追加しました。ダッシュボードメニューから Show release markers を有効にすると、テレメトリに新しいサービスバージョンが初めて出現したタイミングで、チャート上に縦の破線が表示されます。マーカーにカーソルを合わせると、サービス、バージョン、日時を確認できます。

リリースマーカーは、既存のログやトレースに含まれるバージョン情報を利用します。デフォルトでは、OpenTelemetry の service.version リソース属性を読み取ります。バージョンを別の場所に記録している場合は、ソース側で Service Version Expression を設定できます。例えば、コンテナのイメージタグを使用しているチームは ResourceAttributes['container.image.tag'] を指定できます。

マーカーは各チャートに表示されているサービスに連動します。1つのサービスでフィルターされたチャートにはそのサービスのリリースが表示され、サービスごとにグループ化されたチャートには各サービスのラインに合わせた色でマーカーが表示されます。複数のサービスを1本のラインにまとめたチャートにはマーカーは表示されません。

LLM オブザーバビリティダッシュボード (ベータ) #

ClickStack ユーザーはすでに、LLM アプリケーションやコーディングエージェントからログやトレースを送信しています。しかしこれまでは、どのモデルが使用されているか、消費されたトークン数、会話中に何が起きたかを把握するための専用ビューがありませんでした。

既存の ClickHouse、Kubernetes、サービスのプリセットに加え、ベータ版の LLM オブザーバビリティダッシュボードを追加しました。トークン使用量、モデル呼び出し、ツール呼び出し、キャッシュヒット、エラー率、レスポンスタイムを網羅しており、情報が利用可能な場合はユーザーごとの内訳も表示されます。

このダッシュボードは既存のトレースやログを読み取るため、今回のリリース以前に収集されたテレメトリでも動作します。OpenTelemetry GenAI セマンティック規約、OpenLLMetry、OpenInference、Vercel AI SDK のテレメトリをサポートしており、専用テーブルの作成や取り込みの変更は不要です。

Sessions タブでは、呼び出しが会話ごとにグループ化されます。セッションを開くとそのタイムラインが表示され、呼び出しを展開してメッセージの内容確認、ツール呼び出しの調査、トークン使用量の確認ができます。

Latency タブは、時間のかかっているモデル呼び出しやツール呼び出しの調査に役立ちます。所要時間のヒートマップから領域を選択すると、モデルやトークン数など、それらの呼び出しを特徴づける属性を確認できます。Errors タブでは、失敗した LLM スパンと関連するエラーログをまとめて確認できます。

このダッシュボードは、完全な LLM オブザーバビリティや AI エンジニアリングのソリューションではありません。評価やプロンプト管理など、より広範な機能が必要な場合は、Langfuse の利用をお勧めします。

アラート機能の改善 #

2026年8月は、アラート機能に関していくつかの改善を行いました。その多くはユーザーの皆様からのリクエストに基づいています。今回の改善には、より多くの宛先への通知送信、アラートの整理、アラート評価時に何が起きたかの把握が含まれます。

複数の通知先への対応 #

従来の ClickStack のアラートでは、通知先が 1 つに制限されていました。オンコール担当のエンジニアを呼び出しつつ、チームのチャンネルにも投稿したい場合、2 つのアラートを作成してそれらの条件を同期させ続ける必要がありました。

今回から、1 つのアラートで最大 10 か所の通知先を指定できるようになりました。保存された検索条件やダッシュボードタイルのアラートエディタから直接追加・削除でき、アラートページには設定されたすべての通知先が表示されます。

評価履歴には通知先ごとの通知所要時間や失敗も表示されるため、どの連携先で遅延やエラーが発生しているかを特定しやすくなります。複数の通知先への対応は、外部 API や MCP サーバー経由でも利用できます。

アラート名とタグ #

従来のアラートは、監視対象の保存された検索条件やダッシュボードタイルの名前をそのまま引き継いでいました。チームで作成するアラートが増えるにつれて、それらを識別したり整理したりすることが難しくなっていました。

今回から、各アラートに独自の名前とタグを設定できるようになり、アラートページでそれらを使った検索やフィルタリングが可能になりました。新規アラートには所属するダッシュボードや保存された検索条件の名前とタグが初期値として設定されますが、アラートエディタで変更できます。

評価履歴 #

アラートでエラーが発生した際、従来の ClickStack では最新のエラーのみが表示されていたため、それ以前の評価が成功していたのか、あるいはアラートがスケジュールどおりに処理を続けられているのかを把握できませんでした。

現在は、クエリエラー、タイムアウト、通知の失敗などを含め、各評価が個別に記録されるようになりました。履歴にはクエリの所要時間やバックフィルされた時間枠も記録されるため、アラートの処理に遅れが生じているかどうかを確認できます。

エラーが発生した評価は、アラートページの履歴から確認できます。同様の履歴は GET /alerts/:id/evaluations の API 経由でも取得可能で、時間範囲によるフィルタリングや、グループ化されたアラートのグループ別内訳の取得に対応しています。

Webhook ペイロードの拡充 #

外部システムでアラートのルーティングや重複排除を行うには、従来、レンダリングされたタイトルやメッセージから情報を抽出する必要がありました。

汎用 Webhook および incident.io の Webhook テンプレートで、アラートの ID、ステータス、条件、観測値、評価時間範囲の各フィールドが利用できるようになりました。固定の alertId によって繰り返される通知間でも同一のアラートを識別できるため、下流のシステムで重複排除のキーとして利用できます。

Webhook エディタには利用可能な変数と説明が一覧表示され、Test Webhook にはサンプル値が含まれるため、アラートが実際に発生する前に連携の動作を確認できます。

ダッシュボードフィルターの新しいタイプ #

ClickStack のダッシュボードフィルターは、ClickHouse のカラムをクエリすることでドロップダウンの選択肢を生成していました。この方法はデータから選択肢を取得する場合には有効ですが、提供したい値があらかじめ決まっている場合もあります。また、Prometheus データソースでは、メトリクスラベルからドロップダウンの選択肢を生成する仕組みも必要でした。

そこで、フィルターと変数のダイアログに 2 種類のフィルタータイプを追加しました。

静的な値 (Static values) では、選択肢を独自に定義できます。たとえば、環境フィルターであれば、クエリを実行して値を検出することなく「dev」、「staging」、「prod」を提供できます。静的フィルターは前述の変数を通じて機能し、各タイルはクエリ内で選択された値を参照します。

また、グラフでのデータの表示方法を制御するためにも使用できます。たとえば、ServiceName や SeverityText を含むドロップダウンを用意することで、ユーザーがグラフの結果のグループ化方法を選択できるようになります。

PromQL label values フィルタータイプを使用すると、PromQL ソース内のメトリクスラベルからドロップダウンを作成できます。フィルターの設定時には、オートコンプリートを使用してラベルを選択でき、必要に応じてシリーズマッチャーを追加してドロップダウンに表示される値を絞り込むことも可能です。

マッチャーは他のダッシュボード変数を参照できるため、フィルター同士を連動させることが可能です。インスタンスのドロップダウンで選択された環境を使って、その環境内のインスタンスのみを表示し、PromQL チャートではそれらの選択内容を使用して結果を絞り込むことができます。

OTLP レシーバーの OIDC 認証 #

スタンドアロンの ClickStack コレクターは、単一の共有トークンを使用して受信テレメトリーを認証していました。この方式は設定が簡単である一方、データを送信するすべてのアプリケーションが同じ長期有効な認証情報を必要としました。大規模な環境を運用するチームにとって、そのトークンをローテーションすることは、すべてのアプリケーションにわたる更新の調整を意味していました。

コレクターが OpenID Connect (OIDC) 認証に対応したことで、アプリケーションは既存の ID プロバイダーやワークロードアイデンティティシステムから取得した有効期間の短いトークンを使用してテレメトリーを送信できるようになりました。

設定するには、コレクターで OIDC_ISSUER_URL と OIDC_AUDIENCE を指定します。アプリケーションは、OTLP リクエストの Authorization: Bearer <token> ヘッダーに JWT を含めて送信します。コレクターはプロバイダーの署名キーを取得し、トークンの署名、発行者、オーディエンス、有効期限を検証します。

これにより、共有シークレットを環境全体に配布することなく、ID プロバイダーを通じて認証情報を管理し、個々のアプリケーションにトークンを発行できます。

OIDC 認証はスタンドアロンコレクターモードで利用可能です。共有トークンによる認証も引き続きサポートされますが、両オプションは排他的です。OIDC_ISSUER_URL を設定すると OIDC が有効になります。

MCP サーバーの機能強化 #

評価フレームワークを活用してエージェントによる問題調査やダッシュボード構築のテストを行いながら、ClickStack MCP サーバーの拡張を続けています。本アップデートでは、ログパターンの変化を検出するツールやダッシュボード検証ツールの追加に加え、エージェントによる実際のサーバー利用状況に基づいた改善を行いました。

新規および消失したログパターンの検出 #

既存のパターンツールは、エージェントが一般的なログメッセージを見つけたり属性値を比較したりするのには役立ちましたが、新しく出現し始めたログパターンを特定することはできませんでした。調査中には、新しく発生したエラーメッセージが何が変化したかを解明する手がかりになるため、これは重要です。

新しい clickstack_emerging_signals ツールは、異なる時間枠の間でログパターンを比較します。新しく出現したパターンや頻度が増加しているパターン、また消失したパターンをレポートします。

ClickStack の service-health-check 評価では、このツールを使用しなかった場合は皆無だったのに対し、使用した場合は 10 回中 8 回の実行で意図的に仕込んだ新しいログパターンをエージェントが検出しました。

ダッシュボード全体の検証 #

従来、エージェントが構築したダッシュボードが実際に機能するかどうかを確認するには、各タイルを個別にクエリする必要がありました。規模の大きなダッシュボードでは、結果を検証するだけのために膨大な呼び出しが発生していました。

新しい clickstack_query_tiles ツールは、1 回の呼び出しで複数のタイルをチェックし、それぞれの結果、エラー、クエリ警告の概要を返します。ダッシュボード構築の評価では、エージェントがこれを使用して 17 個のタイルからなるダッシュボードを 1 回の呼び出しで検証しました。

エージェントによる適切なツール選択の支援 #

本番環境の利用状況から、利用可能なツールが増えるにつれて、エージェントが生の SQL を選択する傾向が強まっていることが判明しました。生の SQL はクエリ呼び出しの約 73% を占め、ビルダーツールと比べて約 2 倍のエラー率を示していました。

そこで、ツールの説明とサーバーの指示を更新し、エージェントがビルダーツールを優先的に選択するように誘導しました。ビルダーツールは平均して約 20% 精度が高く、ツール呼び出し回数も 27% 削減されます。ビルダーツールはユーザーが詳細をドリルダウンできるチャートやテーブルを生成しますが、ビルダーで表現できないクエリには引き続き生の SQL を使用できます。

また、ツールがデータを読み取るだけなのか、それとも変更を加える可能性があるのかを宣言するようになり、クライアント側で承認が必要なアクションを判断しやすくなりました。

双方向のスパンリンク #

アプリケーションが Kafka 経由で処理をオフロードする場合、メッセージを送信するプロデューサーとそれを処理するコンシューマーが別々のトレースに現れることがあります。OpenTelemetry のスパンリンクはそれらの処理を接続し、サービスをまたいで処理を追跡できるようにします。

ClickStack では、コンシューマーからそのプロデューサーへとリンクを遡る追跡には既に対応していました。しかし、プロデューサー側から開始した場合、そこにリンクしているコンシューマーを見つける手段がありませんでした。そのため、メッセージが発行された後に何が起こったかを調査することが困難でした。

スパン詳細パネルに Linked from セクションを追加し、表示中のスパンを参照しているスパンを見つけられるようにしました。コンシューマーからプロデューサーへのリンクをたどり、そのプロデューサー側に一覧表示されたコンシューマーを確認できるようになりました。

既存の Span Links セクションにも、より詳しい情報が表示されるようになりました。リンクされた各スパンには名前、サービス、所要時間、タイムスタンプが含まれており、開く前に調査対象を判断しやすくなっています。対象のスパンが見つからない場合でも、Open trace アクションを引き続き利用できます。

すでにアクセスしたスパンに戻る際には既存のパンくずに戻るようになり、リンクされたスパン間を行き来してもナビゲーション履歴が見やすく保たれます。

Little but useful things #

What's new, in the app #

Help メニューから、利用中の ClickStack のバージョンにおける変更点を確認できるようになりました。リリースのハイライトや、新機能・破壊的変更のバッジが表示されるほか、View all releases オプションから過去のアップデートを閲覧することもできます。

タイルのクエリを Search で再実行 #

ログおよびトレースのダッシュボードタイルに Replay search アクションが追加されました。タイルのソース、クエリ、ダッシュボードのフィルター、時間範囲を引き継いだ状態で、新しいタブに Search を開きます。これにより、クエリを再構築することなく、グラフの背景にあるイベントを調査できます。

PromQL の凡例テンプレート #

以前の PromQL チャートでは、メトリクス名とそれを区別するラベルを使って各系列にラベルを付けていたため、凡例が読みづらくなることがありました。表示設定で Handlebars テンプレートを定義し、表示したいラベルのみを指定できるようになりました。

ヒートマップのパーセンタイルツールチップ #

ヒートマップのセルにカーソルを合わせると、そのバケットが分布全体のどこに位置するかが表示されるようになりました。パーセンタイルを直接確認できるため、その所要時間が一般的なものなのか、あるいは最も遅い部類に入るのかを把握しやすくなります。

アラートページの高速化 #

アラート数が数千件に及ぶ環境では、アラートページがブラウザに大きな負荷をかけることがありました。リストが現在画面に表示されている行のみを描画するようになり、大量のアラート一覧もスムーズに閲覧できるようになりました。

名前によるソースへのリンク #

ClickStack へのリンクで、ID に加えて名前でもソースを特定できるようになりました。環境ごとにソース ID が異なる場合や、ソースの再作成によって ID が変わる場合があるランブックやアラート連携で便利です。

まとめ #

8 月のアップデートは以上です。8 月は、アラートや MCP サーバーの機能強化、Prometheus や LLM ワークロードへの対応と並行して、ダッシュボードの作成しやすさと調査時の有用性を向上させる取り組みに注力しました。

これらの変更の多くは、実際に ClickStack を運用しているユーザーから使いづらい点をご報告いただいたことで実現しました。引き続きフィードバックをお寄せいただき、今回ご紹介した機能をぜひお試しください。今後追加してほしい機能のご意見もお待ちしております。