> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Демо-дни — 2026-07-31
> Демо-дни ClickStack за 2026-07-31
## Метрики экспоненциальных гистограмм
*Демо от [@pulpdrew](https://github.com/pulpdrew)*
Добавлена начальная поддержка запросов к метрикам экспоненциальных гистограмм OpenTelemetry. Ранее можно было зарегистрировать такую метрику в источнике, но выполнять запросы к ней было невозможно. Теперь в конструкторе запросов поддерживаются подсчёты и квантили.
Экспоненциальные гистограммы похожи на гистограммы с явными бакетами, но границы их бакетов вычисляются как степени двойки, а не хранятся для каждого бакета. Масштаб определяет используемую степень двойки. Чем выше масштаб, тем меньше бакеты, а смещение сдвигает границы в сторону больших или меньших кратных. Счётчик бакета показывает, сколько наблюдений попадает в соответствующий диапазон.
Max, min, sum и avg по-прежнему не поддерживаются, как и в существующей реализации явных гистограмм. Эти поля необязательны в модели данных OpenTelemetry, поэтому мы не рассчитываем на их наличие.
Как показано в демо, сгенерированный SQL длинный и не слишком красивый. Он работает приемлемо и не исчерпывает память, но это лишь начальная функциональная поддержка. Следующий этап работы — производительность; уже ведётся работа над обновлённой схемой, которая должна значительно ускорить эти запросы.
Пока корректно отображается только тип визуализации «временной ряд». Это соответствует существующему типу метрик гистограмм.
**Связанные PR:** [#2687](https://github.com/hyperdxio/hyperdx/pull/2687) feat: Показывать метрики экспоненциальных гистограмм в раскрывающемся списке имён метрик, [#2697](https://github.com/hyperdxio/hyperdx/pull/2697) feat: Реализовать квантиль+сумму для метрик экспоненциальных гистограмм, [#2705](https://github.com/hyperdxio/hyperdx/pull/2705) feat: Поддерживать экспоненциальные гистограммы в MCP, [#2707](https://github.com/hyperdxio/hyperdx/pull/2707) fix: Поддерживать группировку агрегаций квантилей гистограмм по столбцам, не являющимся Attribute
## Проверка Raw SQL диаграмм
*Демо от [@pulpdrew](https://github.com/pulpdrew)*
Raw SQL диаграммы теперь предупреждают об отсутствии ожидаемых макросов. Это изменение появилось после обращения в поддержку: пользователь, создававший множество Raw SQL диаграмм, постоянно сталкивался с непонятными результатами.
Запросы панели мониторинга должны включать макросы фильтров и исходной таблицы. Диаграммы временных рядов также должны включать макросы диапазона времени и интервала. Ранее эти проверки выполнялись только после привязки alert к плитке. Теперь они выполняются для каждой Raw SQL диаграммы, поэтому при удалении макроса в редакторе появляется предупреждение, а не непонятная диаграмма позже.
Проверка также учитывает зависимости каждого макроса. Для макросов исходной таблицы и фильтров требуется выбрать источник, хотя в остальном Raw SQL диаграммам он не нужен. Поэтому использование любого из этих макросов без выбора источника приводит к ошибке, а не к предупреждению.
Это небольшое изменение, но оно должно упростить поиск проблем с Raw SQL без обращения в поддержку.
**Связанные PR:** [#2742](https://github.com/hyperdxio/hyperdx/pull/2742) feat: Предупреждение об отсутствующих params/macros в редакторе SQL
## Ссылки на источники по имени, а не по ID
*Демо от [@pulpdrew](https://github.com/pulpdrew)*
Команде LogHouse требовался более надёжный способ ссылаться на источники. Она управляет средой логирования ClickHouse Cloud и программно создаёт источники с помощью инфраструктуры как кода. ID источников меняются при повторном создании и различаются в средах разработки, промежуточного тестирования и продакшна, поэтому любые ссылки на основе ID ненадёжны. Поскольку команда переходит в ClickStack из систем оповещений и Grafana, поддерживать отдельные наборы ID источников для каждой среды было непрактично.
Параметр URL `source` теперь принимает не только ID, но и имя источника. Имена задаются при создании источников, поэтому одна и та же ссылка может работать в любой среде. Изначально поддержка была добавлена на страницу Search. Следующий PR расширяет её на все страницы с параметром источника, включая Chart Explorer, service map, сеансы, панель мониторинга сервисов и Kubernetes dashboard.
Большая часть дальнейшего обсуждения была посвящена обнаруживаемости этой возможности. По сути, это URL API, и пользователи вряд ли обнаружат его случайно. Один из вариантов — использовать имена вместо ID по умолчанию, хотя конфликты имён делают такой подход небезопасным. Среди других предложений — добавить ссылки через кнопку Share, генерировать их агентами через MCP и надлежащим образом задокументировать URL API. Та же документация была бы полезна и для относительных диапазонов времени.
Ссылки по имени также можно распространить на панели мониторинга. Тогда рабочий процесс инфраструктуры как кода сможет создавать источники, импортировать панели мониторинга и автоматически связывать всё между собой. При импорте панелей мониторинга через UI источники уже сопоставляются по имени, поэтому остаётся закрыть в основном лишь пробел в программных рабочих процессах.
**Связанные PR:** [#2746](https://github.com/hyperdxio/hyperdx/pull/2746) feat: Принимать имена источников наряду с ID в параметрах URL, [#2758](https://github.com/hyperdxio/hyperdx/pull/2758) feat: Поддержка глубоких ссылок по имени источника на дополнительных страницах
## Переработка настроек отображения диаграмм
*Демо от [@elizabetdev](https://github.com/elizabetdev)*
Ведётся работа над тем, где должны располагаться настройки отображения диаграмм. В первоначальном изменении их переместили непосредственно вправо от редактора плитки вместо того, чтобы открывать в отдельной выдвижной панели. Ранее редактор плитки был модальным окном, а Display Settings открывались в выдвижной панели поверх него. Однократное нажатие Escape закрывало оба окна, и выдвижная панель поверх модального окна никогда не казалась удачным решением.
PR усложнился, когда настройки серий тоже потребовалось разместить поверх, поэтому мы сделали шаг назад и начали рассматривать страницу в целом. Работа всё ещё находится на стадии каркаса. В текущем дизайне настройки размещены в закреплённой панели, а изменения применяются автоматически: результат виден в реальном времени без нажатия кнопки Apply.
Планируется завершить переработку, прежде чем вернуть её в существующий PR. То, что есть сейчас, рассматривается как прототип, в частности потому, что новый дизайн также меняет отдельные части страницы панели мониторинга.
**Связанные PR:** [#2721](https://github.com/hyperdxio/hyperdx/pull/2721) feat(dashboards): переместить редактор плитки в выдвижную панель с закреплённой панелью настроек
## Новая страница Explore
*Демо от [@elizabetdev](https://github.com/elizabetdev)*
Это ранняя концепция единой страницы Explore, которая со временем может заменить Search, сохранённые поиски и Chart Explorer, став единой точкой входа.
Подход к внедрению основан на опыте, полученном при переработке средства просмотра трассировок. Вместо того чтобы сразу менять интерфейс для всех, новая страница будет доступна за флагом возможности небольшой группе пользователей. В этот период мы сможем выявить и устранить проблемы, прежде чем внедрять её более широко. Если идея не сработает, она останется экспериментом и не будет выпущена. Это вполне приемлемый результат.
Страница начинается с выбора типа сигнала. При выборе трассировок, журналов или метрик остальной интерфейс адаптируется соответствующим образом. Например, при выборе журналов будут доступны представление списка, шаблоны событий, временные ряды и другие визуализации, которые сейчас есть в Chart Explorer.
Расследование должно продолжаться без переключения между страницами. Можно начать со списка, перейти к числовому или сгруппированному представлению таблицы, добавить результат на панель мониторинга, а затем написать пользовательский запрос, если потребуется больше контроля.
Здесь также предусмотрено несколько небольших идей, большинство из которых основано на отзывах пользователей. Редактор запросов будет работать больше как редактор SQL, устраняя текущие различия в поведении автодополнения. Ошибки и предупреждения будут появляться в процессе редактирования, а не только после выполнения запроса.
Для столбцов появится отдельный элемент выбора. По крайней мере один пользователь не понял, что изменение предложения `SELECT` определяет, какие столбцы отображаются в таблице. В элементе выбора щелчок по полю обновляет SQL и позволяет сортировать по этому полю. Предложение `SELECT` останется доступным для опытных пользователей.
Сохранённые представления также будут доступны на этой странице: можно будет исследовать данные без сохранения, а затем сохранить текущее представление прямо там. Сгенерированный SQL будет отображаться непосредственно в интерфейсе.
Многого ещё не хватает, включая некоторые визуализации, доступные сегодня в Chart Explorer. Дизайн будет и дальше меняться по мере добавления этих компонентов.
**Связанные PR:** пока нет, это исследование, а не выпущенная возможность
## Связывание фильтров панели мониторинга
*Демо от [@teeohhem](https://github.com/teeohhem)*
Добавлена функция связывания фильтров панели мониторинга. Впервые мы продемонстрировали ее в черновом варианте несколько месяцев назад, а затем приостановили работу, чтобы оценить влияние на производительность. Связывание меняет структуру запросов панели мониторинга и не всегда оптимально использует materialized views, поэтому оно будет доступно через переключатель, а не включено по умолчанию.
Когда связывание включено, выбор значения в одном фильтре сужает набор значений, доступных в остальных. При выборе сервиса остаются только значения уровня серьезности, доступные для этого сервиса. При выборе ID трассировки остаются только связанные ID родительских трассировок. Это не позволяет пользователям выбирать комбинации, для которых нет данных.
Следующий PR делает связывание зависимым от источника. Фильтры группируются по источникам, а между соседними фильтрами отображаются значки цепочки, показывающие, какие из них могут сужать набор значений друг друга. На панели мониторинга с двумя фильтрами логов и двумя фильтрами трассировок должно быть понятно, какие фильтры взаимодействуют.
Изначально эта функция предназначалась для панели мониторинга Kubernetes. При выборе пода должны остаться только развертывания и узлы, в которых есть этот под. Отфильтрованные значения загружаются по запросу при открытии выпадающего списка, что ограничивает затраты на дополнительные операции поиска.
В обсуждении остались два открытых вопроса. Сейчас настройка хранится отдельно для каждого пользователя в хранилище браузера. По итогам обсуждения ожидается, что со временем пользователи захотят сохранять ее на уровне панели мониторинга. Если так, пользовательскую настройку, возможно, лучше оставить временной, чтобы в дальнейшем она не конкурировала с поведением на уровне панели мониторинга.
Другой вопрос — как зависимые фильтры ведут себя при загрузке значений. Сейчас при выборе значения внутри зависимого выпадающего списка отображается состояние загрузки, но сам список не блокируется, хотя поведение при наличии второго зависимого фильтра еще нужно проверить. Предпочтительно сохранить возможность использовать фильтры, пока набор значений сужается, и показывать, что список еще не завершил обновление. Пользователям, которые уже знают нужное значение, не придется ждать загрузки метаданных.
**Связанные PR:** [#2423](https://github.com/hyperdxio/hyperdx/pull/2423) feat(dashboards): каскадные (фасетные) значения фильтров, [#2760](https://github.com/hyperdxio/hyperdx/pull/2760) feat(dashboards): сохранять переключатель связывания фильтров и уточнить связывание в пределах одного источника
## Запоминание последней вкладки боковой панели
*Демо от [@MikeShi42](https://github.com/MikeShi42)*
Самый небольшой PR недели также хорошо иллюстрирует неудобство, которое стоило исправить.
Боковая панель строки всегда открывалась на вкладке Overview, предназначенной для полей журналов OpenTelemetry. Для журналов, не соответствующих формату OTel, на этой вкладке отображается крайне мало полезной информации. Поэтому при каждом открытии строки приходилось переключаться на Column Values.
Теперь панель запоминает последнюю выбранную вкладку и открывает её при следующем открытии. Ничего настраивать не нужно. Пользователи, не использующие OTel и переключившиеся на Column Values, останутся на этой вкладке, а для всех, кто использует Overview, сохранится прежнее поведение.
**Связанные PR:** [#2752](https://github.com/hyperdxio/hyperdx/pull/2752) feat(app): запоминать последнюю использованную вкладку боковой панели при повторном открытии