필수 대시보드 필터
데모 제공: @pulpdrew
이제 대시보드 필터를 필수로 지정할 수 있으며, 값이 선택되기 전까지는 tile이 로드되지 않습니다. 이전에는 모든 필터가 선택 사항이어서, 대규모 source 위에 구성된 대시보드를 열면 아무것도 좁히기 전에 모든 tile이 필터 없이 실행되었습니다.
필터 정의에 Required toggle이 새로 추가되었습니다. 이 옵션만 켜면 해당 필터를 실제로 사용하는 tile, 즉 필터를 변수로 참조하는 tile과 필터로부터 broadcast 값을 전달받는 tile이 차단됩니다. 데모에서는 logs와 traces source 양쪽에 broadcast되는 서비스 이름 필터가 대시보드의 모든 tile을 차단한 반면, logs 테이블에만 존재하는 심각도 필터는 log tile만 차단하고 trace tile은 이전과 동일하게 로드되도록 두었습니다.
두 번째 옵션은 tile이 해당 필터를 변수로 사용하는지, broadcast 값을 전달받는지와 관계없이 대시보드의 모든 tile로 이 요구 사항을 확장합니다. 내부적으로 각 필터 유형에는 두 개의 필드가 추가되었습니다. 값이 1이면 필수를 의미하는
minSelections와, 대시보드 전체 적용 버전을 위한 isGlobalRequirement입니다. minSelections를 boolean이 아니라 숫자로 둔 것은, 이후에 짝이 되는 maxSelections 상한이나 1보다 큰 최솟값도 쓸 수 있도록 하기 위함입니다.
종속 필터는 아직 자신이 의존하는 필수 필터에 의해 차단되지 않습니다. 따라서 옵션 쿼리가 필수 변수를 참조하는 필터는 해당 변수에 값이 지정되기 전에도 옵션을 쿼리합니다.
또한 이제 대시보드 필터 및 변수 선택 값이 tile 편집기의 chart 미리보기에도 적용됩니다. Brandon이 필수 필터 PR을 검토하면서 제안한 사항입니다. 이전에는 변수와 핵심 필터만 미리보기로 전파되고 broadcast 필터는 전파되지 않아 일관성이 없었으며, 필수 필터가 도입된 지금은 대시보드가 적용하는 것과 동일한 필터로 tile을 편집하는 편이 성능 면에서도 유리합니다. Apply filters toggle은 기본적으로 켜져 있으며, 이를 끄면 두 가지 방식 모두로 tile을 확인할 수 있습니다.
tile에 알림이 구성되어 있으면 이 toggle은 강제로 꺼집니다. 알림은 어떤 필터도 적용하지 않은 상태로 평가되기 때문입니다. 이렇게 하면 미리보기가 알림이 실제로 실행할 쿼리와 일치하게 됩니다.
필수 필터가 미리보기를 차단하는 경우, 이제 tile 편집기의 메시지는 차단을 해제하는 방법으로 Apply filters를 끄도록 안내합니다.
관련 PR: #3078 Support configuring dashboard filters as required, #3093 Optionally apply dashboard filters to tile editor preview, #3098 Add getBlockingRequiredFilterNames, update tile editor blocked copy
검색 페이지의 실시간 쿼리 진행률
데모 제공: @wrn14897
이전에는 검색이 느릴 때 그 시간 내내 아무 정보도 주지 않는 스피너만 표시되었습니다. ClickHouse가 특정 구간을 5% 처리했는지 95% 처리했는지, 애초에 무언가 진행하고 있는지조차 알 수 없었는데, 이는 소스의 primary key가 해당 쿼리에 적합하지 않을 때 겪게 되는 바로 그 상황입니다. 이제 결과 테이블의 footer와 histogram의 스캔된 행 수 및 경과 시간 표시 영역에 ClickHouse 자체의 progress 카운터가 표시됩니다. 즉 쿼리가 얼마나 오래 실행되었는지, 몇 개의 행이 스캔되었는지, 그리고 진행률(%)을 확인할 수 있습니다. 쿼리가 스트리밍되는 동안 ClickHouse CLI가 보여주는 정보와 거의 동일합니다.
진행률은
JSONEachRowWithProgress 포맷에서 가져오며, 이 포맷은 response body에서 {"progress":...} 형태의 줄을 행과 번갈아 내보냅니다. header 방식은 막다른 길이었습니다. ClickHouse는 body 전송이 시작되면 X-ClickHouse-Progress 전송을 중단하며, 애초에 fetch()로는 header를 점진적으로 읽을 수도 없습니다. 이 포맷은 ClickHouse 25.1 이상이 필요하므로, 보고된 server version을 기준으로 connection마다 선택되고, 그보다 낮은 버전이거나 알 수 없는 서버는 기존의 비스트리밍 경로를 계속 사용합니다.
검색 페이지는 전체 구간을 한 번에 조회하지 않고 time window를 하나씩 가져오므로, 일주일 범위의 검색은 하루 단위로 실행되며 충분한 행이 확보되면 중단됩니다. 진행률은 전체 window 집합을 기준으로 계산되며, window 사이의 간격에서도 의도적으로 유지됩니다. 해당 경계에서 진행률을 초기화해 보니 진행 바가 사라지고 경과 시간 타이머가 window마다 다시 시작되었고, 한 달 범위에서는 이런 일이 수십 번 반복되었기 때문입니다. 각 window는 데이터를 읽기 시작하기 전에 0% 상태로 진행 중임을 등록하므로, 방금 시작된 window가 자신의 전체 구간을 처리한 것으로 반영되지 않습니다.
이 기능은 메인 검색 페이지에만 적용됩니다. 라이브 테일 중에는 쿼리가 몇 초마다 다시 실행되어 진행 바가 깜빡이기만 하므로 숨겨집니다. 첫 window가 짧기 때문에, LIMIT을 즉시 채우는 검색에서는 진행 바가 사라지기 전 약 0%가 잠깐 표시됩니다.
스트리밍되는 것은 진행률이며, 결과가 아닙니다. 행은 여전히 window 단위로 도착하며, 스캔되는 대로 행을 반환하려면 ClickHouse 측의 스트리밍 지원이 필요합니다. 이는 통화에서 Jordan이 문의한 대로 현재 작업이 진행 중입니다. 중간에 위치한 프록시가 여기에 복잡성을 더하기 때문에 아직 구현되지는 않았습니다.
청크 방식에는 피드백으로 제기된 관련 미비점이 있습니다. histogram이 청크 단위로 채워지는 동안, 아직 쿼리가 진행 중인 window와 데이터가 없어 결과가 비어 있는 window를 구분할 수 없으며, chart 자체에 진행 상황을 표시하면 도움이 될 것입니다. 이는 이번 변경과는 다른 코드 영역에 해당합니다.
관련 PR: #3103 검색 중 실시간 ClickHouse 쿼리 진행률 표시(open). 진행 바가 기준으로 삼는 일 단위 검색 windowing은 이전에 수행된 작업으로 이번 변경에 포함되지 않습니다. 증분 검색 window는 #1125에서, chart 청크 처리는 #1233에서 도입되었습니다.