Обязательные фильтры панели мониторинга
Демо от @pulpdrew
Фильтры панели мониторинга теперь можно помечать как обязательные, чтобы плитки не загружались, пока для них не выбрано значение. Раньше все фильтры были необязательными, и при открытии панели мониторинга, построенной на крупном источнике, все её плитки выполнялись без фильтрации ещё до того, как вы успевали сузить выборку.
В определении фильтра появился новый переключатель Required. Сам по себе он блокирует только те плитки, которые действительно используют фильтр: те, что ссылаются на него как на переменную, и те, что получают от него широковещательное значение. В демонстрации фильтр по имени сервиса, распространяемый сразу на источники журналов и трассировок, заблокировал все плитки панели мониторинга, а фильтр по уровню важности, существующий только в таблице журналов, заблокировал плитки журналов, оставив плитки трассировок загружаться, как раньше.
Второй параметр распространяет это требование на все плитки панели мониторинга — независимо от того, использует ли плитка фильтр как переменную и получает ли от него широковещательное значение. Внутри у каждого типа фильтра появились два поля:
minSelections, где значение 1 означает обязательность, и isGlobalRequirement для варианта, действующего на всю панель мониторинга. minSelections — это число, а не булевое значение, чтобы в дальнейшем можно было добавить парный ограничитель maxSelections и минимумы больше 1.
Зависимые фильтры пока не блокируются обязательными фильтрами, от которых они зависят, поэтому фильтр, чей запрос вариантов ссылается на обязательную переменную, всё равно запрашивает свои варианты до того, как у этой переменной появится значение.
Выбранные значения фильтров и переменных панели мониторинга теперь применяются и к предпросмотру графика в редакторе плитки — так предложил Brandon при рецензировании PR об обязательных фильтрах. Раньше переменные и основные фильтры передавались в предпросмотр, а широковещательные фильтры — нет, что было непоследовательно; к тому же с появлением обязательных фильтров есть аргумент производительности в пользу того, чтобы редактировать плитку с теми же фильтрами, которые применяет панель мониторинга. Переключатель Apply filters включён по умолчанию, и его можно отключить, чтобы увидеть плитку в обоих вариантах.
Переключатель принудительно отключается, если для плитки настроен alert, поскольку alerts вычисляются без применения каких-либо фильтров. Так предпросмотр соответствует тому, что alert действительно будет запрашивать.
Если обязательный фильтр блокирует предпросмотр, сообщение в редакторе плитки теперь подсказывает отключить 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 источника не подходит под запрос. Теперь нижний колонтитул таблицы результатов, а также полоса с числом просканированных строк и затраченным временем у гистограммы показывают собственные счётчики прогресса ClickHouse: как долго выполняется запрос, сколько строк просканировано и процент выполнения. Это близко к тому, что показывает ClickHouse CLI, пока запрос передаёт данные.
Прогресс приходит из формата
JSONEachRowWithProgress, который перемежает строки {"progress":...} со строками данных в теле ответа. Заголовки оказались тупиковым путём: ClickHouse перестаёт отправлять X-ClickHouse-Progress после начала передачи тела, а fetch() всё равно не умеет отдавать заголовки постепенно. Формат требует ClickHouse 25.1 или новее, поэтому он выбирается для каждого соединения на основе сообщённой версии сервера, а для более старых или неизвестных серверов сохраняется прежний непотоковый путь.
Страница поиска запрашивает по одному временному окну за раз, а не весь диапазон сразу, поэтому недельный поиск выполняется день за днём и останавливается, когда набрано достаточно строк. Прогресс рассчитывается по всему набору окон и намеренно сохраняется в промежутках между ними: сброс на этой границе приводил к тому, что полоса исчезала, а таймер затраченного времени перезапускался на каждом окне — десятки раз при диапазоне длиной в месяц. Окно регистрируется как выполняющееся с 0% ещё до начала чтения, так что только что открытому окну не зачисляется весь его диапазон.
Это работает только на основной странице поиска. В режиме live tail функция скрыта: там запрос повторяется каждые несколько секунд, и полоса лишь мерцала бы. Из-за короткого первого окна поиск, который сразу заполняет свой LIMIT, на мгновение показывает около 0%, а затем полоса исчезает.
Потоком передаётся прогресс, а не результаты. Строки по-прежнему приходят по одному окну за раз, а для их возврата по мере сканирования нужна поддержка потоковой передачи на стороне ClickHouse — над этим сейчас работают, о чём Jordan спрашивал на созвоне. Стоящий посередине proxy добавляет здесь свою порцию сложности, поэтому пока это не реализовано.
С разбиением на фрагменты связан ещё один пробел, о котором сообщили в отзывах: гистограмма заполняется фрагмент за фрагментом, но ничто не отличает окно, по которому запрос ещё выполняется, от окна, не вернувшего данных, — и какое-то отображение прогресса на самом chart было бы полезно. Но это относится к другой части кода, которую данное изменение не затрагивает.
Связанные PR: #3103 Отображение прогресса запроса к ClickHouse в реальном времени во время поиска (открыт). Разбиение поиска по дням, по которому отчитывается полоса, — более ранняя работа, и в это изменение она не входит; инкрементальные окна поиска были добавлены в #1125, а разбиение chart на фрагменты — в #1233.