> ## 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-08-07
> Демо-дни ClickStack от 2026-08-07
## Страница сведений об оповещении с историей проверок
*Демо от [@wrn14897](https://github.com/wrn14897)*
Сейчас на странице оповещений есть полоса истории и кнопка ошибок. Всё выглядит полезно, пока не потребуется найти с их помощью ответ на конкретный вопрос.
Ошибка хранится в самом документе оповещения, поэтому на странице отображается последнее состояние, а не фактическая история. Нельзя понять, сработало ли оповещение, возникали ли ранее ошибки и успевает ли оно выполняться по расписанию. Это выяснилось во время работы над производительностью оповещений: существующее представление оказалось не просто скудным, а сбивающим с толку.
Новая страница сведений записывает каждую проверку как событие. Диапазон временных меток позволяет просмотреть любой период истории; срабатывания и снятия оповещений отображаются отдельно и чётко обозначены.
Информация о группировке вынесена в таблицу. Если оповещение использует `GROUP BY`, можно открыть проверку и увидеть, какие именно группы сработали, а какие — нет. Это различие важно, когда порог превышает лишь часть результатов. Ошибки также сохраняются в отдельных записях истории, поэтому можно увидеть, что и когда завершилось ошибкой, включая исходную ошибку запроса к ClickHouse.
Столбцы времени показывают, успевает ли оповещение выполняться по расписанию. Длительность запроса фиксирует время, затраченное на выполнение запроса к ClickHouse. Если оповещение запускается каждую минуту, но его запрос выполняется три минуты, задержки неизбежны. Длительность вебхука показывает время, затраченное на отправку результата в пункт назначения.
Пропущенные бакеты делают накопившуюся очередь заметной. Значение семь означает, что семь запланированных окон проверки были пропущены и обработаны позже.
**Связанные PR:** [#2833](https://github.com/hyperdxio/hyperdx/pull/2833) модель чтения проверок оповещений и GET /alerts/:id/evaluations, [#2834](https://github.com/hyperdxio/hyperdx/pull/2834) сохранение ошибок проверок оповещений и аналитики в AlertHistory, [#2835](https://github.com/hyperdxio/hyperdx/pull/2835) страница сведений об оповещении с историей проверок
## Оценка использования инструментов метрик в MCP с помощью evals
*Демо от [@karl-power](https://github.com/karl-power)*
Это третий и, вероятно, последний сценарий с метриками для фреймворка evals. Он намеренно занимает промежуточное положение между двумя другими.
Существующий сценарий `metric-saturation` проверяет, может ли агент использовать инструменты метрик, когда его к этому вынуждают. Новый сценарий `deploy-regression` проверяет, выбирает ли он их сам. Поэтапное развертывание `checkout-api` приостанавливается после обновления трёх из шести подов. Новая сборка вызывает `TypeError` при использовании промокодов на фиксированную сумму, из-за чего примерно 7–8 % оформлений заказа завершаются с ошибкой 500, но только на обновлённых подах и только для таких кодов.
Агенту ничего из этого не помечено. Самая важная подсказка — перекрёстный анализ неудачных оформлений заказа по именам подов с последующим сопоставлением этих подов с журналами событий развертывания. Преднамеренно добавленные метрики подтверждают момент начала сбоев, но не показывают разделение по подам или первопричину дефекта. Агент может полностью игнорировать метрики и всё равно решить сценарий. Поэтому использование метрик здесь является естественным, а не вынужденным.
Есть несколько ловушек, чтобы путь к решению не был слишком очевидным. За несколько минут до начала сбоев происходит несвязанное развертывание, а на тех же границах, что и реальные ошибки, возрастает безобидный поток предупреждений об устаревании.
Создание сценария также выявило места, где MCP мог бы лучше показывать агентам доступные типы и имена метрик. В результате внесённых изменений и то и другое стало проще обнаружить.
Улучшение скромное, и сравнение честно это отражает. Агенты и без изменений уже показывают хорошие результаты. Однако с ними в нескольких запусках они заметно быстрее находят полезные метрики. С Fable разрыв сокращается — это просто более способная модель в данном случае.
Один результат изменился в обратную сторону. В паре запусков Opus показал немного худший результат после изменений, связанных с метриками. Прежде чем делать какие-либо выводы, нужно больше данных.
Впервые фреймворк evals измерил улучшение того, как MCP предоставляет метрики. Нам больше не нужно целиком полагаться на субъективное ощущение, что изменения стали лучше.
Далее нужно провести достаточно запусков, чтобы разобраться с результатом Opus, а затем привести в порядок лежащий в его основе код.
**Связанные PR:** [#2730](https://github.com/hyperdxio/hyperdx/pull/2730) — добавить сценарий deploy-regression (измерение естественного использования инструментов метрик), [#2717](https://github.com/hyperdxio/hyperdx/pull/2717) — усилить сценарий metric-saturation, [#2694](https://github.com/hyperdxio/hyperdx/pull/2694) — оценивать использование инструментов метрик и формировать отчёты, [#2855](https://github.com/hyperdxio/hyperdx/pull/2855) — предоставлять сводные метрики через MCP
## Distributed-таблицы, гистограммы и ускоренный поиск трассировок
*Демо от [@pulpdrew](https://github.com/pulpdrew)*
В этот раз — набор небольших исправлений, некоторые из которых появились благодаря отзывам команды ClickHouse. Самым простым было добавление отсутствующей кнопки очистки в одном из разделов фильтров, хотя во всех остальных она уже была. Общая кнопка «Очистить всё» по-прежнему остаётся в списке пожеланий.
Случай с distributed-таблицами оказался сложнее. Некоторые базовые целевые таблицы не содержат всех столбцов, доступных через distributed-таблицу. При загрузке полных сведений о строке ClickStack выполняет `SELECT *`, что в такой конфигурации сразу приводит к ошибке. Боковая панель строки уже отображала ошибку, но развёрнутая строка — нет, и ни одно из представлений не объясняло, зачем ClickStack вообще выполняет `SELECT *`. Теперь в обоих представлениях ошибка отображается с достаточным контекстом, чтобы рекомендации были полезны.
У метрик было две отдельные проблемы. Во-первых, таблица экспоненциальных гистограмм никогда не сохранялась в источниках метрик. Это не имело значения, пока недавно не появилась поддержка экспоненциальных гистограмм. Пользователь, открывший существующий неполный источник, видел поле, заполненное в результате вывода схемы, обоснованно полагал, что менять ничего не нужно, и не сохранял его.
Вывод схемы больше не запускается просто при открытии существующего источника. Теперь он выполняется при создании источника метрик или изменении его базы данных, что ясно показывает: выведенную таблицу всё ещё необходимо сохранить.
Выпадающий список агрегаций также предлагал среднее, минимум, максимум и другие функции для метрик гистограмм, хотя гистограммы не поддерживают ни одну из них. Выбор такой функции приводил к ошибке при выполнении запроса или сохранении плитки. Теперь эти варианты скрыты для метрик гистограмм и экспоненциальных гистограмм. Путь MCP `query_tile` также отклоняет их для сохранённых плиток, действуя так же, как интерфейс, а не находя собственный способ завершиться ошибкой.
Исправление ограничения числа серий более тонкое. Когда `GROUP BY` создаёт несколько серий, можно задать ограничение, чтобы оставить верхние N по максимальному значению. В режиме отношения при ранжировании использовался только числитель. Это отдавало предпочтение большим числителям, а не действительно высоким отношениям, позволяя серии с большим числителем и столь же большим знаменателем вытеснять серию с фактически более высоким отношением. Теперь при ранжировании используется отображаемое отношение.
Также изменён выбор источника по умолчанию на странице поиска. Ранее выбирался первый настроенный источник, даже если он содержал метрики или сессии. Пользователи могли увидеть ошибку несовместимого источника для выбора, которого не делали. Теперь поиск по умолчанию выбирает первый включённый источник, который действительно может использовать.
При выборе трассировки на боковой панели лога также выполнялся скрытый дорогостоящий поиск. HyperDX искал только по span и ID трассировки, игнорируя разделы по временной метке и первичные ключи. В развертываниях с большим объёмом данных это работает медленно. Теперь поиск ограничен диапазоном дат, выведенным из источника, с преднамеренным возвратом к неограниченному запросу, если в указанном окне результат не найден. Например, это важно для лога, связанного со span, начавшимся несколькими часами ранее.
Глубокие ссылки по имени источника появились на предыдущей неделе, после чего закономерно возник вопрос, как пользователи должны их обнаруживать. URL-параметры, принимаемые каждой страницей, уже считались контрактом, поэтому теперь они задокументированы как таковой. Единственное исключение — фильтры на уровне источника, поскольку пока они доступны только в ClickHouse. В рамках отдельной доработки документации были добавлены поля конфигурации источника, такие как ссылки на span, охватывающие как недавние дополнения, так и несколько ранее упущенных возможностей.
**Связанные PR:** [#2771](https://github.com/hyperdxio/hyperdx/pull/2771) улучшает обработку ошибок SELECT \* для distributed таблиц и распространяет её на развёрнутые строки, [#2817](https://github.com/hyperdxio/hyperdx/pull/2817) автоматически определяет таблицы метрик только при изменении выбранной базы данных, [#2794](https://github.com/hyperdxio/hyperdx/pull/2794) не определяет таблицы метрик для источников, у которых уже есть таблицы (открыт), [#2793](https://github.com/hyperdxio/hyperdx/pull/2793) скрывает неподдерживаемые агрегатные функции для метрик гистограмм, [#2796](https://github.com/hyperdxio/hyperdx/pull/2796) отклоняет сохранённые плитки гистограмм с неподдерживаемыми aggFns в query\_tile (открыт), [#2759](https://github.com/hyperdxio/hyperdx/pull/2759) использует значение ratio для ранжирования ограничения серий в режиме ratio, [#2769](https://github.com/hyperdxio/hyperdx/pull/2769) предотвращает выбор несовместимого типа источника по умолчанию на странице Search, [#2816](https://github.com/hyperdxio/hyperdx/pull/2816) ограничивает поиск строки на боковой панели после View Trace временным окном, [#2836](https://github.com/hyperdxio/hyperdx/pull/2836) добавляет настройку переменной фильтра
## Процентили на тепловой карте и поиск Lucene от контрибьюторов
*Демо от [@pulpdrew](https://github.com/pulpdrew)*
На этой неделе от внешних контрибьюторов поступило около десяти pull request. Два из них заслуживают особого внимания.
Первый, от [@niladrix719](https://github.com/niladrix719), добавляет в подсказку при наведении на тепловую карту информацию о процентилях. Теперь вместо того, чтобы визуально сравнивать одну ячейку с остальной тепловой картой, можно навести на неё курсор и увидеть, например, что бакет 26 миллисекунд находится на 85-м процентиле среди показанных длительностей.
Второй — серия улучшений поиска Lucene от [@shuvamk](https://github.com/shuvamk).
Неограниченные диапазоны теперь работают корректно. `Duration:[* TO 500]` преобразуется в предикат `<= 500`, а не заставляет ClickHouse преобразовывать строку `*` в `UInt64`, что, как и следовало ожидать, ни к чему хорошему не приводит. Фигурные скобки теперь также поддерживаются для исключающих границ диапазона.
Исправления экранирования особенно важны, поскольку из-за этих ошибок возвращались неверные результаты, а не сообщения об ошибке. Термины полей Lucene напрямую подставляются в шаблон `ILIKE`, где символ подчёркивания означает любой одиночный символ, а знак процента — любую последовательность символов. Поэтому поиск по `ServiceName:user_service` также находил такие значения, как `user-service` и `user.service`. Теперь эти метасимволы экранируются до того, как запрос попадёт в ClickHouse.
Отдельное исправление предотвращает двойное экранирование индексов Map при числовом и булевом поиске. Сгенерированный предикат обрабатывал всё выражение как один идентификатор вместо выполнения поиска по Map.
Примеры в приложении, доступные через переключатель языка Lucene, также были обновлены и теперь охватывают новые формы диапазонов.
**Связанные PR:** [#2789](https://github.com/hyperdxio/hyperdx/pull/2789) отображать информацию о процентилях в подсказке при наведении на тепловую карту, [#2779](https://github.com/hyperdxio/hyperdx/pull/2779) учитывать открытые, исключающие и нечисловые границы диапазона, [#2774](https://github.com/hyperdxio/hyperdx/pull/2774) экранировать метасимволы LIKE в поисковых запросах, [#2841](https://github.com/hyperdxio/hyperdx/pull/2841) однократно экранировать индексы Map в числовом и Bool-поиске, [#2837](https://github.com/hyperdxio/hyperdx/pull/2837) добавить примеры для нового синтаксиса Lucene
## RED-метрики в поиске трассировок
*Демо от [@alex-fedotyev](https://github.com/alex-fedotyev)*
**Это исследовательская разработка, без обязательств по её выпуску.**
Сейчас поиск трассировок использует ту же единственную гистограмму количества, что и поиск логов, с цветовой маркировкой по уровню логирования. Она показывает, сколько трассировок найдено, но почти ничего не говорит об их производительности.
Предлагаемое представление результатов заменяет эту гистограмму RED-метриками для источников трассировок. Пропускная способность отображается в виде столбцов с количеством спанов. Ошибки можно отображать либо как процентную долю в виде линии, либо как абсолютное количество в виде столбцов. Длительность отображает среднее, p95 и p99 непосредственно из исходного столбца длительности источника.
Тепловая карта — более информативное представление. В демо она почти сразу позволяет выявить сервис с устойчиво растущей длительностью. Она также показывает форму распределения задержки, которую тренд процентилей сам по себе может скрыть.
Вопрос стоимости пока остаётся нерешённым. Поиск трассировок уже выполняет множество запросов для каждого поиска, и добавление ещё нескольких агрегаций потребует оптимизации производительности, прежде чем можно будет двигаться дальше.
Мы будем рады отзывам об этой функциональности.
**Связанные PR:** [#2826](https://github.com/hyperdxio/hyperdx/pull/2826) — отображение RED-метрик в представлении результатов поиска трассировок (открыт, исследовательский)
## Пользовательские столбцы журналов в плагине ClickHouse Grafana
*Демо от [@alex-fedotyev](https://github.com/alex-fedotyev)*
Несколько недель назад сразу несколько клиентов сообщили об одной и той же проблеме: в компактном представлении журналов плагина Grafana дополнительные столбцы и поля журналов было сложно просматривать.
Это изменение добавляет настройку Columns в раздел журналов конфигурации источника данных. Она задаётся на уровне источника данных, а не отдельных запросов, поэтому выбранные параметры сохраняются для всех, кто использует этот источник, и их не нужно настраивать заново каждый раз.
Можно выбрать любой столбец таблицы. Плагин добавляет эти столбцы в метки журналов под их фактическими именами, благодаря чему они становятся доступны во всём Grafana. Они отображаются в списке Fields слева и в сведениях о строке журнала, где новая группа Fields располагается рядом с Resource attributes и Log attributes и поддерживает те же действия фильтрации по значению и исключения значений. В табличном представлении они работают как полноценные фильтры по столбцам.
Всё это работает на основе одного и того же запроса. Без этой конфигурации эти поля не отображаются ни в одном из указанных мест — именно это и вызывало недовольство пользователей.
Проблема касалась обоих подходов к схеме. Некоторые клиенты используют OpenTelemetry, но добавляют собственные столбцы. Другие используют полностью пользовательские схемы и по собственным причинам хранят поля в обычных столбцах, а не в атрибутах ресурса или журнала. Ни одна из групп вообще не могла видеть эти значения в Grafana.
На момент демонстрации изменение всё ещё проходило проверку; его планировали включить в сборку плагина следующей недели. Дополнительный контекст приведён в [публикации о ClickHouse Grafana plugin 4.20](https://clickhouse.com/blog/clickhouse-grafana-plugin-4-20).
**Связанные PR:** [grafana/clickhouse-datasource#2108](https://github.com/grafana/clickhouse-datasource/pull/2108) — просмотр и фильтрация по любому столбцу таблицы журналов (на момент демо PR был открыт)
## Ограничение количества серий с высокой кардинальностью на стороне источника
*Демо от [@brandon-pereira](https://github.com/brandon-pereira)*
Ответ с высокой кардинальностью может передать графику сотни тысяч строк. Прежде чем что-либо отрисовать, клиент должен преобразовать каждую строку в JSON. На нагруженной панели мониторинга это преобразование обходится дороже самого запроса. Неограниченный `GROUP BY` также может исчерпать память сервера ещё до того, как результат попадёт в браузер.
Новый подход не позволяет большинству этих строк покидать ClickHouse. Теперь запросы включают настройки максимального числа строк и максимального числа сгруппированных строк; обе настройки пока ограничены 5 000. Откровенно говоря, это лишь предположение о разумном пределе. Если ответ указывает на превышение лимита, график предупреждает, что запрос вернул слишком много данных.
Это дополняет более раннюю оптимизацию фронтенда, ограничивающую отрисовку 250 сериями. Хранение десятков тысяч серий в памяти при отрисовке примерно сотни линий приводило к тому, что вкладки браузера занимали несколько гигабайт, а наведение и панорамирование работали медленно.
Оба ограничения по-прежнему действуют. Патологический `GROUP BY` теперь получает около 5 000 строк и отрисовывает 250 из них. Для случаев, когда действительно нужны все данные, по-прежнему доступны явные варианты «загрузить все».
Правильное решение для графика, который регулярно упирается в одно из этих ограничений, — всё то же улучшение SQL: добавьте лимит или сделайте `GROUP BY` более избирательным.
**Связанные PR:** [#2802](https://github.com/hyperdxio/hyperdx/pull/2802) ограничение количества серий с высокой кардинальностью на временных графиках с возможностью загрузить все данные, [#2856](https://github.com/hyperdxio/hyperdx/pull/2856) ограничение затрат на плитки с raw SQL на стороне источника с серверным лимитом строк/кардинальности (открыт)
## Экземплары: от графика метрики к трассировке
*Демо от [@jordan-simonovski](https://github.com/jordan-simonovski)*
Экземплары связывают агрегированную метрику с отдельным событием, обычно с трассировкой. Если гистограмма задержки показывает, что 99-й перцентиль вырос до 2,4 секунды, экземплар может указать на конкретный запрос, занявший 2,4 секунды, и открыть его трассировку.
Когда приложение записывает измерение внутри активного спана, OpenTelemetry включает его в обычную агрегацию. Фильтр экземпларов определяет, подходит ли это измерение, а затем небольшой резервуар сохраняет несколько примеров для экспорта вместе с агрегированной точкой метрики. Каждый экземплар содержит исходное значение и временную метку, ID трассировки и спана, а также все атрибуты, исключённые из агрегированного потока.
Небольшой резервуар даёт конкретный контекст без экспорта каждого необработанного измерения и без добавления `trace_id` и других высококардинальных значений к каждой серии метрик. Экземплар всё равно остаётся лишь примером. Он не обязательно соответствует самому проблемному запросу или статистически репрезентативной выборке. Будет ли работать его ссылка, также зависит от экспортёра, задействованных backend-соединений и от того, была ли сохранена указанная трассировка.
В демо используется backend Prometheus через конечную точку прокси `query_exemplars`, добавленную накануне. Если запрошенное окно слишком велико, конечная точка сужает его вместо отклонения запроса.
Тестовые данные поступают от OpenTelemetry Collector, который отправляет метрики спанов. Обрабатывая спаны, коллектор преобразует их в метрики с экземпларами, связанными с ID трассировки. Затем эти экземплары отображаются как маркеры на графике метрики. При наведении отображаются значение и временная метка экземплара вместе с метаданными трассировки, а кнопка открывает трассировку напрямую. Пока всё работает хорошо и достаточно быстро.
Конфигурация задаётся для каждой плитки. Включите экземплары на графике, затем выберите источник трассировок, который будет разрешать ссылки. Сейчас возможность поддерживает только метрики с одной серией, а вся функциональность по-прежнему скрыта за флагом уровня развертывания в дополнение к переключателю для каждого графика.
Тестирование выявило несколько небольших ошибок, некоторые из которых другие уже обнаружили независимо, но путь Prometheus практически готов. Далее — ClickHouse. Этот путь будет запрашивать экземплары непосредственно из таблицы метрик, предоставляя командам, строящим метрики на основе данных трассировок, тот же способ вернуться к отдельной трассировке.
**Связанные PR:** [#2805](https://github.com/hyperdxio/hyperdx/pull/2805) вывод метрик запросов с экземпларами трассировок из спанов (открыт), [#2806](https://github.com/hyperdxio/hyperdx/pull/2806) добавление /v1/prometheus/query\_exemplars и усиление прокси, [#2807](https://github.com/hyperdxio/hyperdx/pull/2807) разделение двух крупнейших файлов графиков на директории, [#2808](https://github.com/hyperdxio/hyperdx/pull/2808) оверлей экземпларов для временных графиков метрик и PromQL (открыт), [#2809](https://github.com/hyperdxio/hyperdx/pull/2809) приём настроек экземпларов для плиток, созданных API и агентом (открыт)
## Помощники для импорта в Terraform и пакетный экспорт
*Демо от [@jordan-simonovski](https://github.com/jordan-simonovski)*
На панелях мониторинга, в сохранённых поисках и оповещениях на основе сохранённых поисков теперь доступна кнопка Export to Terraform. Она позволяет командам передавать существующие ресурсы под управление Terraform через провайдер ClickHouse, не создавая вручную блоки импорта и не подбирая имена типов ресурсов и форматы ID.
В демо больше всего вопросов вызвал сам результат. Кнопка создаёт блок `import`, а полное определение ресурса Terraform формирует самостоятельно. Простое добавление блока ресурса не означает, что Terraform получает управление существующим ресурсом. Вместо этого он может попытаться создать ещё один ресурс или перезаписать уже существующий. Новый рабочий процесс импорта Terraform корректно учитывает это различие.
Вставьте сгенерированный блок импорта в конфигурацию, затем выполните `terraform plan` с параметром `-generate-config-out`, указав файл, например `generated.tf`. Terraform проанализирует существующий ресурс и запишет соответствующий блок ресурса. После импорта ресурс добавляется в Terraform state, и последующие применения управляют им, а не пытаются создать его заново в ClickStack.
В Team Settings также доступен пакетный экспорт, который скачивает один файл со всеми поддерживаемыми ресурсами. В демо это были 70 панелей мониторинга, около 40 оповещений и 55 сохранённых поисков. Также поддерживаются вебхуки и источники.
Секреты намеренно исключены из V2 API. Запрос `GET` возвращает только то, что уже доступно в UI, поэтому connection содержит хост и имя пользователя, но не пароль. При использовании сгенерированной конфигурации добавьте отсутствующий secret самостоятельно.
**Связанные PR:** [#2741](https://github.com/hyperdxio/hyperdx/pull/2741) добавляет помощники для импорта ресурсов ClickStack в Terraform
## Общие компоненты графиков, визуальные улучшения и предложение по черновикам
*Демо от [@elizabetdev](https://github.com/elizabetdev)*
Карточки на пользовательских панелях мониторинга и карточки из предустановок стали визуально различаться, что породило очевидный вопрос: почему они изначально не использовали один и тот же компонент? Теперь используют. Общий компонент ChartCard оборачивает отдельные графики в те же базовые элементы, что и плитки панели мониторинга, обеспечивая единообразие границы, внутренних отступов и разделителя заголовка во всю ширину без ручной подгонки. Перевести оба варианта на один компонент оказалось сложнее, чем ожидалось, но теперь внутри они отрисовывают одно и то же. Для карточек без элементов управления справа ещё требуется доработка, чтобы сохранять одинаковую высоту.
Также внесён ряд небольших улучшений, некоторые из которых специально направлены на то, как ClickStack выглядит на скриншотах и в демо-видео. Сегментированный элемент управления отрисовывал линию списка как границу вокруг блока нулевой высоты, из-за чего верхняя и нижняя границы накладывались и выглядели как линия толщиной 2 px. Теперь это действительно граница толщиной 1 px. По той же причине были переработаны цвета кнопок.
Логотип с открытым исходным кодом в светлой теме тоже исправлен. Ранее для переключения между темами использовался CSS-фильтр, инвертировавший все цвета, включая логотип, поэтому в светлой теме он отображался в неверном фирменном цвете. Как оказалось, один и тот же логотип подходит для обеих тем, поэтому ветвление по теме больше не требуется.
Нажатие на строки в поиске тоже снова работает корректно. Старое поведение было намеренным, но таковым не воспринималось. Выдвижная панель могла открыться над нажатой строкой, и на экране оставалась, казалось бы, неизменившаяся область. Нажатие в области выдвижной панели теперь обновляет её, а нажатие вне этой области закрывает панель.
Также добавлены семантические компоненты Alert для состояний предупреждения и успеха наряду с состоянием опасности. Новые навыки агентов направляют всё, что пытается использовать чистый красный цвет или текст предупреждения, к Alert, не позволяя жёстко задавать цвет из палитры Mantine.
Заключительная часть посвящена исключительно исследованию дизайна. Это макеты, и отзывы очень приветствуются.
Всё началось с небольшой проблемы в редакторе плиток: модальное окно открывало выдвижную панель, которая открывала другое модальное окно, и одно нажатие Escape закрывало весь стек вместо возврата на один уровень. Затем работа переросла в более широкий пересмотр панелей мониторинга.
Предложение заменяет разделение на сохранённые и временные панели мониторинга черновиками. При нажатии «New dashboard» создаётся приватный черновик, который видите только вы. Когда он будет готов, его можно сохранить для команды. Также можно переместить командную панель мониторинга обратно в черновики или вовсе удалить её. Это покрывает текущие сценарии использования временных панелей мониторинга, не вынуждая принимать такое решение заранее. Одна концепция вместо двух.
Для избранного появится представление списком наряду с карточками, поскольку страница с крупными карточками может отодвинуть нужный объект неожиданно далеко вниз. Шаблоны будут свёрнуты в одну строку. Фильтрация по тегам будет поддерживать несколько тегов и сортировку по имени или времени последнего просмотра, вместо того чтобы считать один выбранный тег единственным доступным способом организации.
Редактор плиток закрепит панель настроек справа вместо открытия выдвижной панели. Он также объединит два текущих пути к настройкам в один предсказуемый маршрут.
**Связанные PR:** [#2829](https://github.com/hyperdxio/hyperdx/pull/2829) добавить общий компонент ChartCard и перенести использования ChartBox, [#2814](https://github.com/hyperdxio/hyperdx/pull/2814) доработать тему Mantine (вкладки, фон кода, сегментированный элемент управления), [#2704](https://github.com/hyperdxio/hyperdx/pull/2704) семантические токены цветов, настроенные для AA, и варианты Alert/Text, [#2714](https://github.com/hyperdxio/hyperdx/pull/2714) задокументировать семантические варианты Alert/Text/danger, [#2682](https://github.com/hyperdxio/hyperdx/pull/2682) закрывать выдвижные панели поиска и сеанса при нажатии вне них, [#2721](https://github.com/hyperdxio/hyperdx/pull/2721) перенести редактор плиток в выдвижную панель с закреплённой панелью настроек (всё ещё открыт). Для переработки черновиков и избранного нет PR — на этом этапе это макеты.