必須のダッシュボードフィルター
デモ提供: @pulpdrew
ダッシュボードのフィルターを必須に設定できるようになり、値が選択されるまでタイルが読み込まれないようになりました。従来はすべてのフィルターが任意だったため、大規模なログソース上に構築されたダッシュボードを開くと、何も絞り込まないうちにすべてのタイルがフィルターなしで実行されていました。
フィルター定義に Required トグルが追加されました。これを単体で有効にすると、そのフィルターを実際に使用しているタイル、つまりフィルターを変数として参照しているタイルと、そこからブロードキャストされた値を受け取っているタイルがブロックされます。デモでは、logs と traces の両方のログソースにブロードキャストされる service name フィルターがダッシュボード上のすべてのタイルをブロックし、logs テーブルにのみ存在する severity フィルターはログのタイルのみをブロックして、トレースのタイルは従来どおり読み込まれました。
2つ目のオプションを使うと、タイルがそのフィルターを変数として使用しているか、ブロードキャスト値を受け取っているかにかかわらず、ダッシュボード上のすべてのタイルに必須条件が適用されます。内部的には、各フィルタータイプに2つのフィールドが追加されています。値が 1 の場合に必須を意味する
minSelections と、ダッシュボード全体へ適用するための isGlobalRequirement です。minSelections をブール値ではなく数値にしているのは、対応する maxSelections の上限や 1 を超える最小値を、将来的に利用できるようにするためです。
依存フィルターは、依存先の必須フィルターによってはまだブロックされません。そのため、オプションのクエリが必須変数を参照しているフィルターは、その変数に値が設定される前にオプションのクエリを実行します。
必須フィルターの PR のレビュー時に Brandon から提案されたとおり、ダッシュボードのフィルターおよび変数の選択が、タイルエディター内のチャートプレビューにも適用されるようになりました。従来は変数とコアフィルターはプレビューに反映される一方でブロードキャストフィルターは反映されず、動作に一貫性がありませんでした。また、必須フィルターが導入された今、ダッシュボードで適用されるものと同じフィルターでタイルを編集することには、パフォーマンス上の利点もあります。Apply filters トグルはデフォルトで有効で、オフにすればタイルを両方の状態で確認できます。
タイルに alert が設定されている場合、このトグルは強制的にオフになります。alert はフィルターを一切適用せずに評価されるためです。これにより、プレビューが alert が実際にクエリする内容と一致します。
必須フィルターによってプレビューがブロックされている場合、タイルエディターに表示されるメッセージで、ブロックを解除する手段として Apply filters をオフにすることが案内されます。
関連 PR: #3078 ダッシュボードフィルターを必須として設定できるようサポート、#3093 ダッシュボードフィルターをタイルエディターのプレビューに任意で適用、#3098 getBlockingRequiredFilterNames を追加し、タイルエディターのブロック時メッセージを更新
検索ページでのライブクエリ進捗
デモ提供: @wrn14897
これまでは、検索に時間がかかると、その間ずっと進捗の分からないスピナーが表示されるだけでした。ClickHouse が範囲の 5% まで進んでいるのか 95% なのか、そもそも何か処理をしているのかすら分からない。ログソースの主キーがクエリに適していない場合には、まさにこの状況に陥ります。今回、結果テーブルのフッターと、ヒストグラムのスキャン行数・経過時間のストリップに、ClickHouse 自身の進捗カウンターが表示されるようになりました。クエリの実行時間、スキャンされた行数、そして進捗率です。クエリのストリーミング中に ClickHouse CLI が表示する内容に近いものです。
進捗は
JSONEachRowWithProgress フォーマットから取得されます。このフォーマットでは、レスポンスボディ内で {"progress":...} 行が行データと交互に出力されます。ヘッダーを使う方法は行き詰まりでした。ClickHouse はボディの送信が始まると X-ClickHouse-Progress の出力を停止しますし、そもそも fetch() ではヘッダーを逐次取得できません。このフォーマットには ClickHouse 25.1 以降が必要なため、報告されたサーバーバージョンに基づいて接続ごとに選択され、それより古いサーバーや不明なサーバーでは既存の非ストリーミング経路が使われます。
検索ページは範囲全体を一度に取得するのではなく、時間ウィンドウを 1 つずつ取得します。そのため 1 週間分の検索は日単位で実行され、十分な行数が得られた時点で停止します。進捗はウィンドウ全体のセットに対して計算され、ウィンドウ間のギャップをまたいでも意図的に維持されます。その境界で進捗をクリアしてしまうと、バーが消えて経過時間タイマーがウィンドウごとにリセットされ、1 か月分の範囲では何十回も繰り返されてしまうためです。各ウィンドウは読み取りを開始する前に 0% で実行中として登録されるため、開いたばかりのウィンドウにその範囲全体の進捗が計上されることはありません。
これはメインの検索ページ限定の動作です。ライブテール中は、クエリが数秒ごとに再取得されバーがちらつくだけになるため、非表示になります。最初のウィンドウが短いため、すぐに LIMIT に達する検索では、バーが消える前に一瞬およそ 0% と表示されます。
ストリーミングされるのは進捗であって、結果ではありません。行は依然としてウィンドウ単位で届きます。スキャンされた順に行を返すには ClickHouse 側でのストリーミングサポートが必要で、通話で Jordan が質問していたとおり、現在対応が進められています。その間に挟まる proxy がさらに複雑さを加えるため、まだ実装には至っていません。
このチャンク分割には、フィードバックで挙がった関連する課題があります。ヒストグラムは chunk ごとに埋まっていきますが、まだクエリ実行中のウィンドウと、データが返らなかったウィンドウを区別する手段がなく、チャート自体にも何らかの進捗表示があると役立ちます。これは今回の変更とは別のコード部分に関わる話です。
関連 PR: #3103 検索中に ClickHouse クエリの進捗をライブ表示する (オープン) 。バーが対象とする日単位の検索ウィンドウ分割は以前からの実装であり、今回の変更には含まれません。インクリメンタルな検索ウィンドウは #1125、チャートのチャンク分割は #1233 で導入されました。