Переменные панели мониторинга
Переменные панели мониторинга — главное изменение этой недели. Они основаны на модели фильтров, уже используемой панелями мониторинга: любой существующий или новый фильтр можно сделать доступным в виде переменной.
По умолчанию переменная использует отображаемое имя фильтра. Если это имя содержит специальные символы или два фильтра имеют одинаковое отображаемое имя, можно задать пользовательское имя переменной. Оно остается неизменным, даже если впоследствии фильтр будет переименован. На странице конфигурации указано имя, которое нужно использовать в ссылках, а после включения переменной оно также отображается во всплывающей подсказке фильтра.
Диаграммы Raw SQL поддерживают несколько способов использования переменных.
$__filter($var) разворачивается в текущее выбранное значение одной переменной. Это аналог существующего макроса $__filters для одной переменной, который разворачивается во все фильтры.
Более интересное дополнение — $__conditionalAll(condition, $var). Его первый аргумент — условие, а второй — переменная. Если для переменной выбрано значение, условие включается в запрос. Если значение не выбрано, всё выражение преобразуется в 1 = 1 и не влияет на фильтрацию.
Это позволяет выполнять сопоставления между источниками. Панель мониторинга может сопоставлять коды статуса трассировки со значениями error или info, чтобы фильтр уровня серьезности, определенный для таблицы логов, мог фильтровать таблицу трассировок. Выберите error на уровне панели мониторинга, и запрос трассировок будет отфильтрован по статусу ошибки.
Автодополнение предлагает все доступные переменные и поддерживаемые ими форматы. По предложению Brandon теперь оно прямо в строке показывает результат разворачивания с учетом текущего выбранного значения. Предложения макросов также включают результаты их разворачивания, а новый раздел документации объясняет назначение каждого макроса. Проверка выявляет ссылки на несуществующие переменные и вызовы макросов с неверными аргументами.
Диаграммы в конструкторе используют ту же подстановку переменных в большинстве редактируемых полей — как для SQL, так и для Lucene. Переменные работают в WHERE, GROUP BY, HAVING и ORDER BY, с теми же автодополнением и проверкой. Поля Lucene поддерживают переменные, но не макросы. Поля конструктора SQL предлагают макросы, связанные с переменными, а не полный набор, доступный в Raw SQL.
Для оповещений действует одно строгое правило: каждая переменная вычисляется с пустым значением. Если запрос оповещения ссылается на переменные, редактор предупредит об этом перед сохранением. Предварительный просмотр и сгенерированный SQL показывают разворачивание с пустыми значениями, в том числе на странице сведений об оповещении, а задача оповещения применяет эти пустые значения при выполнении.
Конфигурация переменных по-прежнему скрыта за флагом NEXT_PUBLIC_ENABLE_DASHBOARD_VARIABLES. Если переменные не настроены, поведение панели мониторинга не изменяется.
Связанные PR: #2836 добавление конфигурации переменных фильтра, #2873 подстановка переменных в диаграммах Raw SQL, #2874 автодополнение и проверка переменных панели мониторинга в SQL, #2901 поддержка переменных панели мониторинга в плитках конструктора диаграмм, #2910 разворачивание переменных в пустые значения в запросах оповещений, #2923 поддержка запросов значений зависимых переменных, #2937 поддержка вложенных макросов и ссылок на переменные в макросах, #2944 добавление переменных панели мониторинга во внешний API
Страница сведений об оповещении с историей проверок
До сих пор оповещение отображало лишь полосу истории и почти ничего больше. Если вы хотели понять, что именно делает оповещение, изучать было практически нечего.
На новой странице сведений отображаются все проверки. Для сгруппированных оповещений она показывает, какая группа сработала и какое значение превысило порог. Каждая запись также содержит длительность запроса к ClickHouse, а рядом доступна конфигурация оповещения.
Столбец дозагруженных бакетов требует пояснения. Если проверка была пропущена, при следующем запуске пробел заполняется обработкой отсутствующего бакета. Поэтому наличие дозагруженных бакетов означает, что оповещение отстаёт от расписания. Медленный запрос к ClickHouse теперь оставляет заметный след, а не незаметно задерживает последующие проверки.
Маркеры на диаграмме выравниваются по началу проверяемого бакета, поэтому легче увидеть, когда оповещение сработало и когда вернулось в состояние OK.
Также можно редактировать или удалять оповещение непосредственно на странице сведений. Не нужно возвращаться к модальному окну сохранённого поиска или редактору плитки панели мониторинга. Возможность перенести на эту страницу больше настроек оповещения всё ещё прорабатывается.
Страница по-прежнему доступна за флагом
NEXT_PUBLIC_ENABLE_ALERT_DETAILS.
Связанные PR: #2833 модель чтения проверок оповещения и GET /alerts/:id/evaluations, #2834 сохранение ошибок проверок оповещения и аналитики в AlertHistory, #2835 страница сведений об оповещении с историей проверок, #2928 выравнивание маркеров диаграммы оповещения по началу проверяемого бакета, #2931 редактирование и удаление оповещений со страницы сведений об оповещении
Расследование оповещений и аннотации инструментов MCP
Для сработавших оповещений теперь доступна кнопка Investigate. Нажатие на неё запускает расследование в notebook со страницы оповещений или со страницы сведений об оповещении.
Конечная цель — автоматически запускать такие расследования при срабатывании оповещения. Кнопка — полезный промежуточный шаг, а не конечный вариант.
Все инструменты на MCP-сервере ClickStack теперь также содержат подсказки в аннотациях. Ранее сервер не сообщал, какой инструмент предназначен только для чтения, а какой изменяет или удаляет данные.
Добавление
readOnlyHint и destructiveHint даёт клиентам достаточно информации, чтобы по-разному обрабатывать эти инструменты. Операции чтения могут выполняться без прерываний, а деструктивные действия — ожидать явного подтверждения. Удаление оповещения — очевидный пример: перед этим у вас должны запросить подтверждение.
Последнее изменение влияет на первоначальный выбор инструментов агентами. Использование clickstack_sql росло по мере расширения набора инструментов без чёткой политики выбора. Агенты обращались к Raw SQL, даже когда инструменты построения запросов подходили лучше.
Это важно не только для корректности запросов. Raw SQL создаёт статические плитки с результатами. Инструменты построения запросов — clickstack_table, clickstack_timeseries и clickstack_search — создают плитки, которые можно открыть и использовать для pivot-анализа.
Теперь MCP сначала направляет агентов к этим инструментам построения запросов, оставляя Raw SQL для запросов, которые они действительно не могут выразить. После изменения оценки Eval заметно улучшились.
Связанные PR: #2838 добавляет аннотации инструментов MCP (readOnlyHint и т. д.) для всех инструментов, #2840 направляет агентов к инструментам построения запросов вместо Raw SQL, #2870 направляет агентов панели мониторинга к фильтрам плиток для каждой серии. У самой кнопки Investigate нет публичного PR, на который можно сослаться.
Диаграммы метрик с несколькими сериями в одном запросе
Раньше для отображения нескольких метрик на одной диаграмме требовалось выполнять отдельный запрос к ClickHouse для каждой серии, а затем объединять результирующие наборы в Node или браузере. Диаграмма с N сериями порождала N запросов.
Теперь диаграммы с несколькими сериями компилируются в один SQL-запрос. Каждая серия становится CTE, а в конце ClickHouse объединяет их. То же относится и к отношениям: обе серии формируются в одном запросе, а отношение вычисляется в финальной проекции.
Главное преимущество — меньше запросов. Такая форма запроса также закладывает основу для формул метрик. Для формулы все серии должны быть доступны как столбцы в одном отношении, чтобы её можно было выразить в финальном
SELECT. Именно это теперь создаёт компилятор, и работа над формулами уже ведётся.
Это изменение выявило одну регрессию. Плитки с несколькими сериями не отображались, если в них использовались агрегации, возвращающие числа с плавающей точкой и целые числа. Для её воспроизведения было достаточно сочетания гистограммных quantile, возвращающего Float64, и count, возвращающего Int64.
Составные UNION ALL и pivot пропускали все серии через один и тот же столбец, из-за чего ClickHouse расширял тип до Variant(Float64, Int64). Этот случай исправлен.
Связанные PR: #2858 расширение тестового покрытия целых чисел для объединения метрик с несколькими сериями, #2859 перенос вычисления объединения метрик с несколькими сериями в ClickHouse, #2907 покрытие alert-task для плиток метрик с несколькими сериями, #2916 исправление диаграмм метрик с несколькими сериями, смешивающих агрегации float и int, #2872 модель выражений формул, #2908 отображение формул в составном запросе метрик, #2909 интерфейс редактора диаграмм для формул метрик
Исправления автодополнения Lucene и требований к паролю
Тестирование переменных панели мониторинга выявило отдельную регрессию: автодополнение Lucene незаметно перестало работать почти везде. Единственным местом, где оно всё ещё работало, оставалась страница поиска.
Другое изменение касается страницы Join Team, где приглашённые пользователи задают пароль. На странице не отображались требования к паролю, хотя backend их применял. При вводе недопустимого пароля появлялось общее сообщение «Недопустимый пароль», и пользователю приходилось самому догадываться о требованиях.
Теперь эти требования отображаются. Проверка общего компонента, который их выводит, также выявила два расхождения с backend: в отношении учитываемых специальных символов и максимальной длины пароля. Оба исправлены.
Связанные PR: #2902 восстанавливает автодополнение Lucene, #2904 отображает требования к паролю на странице Join Team