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

ClickStack の新機能 - 6・7月号へようこそ。今回は 2 回分のリリースを 1 つのアップデートにまとめたため、通常よりも少し盛りだくさんの内容でお届けします。

過去 2 か月間の取り組みの多くはトレースに焦点を当てたものであり、ユーザーからのフィードバックに直接応えたものです。ウォーターフォールではサービスごとに個別の色が使用されるようになりました。新しいミニマップにより、トレースの一部を確認している最中でもトレース全体の形状を把握でき、スパン詳細パネルには OpenTelemetry のスパンリンクが表示されるため、トレース間をスムーズに移動できます。

メトリクスについては、指数ヒストグラム (exponential histogram) に対する分位数 (quantile) のサポートを追加し、より無駄のないデフォルトスキーマを導入したほか、外部の 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 月にこの分野へ大幅な投資を行い、ビューの再設計とスパンリンクのサポートを実施しました。

トレースウォーターフォールの再設計 #

2026年5月には、スパンの詳細を分割ペインへ移行し、スパンを調査している間もウォーターフォールが表示されたままになるようにしました。今回のリリースでは、ウォーターフォール自体に焦点を当てました。

各サービスに固定の色が割り当てられ、操作名とサービスラベルの横に垂直バーとして表示されるようになりました。以前は、スパンバー内のテキストの背景を塗りつぶす形で色が表示されていました。緑色は関連するログ行専用、赤色はエラースパン専用として保持されているため、どちらもサービスの色と混同されることはありません。

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

また、極めて短いスパンにおけるズーム時の挙動も修正しました。以前は最小幅がウォーターフォール領域の割合として定義されていたため、ズームするにつれて幅が広がっていました。これにより、非常に短いスパンが数秒間続くスパンと同じ幅で表示されることがありました。現在では最小幅が固定のピクセル幅になり、すべてのズームレベルでスパンの比率が保たれつつ、1 ピクセル未満のスパンでもクリック可能な状態が維持されます。

深いトレースの移動も簡単になりました。展開と折りたたみの操作は、1 つの階層またはトレース全体に対して実行できるようになり、折りたたむノードが存在する場合にのみ表示されます。

長いトレース向けのミニマップ #

トレースビューの改善により大規模なトレースの移動はスムーズになったものの、依然として 1 つの画面に収まりきらない場合があります。特定セクションへズームインした後に、そのセクションがトレース全体の中でどこに位置しているのかを把握するのが難しい場合がありました。以前は全体表示に戻るために、ズームアウトを繰り返すか、表示を完全にリセットする必要がありました。

これに対応するため、ウォーターフォールの上部にミニマップを配置しました。トレース全体の範囲を時間軸として表示し、スパンごとに 1 本のバーを示します。枠線付きの長方形が現在の表示範囲を示し、薄暗いオーバーレイによってトレースの残りの部分と区別されます。ミニマップ上をドラッグしてズームしたり、表示範囲をドラッグしてパンしたり、両端をドラッグしてサイズを変更したりできます。

トレースビューアにおけるスパンリンク #

スパンリンクは、あるスパンを別のトレース内のスパンに関連付ける OpenTelemetry の仕組みです。プロデューサーからコンシューマーへの処理の受け渡し、バッチジョブによる元のソースレコードの参照、リトライされたリクエストによる新しいトレースの開始といったケースをカバーします。これらのスパンは、トレース ID を共有していなくても因果関係があります。

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

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

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

2026年5月、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 ではそのコストを抑えるために、メタデータ用のマテリアライズドビューを以前から活用していましたが、どの方法でクエリを実行するかを決定するロジックが複雑化し、処理経路が重複するようになっていました。

そこで、フィルター候補の生成戦略を決定するロジックを見直し、利用可能な選択肢をコストの低い順に試行するように改修しました。

第1の選択肢は、mergeTreeTextIndex() テーブル関数を介して読み取る ClickHouse のテキストインデックスです。これにより、基盤となるデータパートを読み込むことなく、インデックス内にすでに保存されているタームを一覧取得できます。これは Map カラムに対するテキストインデックスだけでなく、TraceId などのネイティブなカラムにも有効です。

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

オートコンプリートも同じ経路を使用するようになり、入力補完の候補とフィルター値で共通の実装が使われるようになりました。

mergeTreeTextIndex() の経路には ClickHouse 26.3 以降が必要です。それより前のバージョンではルーターがこの経路をスキップし、代わりにメタデータロールアップを使用するため、どちらの環境でもフィルターは機能します。

ダッシュボードフィルターの連動(カスケード) #

ダッシュボードのフィルタリング機能は過去数か月で大幅に強化されました。フィルターに表示される値の絞り込み機能に始まり、5月にはソーススコープフィルターをサポートしました。しかしこれまでは、すでに適用されているフィルターにかかわらず、各ドロップダウンにはそのカラム内のすべての値が表示されたままでした。たとえば Kubernetes ダッシュボードで特定のクラスターを選択しても、ネームスペースのドロップダウンには他のクラスターのネームスペースも並んでしまい、選択しても結果が返らないものが大半を占めていました。

ダッシュボードのフィルターバーと Kubernetes ビューに、「Link filters」トグルが追加されました。これを有効にすると、各ドロップダウンには現在の選択条件と共存する値のみが提示されるようになります。たとえばクラスターを選択すると、ネームスペースのリストはそのクラスター内に存在する項目だけに絞り込まれます。Kubernetes フィルターバーでのフリーテキスト検索も、同様の絞り込みに連動します。

クエリコストの観点から、リンク機能はデフォルトで無効になっています。絞り込まれた値は現在の選択状態に依存するため、通常のドロップダウンで使用されるキーごとの安価な集計値を利用できません。これらのルックアップは、データソースが大きくなるにつれて大幅にコストが高くなります。

そのコストを抑えるため、絞り込まれた値はドロップダウンが開かれたときにのみ取得されます。これにより、ダッシュボードがトリガーする追加ルックアップの回数に上限を設けています。

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

一時的ですでに解消した問題によって、午前3時にアラートで誰かが呼び出される原因として、ノイズを含む単一の評価ウィンドウがよく挙げられます。一時的なレイテンシのスパイクやリトライの集中、あるいはエラー率を一時的に上昇させるデプロイによってしきい値を超え、アラートが発報されたものの、通知を読み終える前に復旧しているというケースがあります。

アラートが発報する前に、複数の連続したウィンドウで条件が維持されるのを待機できるようになりました。アラートで 1 分間のウィンドウが 3 回連続して必要とされる場合、しきい値が 3 回連続で超過した後にのみ通知が送信されます。これにより、しきい値を引き上げて持続的な問題に対するアラートの感度を落とすことなく、短時間のスパイクをフィルタリングできます。

アラートが必要なウィンドウ数を蓄積している間は、新しい PENDING 状態が報告されます。これにより、今にも発報しそうなアラートと、アクティブな条件が存在しないアラートを区別できます。

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

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

指数ヒストグラム は、OpenTelemetry の 2 つのヒストグラムタイプのうち、よりコンパクトな形式です。あらかじめ固定のバケット境界を定義する代わりに、スケールファクターとインデックスを使用して各バケットを表現します。これにより、インスツルメンテーションの作成者が有用なレイテンシ境界を事前に予測しなくても、1 つのメトリクスで広範囲の値を高解像度でカバーできます。

指数ヒストグラムのサポートは、メトリクス対応に関して最も多く寄せられていたリクエストの 1 つでした。

クエリビルダーが、exponential histogram メトリクスに対する quantile および sum 集約に対応しました。これらのメトリクスは、他のメトリクスタイプと並んでメトリクス名セレクターにも表示されます。

quantile の計算は、固定バケットのヒストグラムよりも複雑です。スケールはシリーズ間や同じシリーズ内のデータポイント間でも異なる場合があります。集約を実行する前に、ClickStack はカウントを存在する最小スケールに正規化します。これにより、オフセットの整合性を保ちながら、細かいバケットをより粗いバケットに統合します。

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

整列が完了すると、各時間バケット内でシリーズを横断してバケットが合算されます。ClickStack は累積カウントを使用して要求された quantile を含むバケットを特定し、そのバケット内で対数線形補間(log-linear interpolation)を用いて値を推定します。これは Prometheus の挙動と一致します。

カテゴリカル棒グラフ #

ClickStack は以前から棒グラフをサポートしていましたが、時間軸に沿ってバケットごとに1本の棒を表示する時系列データとしてのみでした。「その日、最も多くのエラーを発生させた上位10個のエンドポイントはどれか」といった問いに答えるには円グラフを使う必要がありましたが、比較する値が多いと読み取りにくくなっていました。

Chart Explorer、ダッシュボード、MCPサーバー、および外部ダッシュボード API において、カテゴリカル棒グラフが独自の表示タイプとして利用できるようになりました。各棒が時間バケットではなくグループを表すため、ランキング形式の比較がはるかに読み取りやすくなります。

新しい棒グラフと既存の円グラフは、時系列グラフで既に利用可能だったシリーズ数の制限(series limit)もサポートしています。ただし、カテゴリカルグラフでの実装は異なり、時系列グラフではすべての時間バケットにわたって上位シリーズを計算するために CTE が必要となるのに対し、カテゴリカルグラフではクエリ内の ORDER BY と LIMIT に変換されます。

並び順も設定可能です。カテゴリカルグラフはこれまで値の降順に固定されていました。現在は値の降順をデフォルトとしつつ、任意の SQL 式を指定して並べ替えることができます。

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

イベントパターンは、類似したメッセージを少数の代表的なパターンにグループ化します。これは、サービスが出力している内容を理解するための最も迅速な方法となることがよくあります。

以前は、パターンは検索ページに限定されていました。調査中に利用することはできましたが、その結果を、解釈の補助となるチャートと一緒にダッシュボードへ保存することはできませんでした。

イベントパターンがダッシュボードのタイルタイプとして利用可能になりました。タイルエディターには、分析対象のカラム式(ログの場合はデフォルトで Body、トレースソースの場合は SpanName)を指定する専用セクションが用意されているほか、Lucene または SQL で任意のフィルターを指定できます。これはパターンマイニングをデータのサブセットに限定するのに便利です。

UI、MCPサーバー、外部 API を網羅してサポートしているため、エージェントも displayType: "event_patterns" を使用してパターンタイルを作成できます。

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

オフィスのスクリーンにダッシュボードを表示し続けているチームは数多くあります。これまでは、編集可能なダッシュボードを開いたままにして、誰かがマウスを持って通りかからないよう祈るしかありませんでした。また、誰も操作するはずのないディスプレイ上で、編集インターフェースが無駄にスペースを占有していました。

ダッシュボードにキオスクモードが追加され、オーバーフローメニューから利用できるようになりました。インターフェースはダッシュボード名、ライブ読み取り専用インジケーター、およびタイル自体のみに絞り込まれます。すべての編集コントロールは無効化され、トレースおよび検索タイルのライブ動作を含め、自動更新は常に有効になります。

キオスクモードは URL 内に kiosk=true として保持されます。壁掛けディスプレイでその URL を直接開けば、再起動後も再設定の手間なくキオスクモードへ復帰できます。

External API を介した保存済み検索と Webhook の管理 #

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

今回、両方の対応が完了しました。新しい /api/v2/saved-searches ルーターが一覧取得、個別取得、作成、更新、削除をサポートし、/api/v2/webhooks には既存の一覧取得エンドポイントに加えて POST、PUT、DELETE が追加されました。

すべてチームスコープで動作し、保存済み検索のリクエストは埋め込みのソースオブジェクトではなく sourceId でソースを参照します。保存済み検索のピン留めフィルターは書き込み時にバリデーションされ、保存されたまま無視されるのではなく、サイドバーのファセットとして実際に表示できることが確認されます。

この対応とあわせて、アラート、保存済み検索、Webhook の v2 一覧取得エンドポイントがページネーションに対応し、limit と offset を受け取って総数(total)を含む meta ブロックを返すようになりました。件数制限のない一覧取得に依存していたクライアントがある場合は、総数を取得してページ送りを行う必要があります。

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

メトリクステーブルには際立った特徴があります。比較的少数のシリーズで構成され、それぞれに時系列で記録された多数のデータポイントが含まれ、各シリーズは属性によって識別されます。

従来のデフォルトスキーマでは、属性の Map そのものでソートしていました。

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

ソートキーに Map を直接配置するのはコストがかかります。主キーのインデックスはその Map の値をメモリ上に保持する必要があり、リソース属性やメトリクス属性を含む Map は肥大化しがちだからです。

新しいデフォルトスキーマでは以下を使用します。

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

属性をハッシュ化することで、完全な Map をソートキーに格納する代わりに、各シリーズへコンパクトな固定長の識別子を割り当てられます。これにより、インデックスのメモリフットプリントが削減されます。

時間単位のバケットを属性ハッシュの前に配置したことで、時間でフィルターするクエリは、属性を調べる前にグラニュール全体をスキップできるようになりました。また、TimeUnix の min-max インデックスにより、データを低コストで絞り込む別の手段も得られます。

これらの変更が合わさることで、メトリクスクエリが読み込むデータ量とインデックスが使用するメモリ量の両方が削減されます。

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

OpenTelemetry Collector 向け Datadog レシーバー #

OpenTelemetry Collector の ClickStack ディストリビューションに、オプトイン方式の Datadog レシーバーが含まれるようになりました。既存の Datadog Agent から、計装コードにすぐ手を加えることなく、ClickStack へトレース、メトリクス、ログを送信できます。

ENABLE_DATADOG_RECEIVER を設定すると、OpAMP コントローラーが 0.0.0.0:8126 で contrib の datadogreceiver をトレース、メトリクス、ログのパイプラインに追加します。コレクターの認証が有効な場合、レシーバーは 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」を有効にすると、関連する各タイル上で、アラート発生時には赤いマーカー、復旧時には緑のマーカーが表示されます。

ブラウザ RUM ダッシュボードの強化 #

2026年5月にリリースされた ブラウザ RUM ダッシュボード で、タイルが値に応じて色分けされるようになりました。Core Web Vitals には Google の「良好」「要改善」「不良」のしきい値が使われ、ページロードにはレイテンシ帯が使われ、エラーが存在するとエラータイルが黄色に変化し、各しきい値を説明する凡例も表示されます。単一値のタイルには、コンテキストを把握しやすくするために背景に薄いスパークラインも表示されます。新しい「Sessions」セクションには rum.sessionId ごとの直近のセッションが一覧表示され、ページビュー数、エラー数、個別トレース数、ユーザー、サービス、最終アクティブ時刻が含まれ、各行からそのセッションでフィルターされたトレースへリンクします。「Memory」セクションには、documentLoad スパンの performance.memory.* 属性に基づくページごとの JavaScript ヒープタイルが追加されました。

テーブルタイルの外部リンク対応 #

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

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

ダッシュボードタイルのドラッグやリサイズを行う際に、タイルの背後にグリッドが表示され、タイルが実際に配置されるセルがハイライトされるようになりました。

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

5月のサービスマップの改善に続き、メトリクスモードが追加されました。レイテンシ、エラー率、スループットに応じてグラフを色分け表示できるほか、カラースケールやノードサイズがスループットを表す仕組みを説明する凡例も用意されています。

まとめ #

6月と7月には、よりリッチになったトレースナビゲーションやメトリクス対応の拡充から、よりスマートなダッシュボード、アラート、APIに至るまで、ClickStack 全体でさまざまな改善が行われました。これらの変更の多くは、ユーザーからのフィードバックやコントリビューションから直接生まれたものであり、ClickStack の高速化、運用の容易化、そして既存のオブザーバビリティツールと併用するチームにとっての柔軟性の向上を実現しています。ぜひ最新リリースをお試しいただき、今後どのような機能がほしいか、いつでもご意見をお寄せください。