Переменные панели мониторинга в PromQL и Lucene
Демо от @pulpdrew
Переменные панели мониторинга теперь работают в графиках PromQL: доступны автодополнение ссылок на переменные и предупреждения об отсутствующих переменных или неподдерживаемом использовании — например, о макросах или ссылках, которым нужны кавычки. Рядом с уже привычной панелью сгенерированного SQL появился предпросмотр сгенерированного PromQL: он показывает запрос с подставленными текущими значениями.
Переменные Lucene теперь поддерживают точное совпадение. Раньше
ServiceName:$service раскрывалось в ServiceName:("add" OR "cart"). Совпадение поля Lucene без кавычек — это поиск подстроки, поэтому в итоге получалось ServiceName ILIKE '%add%' OR ServiceName ILIKE '%cart%'. Можно было выбрать два сервиса, а получить четыре.
Если взять переменную в кавычки — ServiceName:"$service" — теперь она раскрывается в (ServiceName:"add" OR ServiceName:"cart"), точно сопоставляя каждое выбранное значение. Это соответствует существующему поведению для совпадений полей в кавычках без переменных. Автодополнение также предлагает вариант с кавычками.
Переход из tooltip графика или строки таблицы на страницу поиска теперь раскрывает переменные и макросы ещё до навигации. Страница поиска не понимает переменные, поэтому передача необработанного $service раньше приводила к некорректным результатам или ошибке запроса. Макросы без выбранных значений раскрываются в (1=1). В поле WHERE на странице поиска это выглядит не слишком красиво, зато запрос остаётся корректным.
Выбранные значения фильтров теперь привязаны к имени переменной, а не к выражению. Два фильтра с одинаковым выражением — например, ServiceName из разных источников — больше не используют общий выбор.
Нажатие Escape при редактировании фильтра теперь запрашивает подтверждение перед отменой изменений, как предложил Brandon. Раньше попытка закрыть tooltip могла привести к потере всех правок.
Переменные панели мониторинга на этой неделе вышли в продакшн. Переключатель возможности удалён, а публичная документация описывает формы ссылок и макросы.
Связанные PR: #2994 подстановка переменных в графиках PromQL, #2995 добавление автодополнения для переменных PromQL, #2997 вывод предупреждений о некорректном использовании переменных PromQL, #2998 добавление предпросмотра сгенерированного PromQL, #2987 распределение ссылок на переменные Lucene с точным совпадением, #3008 раскрытие переменных перед переходом на страницу поиска через drill-down, #2963 приём значений фильтров панели мониторинга, привязанных к переменным, #2964 сохранение и чтение состояния фильтров, привязанного к переменным, #3005 подтверждение отмены несохранённых изменений при закрытии редактора фильтров, #3009 удаление переключателя возможности переменных панели мониторинга
Span links, в обоих направлениях
Демо от @karl-power
Span links можно было просматривать уже давно, но только со стороны consumer. Каждая ссылка отображалась как действие «Open trace», и начать с producer span, чтобы найти ссылающиеся на него spans, было невозможно. Один из пользователей попросил об этом в issue на GitHub.
Раздел Span Links теперь показывает имя целевого span, service, duration и timestamp. Это упрощает выбор между несколькими ссылками — не нужно открывать каждую из них. «Open trace» остаётся запасным вариантом (fallback), если целевой span найти не удаётся.
Новый раздел «Linked from» перечисляет spans, которые ссылаются на текущий span. Теперь можно перейти по ссылке от consumer к его producer и увидеть там consumer в списке.
Переход по ссылке на предыдущий span в цепочке навигации возвращает вас к уже существующей записи, поэтому перемещение между двумя связанными spans не плодит дубликаты. Если между ними есть другие записи, навигация добавляет новую запись как обычно.
Обратный поиск находит rows, в span links которых содержится выбранный span ID, а затем проверяет совпадение trace ID. Поиску по trace ID помогает индекс bloom filter по этому столбцу, а вот обратный поиск требует scan и на более крупных таблицах traces может работать медленнее, чем в демо. Если это станет проблемой, мы сможем добавить индекс по span ID ссылки, как и предлагается в комментариях к коду.
Связанные PR: #3011 добавлены обратные span links, отображение деталей span link
Обсервабилити LLM «из коробки»
Демо от @wrn14897
Многие команды уже отправляют в ClickStack телеметрию LLM и кодовых агентов, но специальной поддержки для неё не было: ни отображения диалогов, ни учёта токенов и затрат, ни аналитики по моделям.
Теперь наряду с существующими преднастройками для ClickHouse, Kubernetes и сервисов появилась панель мониторинга LLM. Она охватывает расход токенов, стоимость, вызовы моделей, вызовы инструментов, попадания в кэш и время ответа, а также разбивку по пользователям, если присутствует соответствующий атрибут.
Она читает ваши существующие traces и журналы во время выполнения запроса и не требует фиксированной схемы, отдельных таблиц или обработки на этапе приёма. Поддерживается телеметрия, использующая распространённые соглашения, OpenLLMetry или OpenInference, включая данные из SDK OpenAI и Anthropic, Vercel AI SDK, LangChain, Claude Code и opencode. Это работает и с уже собранной вами телеметрией.
Представление latency выводит наверх spans, связанные с ИИ, — так проще найти медленный вызов модели, не разбирая остальную часть trace.
Представление сеансов группирует spans по диалогам. Откройте сеанс, чтобы увидеть его spans, затем выберите один из них и посмотрите подробности, включая промпт, если он был записан. Это помогает при отладке работы агента, а по тому же фильтру сеанса можно искать и журналы.
Охват намеренно уже, чем у специализированных инструментов обсервабилити LLM, таких как Langfuse, который поддерживает также оценки и многое другое. Здесь закрываются типовые потребности мониторинга: доля ошибок, стоимость, токены и latency — на основе телеметрии, которая уже есть в ClickStack.
Связанные PR: #2990 панель мониторинга обсервабилити LLM, представление диалогов по spans и сеансы
Просмотр метрик в редакторе графиков
Демо от @MikeShi42
Раньше выбор метрики сводился к поиску по плоскому списку, в котором на каждый тип приходилось до 3000 имён. Автодополнение выручает, если вы примерно знаете, что ищете, но в отзывах нам неоднократно просили добавить возможность просматривать каталог.
Теперь рядом с полем выбора метрики есть элемент управления «Browse metrics», который открывает обозреватель: каталог слева, подробности о выбранной метрике справа. Имена метрик разбиваются по точкам и подчёркиваниям, формируя дерево. Сегменты с единственным дочерним элементом объединяются, чтобы не делать лишних щелчков. Столбцы
Metric, Type и Unit выровнены на всех уровнях. Искать можно по всему каталогу либо переключиться на плоский список.
Ранее единица измерения, описание и теги становились доступны только после выбора метрики — в свёрнутой панели под строкой серии. Панель подробностей позволяет изучить их ещё до выбора, так что вы сразу видите, что именно отдаёт ваше развертывание и по каким тегам можно группировать. Нажмите «Use metric», чтобы применить выбор к редактируемой серии.
Пока функция намеренно убрана на второй план — ей нужно время, чтобы устояться.
Связанные PR: #3000 добавление обозревателя метрик в редактор графиков, #3025 потоковая передача имён метрик из основного индекса (открыт), #3054 улучшения UX в выпадающем списке метрик
Объём журналов для запросов на raw SQL в Grafana
Демо от @SpencerTorres
Небольшое визуальное изменение, которое потребовало больше работы, чем ожидалось.
В Grafana для запросов к журналам, построенных в query builder, над результатами отображается гистограмма объёма — plugin знает, какие столбцы использовать. У того же запроса в редакторе SQL гистограммы не было: plugin не мог определить, какие столбцы вы выбрали. В Explore вместо неё показывалась гистограмма Grafana по строкам, ограниченная
LIMIT запроса и не учитывающая выбранный диапазон времени.
Теперь plugin отбрасывает завершающие ORDER BY и LIMIT, оборачивает ваш SQL в производную таблицу и агрегирует данные по всему диапазону времени. Удаление LIMIT здесь принципиально: если его оставить, подсчёт будет ограничен строками, которые вернул исходный запрос.
Гистограмма отражает фильтры вашего SQL и обновляется при изменении диапазона времени. Это работает как для SQL, написанного вручную, так и для запросов, открытых через «Edit as SQL» в query builder.
Вероятно, остаются пограничные случаи, в которых переписывание запроса не сработает.
Связанные PR: grafana/clickhouse-datasource#2141 отображение объёма журналов для запросов из редактора SQL (открыт)
Каналы уведомлений на страницах алертов
Демо от @jordan-simonovski
Алерт может отправлять уведомления в десять вебхуков, однако в списке алертов и в заголовке детальной страницы отображался только первый из них — с подписью «Webhook» вместо собственного имени. И там, и там по-прежнему считывалось устаревшее поле с одним каналом.
Отправка сразу нескольким адресатам работала, но из-за такого отображения складывалось впечатление, что дополнительные каналы не сохранились.
Теперь и в списке, и в заголовке детальной страницы каждый настроенный канал отображается по имени. Добавлять и удалять каналы тоже стало проще — в том числе вебхуки и интеграции с incident.io. Время уведомления фиксируется отдельно для каждого адресата, так что медленную интеграцию можно легко выявить.
Настроенные каналы теперь уведомляются напрямую. Раньше они преобразовывались в упоминания вебхуков и добавлялись в тело сообщения. Из-за этого уведомления могли теряться: если в теле сообщения уже было достаточно произвольных упоминаний, чтобы достичь лимита на событие, настроенные каналы алерта пропускались.
С появлением дополнительных элементов управления страница стала перегруженной. Действия для строк, включая экспорт и Terraform, теперь собраны в одном меню.
Связанные PR: #3001 отображение всех адресатов уведомлений на страницах алертов, #2991 отображение всех каналов уведомлений в сводной строке, #2984 уведомление настроенных каналов напрямую, а не через строки упоминаний, #2961 неудачные упоминания больше не расходуют слоты уведомлений, #3003 привязка времени уведомления алерта к каждому адресату, #3002 одинаковые управляющие элементы в конце каждой строки на странице алертов, #3016 объединение заголовка детальной страницы алерта с общим меню строки
Отрисовка десятков тысяч алертов
Демо от @pulpdrew
Вычисление алертов протестировано на 16 000 одновременных алертов и работает стабильно. А вот открытие страницы алертов при таком их количестве приводило к сбою.
Теперь список виртуализирован и способен отрисовать 16 000 алертов. Загрузка по-прежнему медленная, поскольку все алерты запрашиваются и фильтруются на стороне клиента. Чтобы это исправить, ведётся работа над постраничной навигацией.
Изменение также включает скрипт для наполнения и очистки большого числа алертов в MongoDB — это упрощает локальное тестирование страницы в таком масштабе.
Связанные PR: #3012 виртуализация списка на странице алертов
Скрытие ключей API за кнопкой показа
Демо от @brandon-pereira
Учётные данные отображались в приложении открытым текстом. На странице Team Settings был виден полный ключ API для приёма данных, а во фрагментах команд установки MCP присутствовал персональный ключ доступа. И то, и другое легко случайно раскрыть при демонстрации экрана или на скриншоте.
Теперь ключи по умолчанию замаскированы, а при необходимости их можно показать с помощью отдельного элемента управления. За это отвечает общий компонент — он используется для ключа приёма данных, персонального ключа доступа и фрагментов установки MCP, включая добавленные сообществом.
При копировании по-прежнему подставляется реальное значение, поэтому раскрывать ключ, чтобы его скопировать, не нужно. Такое же изменение готовится для онбординга в ClickStack Cloud.
Связанные PR: #2988 — маскирование секретов в ключе API и фрагментах установки MCP с помощью общего компонента RevealSnippet
Заметки о релизе в продукте
Демо от @jordan-simonovski
Панель «What’s new» в меню Help строилась на наборах изменений по каждому PR и отбирала записи с префиксом
feat:. Из-за этого в версии v2.36.0 переменные панели мониторинга были перечислены трижды, а формулы и работа над алертом — основные изменения релиза — в список вообще не попали.
Теперь панель читает корневой файл CHANGELOG.md, который пишется и проверяется в рамках релизного PR. Генератор релизов также передаёт в панель заголовок каждого релиза. Ниже располагаются breaking changes, новые возможности, исправления ошибок и улучшения со ссылками на changelog.
Кнопка Help теперь мерцает при наличии непрочитанных заметок о релизе — за это отвечает анимированный SVG без JavaScript.
Отслеживание непрочитанного тоже пришлось исправить. Оно опиралось на версию сборки приложения, поэтому при развертываниях, включавших короткий git SHA или номер сборки CI, мерцание срабатывало на каждом развертывании, даже если нового релиза не было. Теперь берётся последняя версия релиза из changelog.
Формат заметок о релизе тоже меняется, так что в панели будет появляться всё больше такого содержимого.
Связанные PR: #2993 формирование «What’s new» на основе сгенерированных заметок о релизе, #3042 привязка мерцания «What’s new» к релизу, а не к сборке, #3007 отдельное предупреждение при сбое запроса маркера релиза