Ссылки на источники в Notebook
Демо от @pulpdrew
На плитки Notebook (ячейки) теперь можно ссылаться напрямую, в том числе из других веток. В пользовательском Markdown можно использовать как абсолютную ссылку, так и относительную hash-ссылку, поэтому стало гораздо проще направить кого-то к точному подтверждению утверждения.
Но более крупное изменение — на стороне агента. Сводки, создаваемые в Notebook, теперь содержат ссылки на плитки, на которых они основаны, так что читатели могут сразу перейти к исходным данным, а не принимать сводку на веру.
Мы также изменили то, как открываются существующие Notebook. Плитка со сводкой теперь по умолчанию развернута, а не свернута — обычно именно это и нужно, когда возвращаешься к Notebook.
Оптимизация первичного ключа таблицы метрик OTel
Демо от @knudtty
Подробный разбор оценки и уменьшения первичных ключей в таблицах метрик OTel. Ключевой показатель здесь — число байт первичного ключа на гранулу: общий размер первичного ключа, делённый на количество гранул. Это учитывает, что у более крупных таблиц естественным образом больше гранул, и позволяет корректно их сравнивать.
В исходной схеме получалось около 148 байт на гранулу. В новой схеме — около 17 байт, то есть размер первичного ключа уменьшился примерно в 9 раз, а использование памяти в продакшне сократилось сопоставимо.
Изменения схемы довольно небольшие. MetricName теперь использует LowCardinality, и это подходит, если только вы не работаете с огромным количеством уникальных имён метрик. Но даже в этом случае проблема, скорее всего, проявится только в совсем крайних ситуациях. Временные метки переводятся с DateTime64 с наносекундной точностью на обычный DateTime с точностью до секунды, чего для метрик более чем достаточно. При необходимости вы по-прежнему можете сохранить наносекундную точность, изменив схему самостоятельно.
Мы также добавили явные индексы min/max по времени и заменили полный Map атрибутов в первичном ключе на хеш. Те же изменения были применены ко всем схемам таблиц метрик, и мы также отправляем их в upstream-проект OTel collector.
Связанные PR: #2545 fix: change metrics PK for better memory usage
Линии тренда и спарклайны на фоне чисел
Демо от @alex-fedotyev
Плитки Number теперь могут показывать линию тренда или график с областями на фоне значения. Эта возможность давно популярна в Grafana, а теперь появилась и в ClickStack.
Её можно включить в настройках отображения плитки. По умолчанию фоновый график отключён; помимо этого, доступны варианты с линией и областью. Настройки почти не нужны, но панели мониторинга сразу выглядят заметно более завершёнными.
Пока фоновые графики работают только с декларативными плитками Number, поэтому задать custom SQL пока нельзя. Мы рассматриваем это как следующий шаг, поскольку пользователи хотят больше контроля над тем, что именно строится на графике.
Связанные PR: #2489 feat(dashboards): фоновая трендовая спарклайн-линия для плиток Number, #2501 fix(dashboards): привести фоновую спарклайн-линию плитки Number в соответствие с отображаемым значением, #2520 refactor(dashboards): вынести общий примитив Sparkline из плитки Number
Визуальные улучшения таблиц
Демо от @alex-fedotyev
Табличные плитки получили несколько улучшений, повышающих удобочитаемость, — все они появились благодаря конкретным отзывам пользователей. Теперь в настройках отображения можно включить чередующийся фон строк, что заметно упрощает просмотр широких или плотных таблиц. Кроме того, разделитель между строкой заголовка и данными под ней стал чище и заметнее.
Теперь столбцы могут иметь собственные цвета с теми же параметрами оформления, что и у плиток Number. Можно задать один цвет по умолчанию или добавить пороги, которые проверяются для каждой ячейки отдельно, чтобы ошибки отображались красным, а обычные значения — зелёным.
Изменения небольшие, но каждое из них выросло из реальных комментариев пользователей в духе: «Хорошо бы, если бы таблица умела вот это».
Связанные PR: #2519 feat(dashboard): разделитель строки заголовка в табличной плитке и опциональный чередующийся фон строк, #2517 feat(dashboards): цвет по столбцам в табличных плитках
Улучшения плагина Grafana
Демо от @alex-fedotyev
Краткий обзор того, что скоро появится в плагине Grafana для ClickStack.
Конфигурация источника данных теперь поддерживает режим одной таблицы наряду с существующей схемой с несколькими базами данных. Укажите одну таблицу, например журналы из продакшн, и редактор запросов переключится в компактный конструктор, предназначенный для исследования данных. В нем есть быстрые фильтры по таким полям, как имя сервиса, а также фильтрация по включению и исключению; при этом SQL по-прежнему доступен, когда он нужен.
Мы также выпускаем готовые панели мониторинга для журналов и трассировок OTel с тем же drill-down-подходом, к которому привыкли пользователи. Панель мониторинга журналов включает обзор по сервисам, графики объема и подробности журналов. Раздел Trace Explore охватывает представления сервисов, heatmap задержек и разбивку по операциям. Также есть объединенная панель мониторинга сервисов, которая показывает журналы и трассировки вместе, сгруппированные по имени спана, так что вы можете исследовать один сервис, не переключаясь между инструментами.
Все эти панели мониторинга работают со схемой по умолчанию сразу после установки. Новые пользователи могут начать работу сразу, а затем использовать их как отправную точку для собственных панелей мониторинга.
Кроме того, появились два новых конструктора в стиле мастера. Конструктор переменных позволяет выбирать значения столбцов вместо написания custom SQL. Например, вы можете создать переменную из имен подов и предварительно просмотреть возвращаемые ею значения.
Конструктор аннотаций генерирует аннотации из запроса на обнаружение изменений по выбранному полю. Укажите атрибут версии сервиса, и он сможет добавлять маркер развертывания каждый раз, когда это значение меняется, без необходимости писать SQL вручную.
Демо от @karl-power
Большой пакет улучшений для навигации и просмотра трасс.
Теперь боковую панель можно закрепить в открытом состоянии во время работы на странице поиска, чтобы прокручивать и выбирать другие строки, не закрывая её. Навигация также сохраняет контекст текущей вкладки. Кнопка «Назад» использует цепочку навигации, чтобы вернуть вас именно туда, откуда вы пришли, а не просто закрыть панель.
Также появилось всплывающее окно с сочетаниями клавиш, так что доступные комбинации легко найти. Журналы, связанные с трассой, теперь показывают бейдж, который сразу переводит к ней.
Представление спанов получило самые заметные улучшения. Спаны теперь окрашиваются по имени сервиса, с переключением цветов при смене сервисов, а новая мини-карта делает большие трассы гораздо удобнее для чтения, чем сплошная стена серых полос. Можно выделить диапазон времени перетаскиванием, чтобы приблизить нужный участок, и сбросить представление одним щелчком. Новый стек истории также позволяет переходить между трассами и возвращаться туда, где вы были.
Для выбранных спанов улучшены элементы управления раскрытием и сворачиванием, так что больше не нужно закрывать каждый дочерний элемент по отдельности. Мы также включили исправление, предложенное сообществом, которое задаёт очень коротким спанам минимальную ширину отображения. Например, спан длительностью в несколько микросекунд остаётся видимым на временной шкале без необходимости масштабировать до предела.
Связанные PR: #2552 feat: add trace timeline minimap
Запросы к метрикам, eval для панелей мониторинга и улучшенная отчетность об ошибках для alerting в MCP
Демо от @brandon-pereira
В этом цикле одновременно вышли три улучшения MCP-сервера.
Теперь MCP может выполнять запросы к метрикам напрямую, в том числе из Notebooks, без маршрутизации через панель мониторинга только для доступа к исходным данным.
Мы также добавили сквозной eval для создания панелей мониторинга. Сейчас он успешно проходит около 75% сценариев, и мы постепенно добавляем отвлекающие факторы, чтобы его было сложнее обмануть. Когда MCP создает нерабочую панель мониторинга в реальных условиях, такой сбой можно добавить в набор eval. Со временем это должно выявлять такие проблемы, как источники Raw SQL, формирующие неверный запрос, прежде чем они превратятся в повторяющиеся сбои.
Ошибки инструментов теперь классифицируются по категориям, а не попадают в один общий бакет. Некорректный SQL-запрос от пользователя теперь обрабатывается отдельно от внутреннего сбоя, такого как тайм-аут базы данных. Это дает нам нужное разделение, чтобы строить более полезные алерты по состоянию MCP.
Связанные PR: #2437 feat(mcp): first-class metric source support, #2571 feat(hdx-eval): add dashboard-build eval scenario, #2570 feat(mcp): classify MCP tool errors by category for alerting
Изменения в пакетном процессоре OTel collector
Демо от @SpencerTorres
OpenTelemetry переносит батчинг из автономного пакетного процессора в конфигурацию экспортера. Коллектор ClickStack уже поддерживал оба подхода, поэтому код менять не пришлось. В итоге потребовалось только обновить документацию.
В старой модели выделенный пакетный процессор находился в конвейере и буферизовал строки перед передачей в экспортер. У него были собственные настройки размера батча, максимального размера батча и тайм-аута.
В модели, которую стандартизирует OpenTelemetry, батчер размещается рядом с экспортером, а не в цепочке процессоров. При этом сохраняется большинство тех же концепций, включая минимальный и максимальный размеры батча и размер очереди. Конфигурация на основе экспортера также поддерживает блокирующее поведение, ограничения по числу байтов и сохранение состояния — ничего этого не было в старом пакетном процессоре.
Теперь в документации рекомендуется конфигурация на основе экспортера и объясняется, как перенести существующие настройки пакетного процессора. Также рекомендуется минимум 5 000 строк и короткий тайм-аут как разумное значение по умолчанию для большинства развертываний. Неудачная конфигурация батчинга по-прежнему остаётся одной из самых частых причин неудачного первого опыта работы с ClickHouse.
Окружающий контекст для произвольных атрибутов
Демо от @MikeShi42
Окружающий контекст позволяет открыть строку лога и посмотреть, что еще происходило вокруг нее. По умолчанию этот контекст группируется по сервису, поду или узлу. Это хорошо работает для большинства развертываний со схемой OTel, но у тех, кто использовал пользовательскую схему, не было удобного способа строить это представление на основе собственных атрибутов.
Теперь для формирования представления контекста можно использовать любой атрибут строки лога — независимо от того, взят он из схемы OTel или из пользовательской. Привычные варианты service, pod и node по-прежнему доступны, но с тем же успехом можно группировать, например, по версии SDK телеметрии или любому другому полю в строке лога. В любой момент можно также очистить выбор и начать заново.
Связанные PR: #2558 fix: support service name expression and quick attribute filters in surrounding contextПоследнее изменение 23 июля 2026 г.