Последние пару месяцев в ClickStack выдались насыщенными: вышло четыре минорных релиза, и вскоре мы поделимся отличными новостями. Мы немного отстали с рубрикой «Что нового», поэтому этот выпуск объединяет сентябрь и октябрь и охватывает версии с v2.39 по v2.42.
На дашбордах появились нерегламентированные фильтры для повышения интерактивности, фильтры с одиночным выбором и обязательные фильтры, сохраненные относительные диапазоны времени, а также переменные в плитках markdown. PromQL, представленный в режиме предварительного просмотра в августе, теперь поддерживает все типы диаграмм в редакторе, включая числовые плитки, таблицы, круговые диаграммы и тепловые карты. Плитки PromQL также поддерживаются через внешний API для управления дашбордами Prometheus как кодом, а в тепловых картах появился режим серий.
Каждый запрос ClickStack теперь включает информацию о своем источнике, что помогает отслеживать нагрузку на чтение в общих кластерах ClickHouse. Мы также добавили вкладку журналов трассировки, привели панели спанов в соответствие с текущими соглашениями OpenTelemetry и улучшили страницу поиска благодаря помощи сообщества. Среди других дополнений — создание алертов из проводника диаграмм, инструмент проверки работоспособности службы MCP для более быстрого проведения расследований с помощью агентов, а также поддержка StatsD и метрик спанов в коллекторе.
Если двух месяцев ждать слишком долго, наши еженедельные видеоролики Demo Day — отличный способ быть в курсе последних новостей. Команда разработчиков показывает, над чем они работают, так что вы можете увидеть, что именно создается, еще до того, как это попадет в эту рассылку. Мы также делимся этими видео в канале #o11y-clickstack в Slack.
На следующей неделе мы будем на конференции KubeCon в Солт-Лейк-Сити. Присоединяйтесь к нам на стенде №108 или пройдите практическое обучение ClickStack 9 ноября. Чтобы попасть на коктейли, запросите место на Gracie's on November 10 или AprèsKube at Keys on Main on November 11, регистрация подлежит одобрению.
На следующей неделе мы будем на конференции KubeCon в Солт-Лейк-Сити. Присоединяйтесь к нам на стенде №108 или пройдите практическое обучение ClickStack 9 ноября. Чтобы попасть на коктейли, запросите место на или , регистрация подлежит одобрению.
Спасибо нашим контрибьюторам открытого исходного кода и пользователям, чьи отзывы помогли сформировать многие из этих функций.
Harshul1484, DevShoaib78, breken-ai, krishs01, BilalAtique, 28Hus, squaredg, archat-hash, octo47, wanjinhao1, felipe-carvalho12, adityareddy-dev, bahltushar, andrewdunndev, poblahblahblah, marcleblanc2
Участие в разработке не обязательно означает написание кода. Исправления документации, идеи, запросы функций, отчеты об ошибках и общие отзывы приветствуются через the repository.. Небольшие вклады тоже имеют значение, и каждый из них делает ClickStack лучше для всего сообщества.
До сих пор фильтры дашборда должны были определяться пользователем заранее. Тот, кто создавал дашборд, выбирал столбец, и все остальные получали для него выпадающий список. Но во время расследования вы можете заметить хост, код состояния или идентификатор клиента, по которым хотите отфильтровать данные, но автор дашборда этого не предусмотрел. Это означало необходимость редактирования отдельных плиток или добавления еще одного фильтра дашборда.
Новый тип фильтра «Нерегламентированные ключи и значения» позволяет выбирать поля для фильтрации прямо в процессе расследования. Он поддерживает столбцы и ключи сопоставления для источников журналов, трассировок и метрик, а также имена меток для источников PromQL.
Выберите ключ, оператор и значение на панели фильтров, используя подсказки как для ключей, так и для значений. Затем это условие применяется ко всем плиткам, использующим эти источники.
Эти фильтры также обеспечивают большую интерактивность дашбордов, позволяя пользователям добавлять условия непосредственно из визуализаций. Нажмите на ячейку в плитке поиска, ячейку группировки в табличной плитке или серию во всплывающей подсказке графика времени, чтобы отфильтровать данные по этому значению. Для плиток с необработанным SQL ClickStack использует предложение GROUP BY запроса для определения столбцов, доступных для фильтрации по клику. Если он не может разобрать запрос, он вместо этого предлагает текстовые столбцы. Если для определенной службы наблюдается рост ошибок, вы можете отфильтровать данные по этой службе, а затем сузить поиск по региону без редактирования каких-либо плиток. Предварительный просмотр SQL и PromQL показывает условия, примененные к каждому запросу.
Условия поддерживают равенство, отрицание, соответствие регулярным выражениям и оператор LIKE для источников SQL. Выбранные значения сохраняются в URL-адресе дашборда, поэтому вы можете поделиться отфильтрованным представлением или сохранить их в качестве значений дашборда по умолчанию наряду с существующими фильтрами. При импорте дашборда его нерегламентированные фильтры сопоставляются с вашими источниками точно так же, как и его плитки.
На данный момент нерегламентированные фильтры являются экспериментальными. Включите их с помощью переменной среды NEXT_PUBLIC_ENABLE_ADHOC_FILTERS=true, пока мы собираем отзывы.
На данный момент нерегламентированные фильтры являются экспериментальными. Включите их с помощью переменной среды NEXT_PUBLIC_ENABLE_ADHOC_FILTERS=true, пока мы собираем отзывы.
Когда в августе мы представили поддержку PromQL, вы могли использовать одно выражение PromQL на графике временных рядов. С тех пор мы расширили редактор диаграмм, чтобы поддержать больше типов диаграмм и параметров запросов, необходимых командам при переносе дашбордов Prometheus в ClickStack.
Графики временных рядов теперь поддерживают несколько выражений PromQL, каждое со своим псевдонимом. Например, вы можете одновременно отображать задержки p50, p95 и p99. Предварительный просмотр запроса под редактором показывает каждое выражение с подставленными переменными дашборда.
Числовые плитки покажутся вам знакомыми, если вы пользовались панелями статистики Grafana. Выберите мгновенный запрос (Instant query) для вычисления выражения один раз в конце временного диапазона или диапазонный запрос (Range query) для сведения результатов к единственному значению с помощью функций Last, Min, Max, Avg, Sum или Count. Диапазонные запросы также могут отображать мини-график (sparkline) позади числа. Если ваше выражение по-прежнему возвращает более одного значения, плитка выдаст предупреждение.
PromQL также работает с таблицами, круговыми и гистограммными диаграммами. Таблицы показывают каждую возвращенную выборку в виде строки со столбцом для каждой метки. Круговые диаграммы и гистограммы поддерживают те же параметры мгновенных и диапазонных запросов, что и числовые плитки, а также шаблоны легенд.
Вы можете использовать три совместимых с Grafana макроса в своих выражениях: $__interval для детализации графика, $__range для длительности выбранного временного диапазона и $__rate_interval для окна, охватывающего несколько интервалов сбора данных. Все три отображаются в подсказках автозаполнения и подставляются в предварительный просмотр запроса точно так же, как и переменные дашборда.
Для запросов, возвращающих сотни серий, параметр ограничения серий (Series Limit) в настройках отображения помогает сохранять читаемость графиков. Линейные и сгруппированные гистограммы сохраняют верхние серии по пиковому значению, в то время как круговые диаграммы и гистограммы сохраняют наибольшие срезы или столбцы.
Поддержка PromQL по-прежнему носит экспериментальный характер. Включите ее с помощью ENABLE_PROMQL=true для API и NEXT_PUBLIC_ENABLE_PROMQL=true для приложения.
Поддержка PromQL по-прежнему носит экспериментальный характер. Включите ее с помощью ENABLE_PROMQL=true для API и NEXT_PUBLIC_ENABLE_PROMQL=true для приложения.
Мы также улучшили переменные дашборда, представленные в августе, на основе отзывов пользователей.
Фильтры теперь можно помечать как доступные только для одиночного выбора, поэтому выбор нового значения заменяет текущий выбор. Это особенно полезно для PromQL, где переменные с возможностью множественного выбора расширяются до альтернатив с регулярными выражениями и требуют использования сопоставителя =~.
Переменные с одиночным выбором работают с простым равенством, например instance="$instance". Новый формат переменных PromQL, используемый по умолчанию в выражениях PromQL, обрабатывает экранирование как для значений с одиночным, так и с множественным выбором.
Вы также можете отметить фильтры как обязательные. Ранее при открытии дашборда выполнялся каждый тайл до того, как вы выбирали какие-либо фильтры, что потенциально могло приводить к запросам большого объема неинтересных вам данных.
Тайлы, использующие обязательный фильтр, теперь ждут, пока вы выберете значение. Вы также можете распространить это требование на каждый тайл на дашборде. При редактировании тайла в предпросмотре используются ваши текущие выбранные фильтры дашборда с переключателем Применить фильтры для сравнения отфильтрованных и неотфильтрованных результатов.
Дашборды теперь также запоминают относительные диапазоны времени. Сохраните дашборд с выбранным значением "последние 6 часов", и он будет открываться с учетом последних 6 часов каждый раз, а не с фиксированными датами, которые отображались при сохранении.
Наконец, тайлы разметки теперь поддерживают переменные дашборда, в том числе в ссылках. Вы можете использовать их для отображения просматриваемой службы или окружения, либо передавать текущий выбор на другую страницу через ссылку. Значения экранируются для Markdown по умолчанию, а при необходимости другого представления доступны ${var:csv} и другие форматы.
Тепловые карты в ClickStack ранее отображали числовые распределения со значением по бакетам, таким как длительность спана по оси y, а цвет указывал на количество событий в каждом бакете. Это отлично работает для понимания задержек, но не позволяет использовать визуализацию для более широких исследований поведения.
Новый режим Серии предоставляет каждому значению группировки собственную строку, при этом временные бакеты остаются вдоль оси x, а цвет представляет выбранный вами агрегат. Вы можете использовать его во многом как многосерийную линейную диаграмму, где цвет показывает значения вместо высоты линии.
Для источников PromQL тепловые карты поддерживают три режима. Серия работает так же, как описано выше, с использованием диапазонного запроса и поддержкой макросов, переменных и шаблонов легенд. Гистограмма работает с метриками, которые Prometheus уже разбил на бакеты. Границы бакетов берутся из меток le, и вы можете использовать sum by (le) (...) для объединения серий, которые разделяют эти границы.
Группы распределения выполняют выборку значений из всех серий в бакеты для каждой временной метки с использованием линейного или логарифмического интервала. Это полезно для данных, которые еще не являются гистограммой, таких как использование CPU по ядрам.
Когда группировка возвращает более 50 серий, тепловая карта отображает первые 50 и показывает предупреждение. В ней используется та же сортировка, что и на временных диаграммах.
Внешний API дашбордов теперь поддерживает тайлы PromQL. Запрос GET /api/v2/dashboards включает их в ответы, а POST и PUT принимают их с использованием configType: "promql", sourceId и списка выражений. Ранее тайлы PromQL опускались в ответах, что означало их возможную потерю при сохранении дашборда обратно через API.
Теперь вы можете управлять дашбордами, содержащими тайлы PromQL, через API или Terraform, точно так же, как и другими дашбордами.
Мы также добавили обнаружение источников PromQL в процесс настройки. Когда PromQL включен, ClickStack автоматически создает источник для любой таблицы ClickHouse TimeSeries, обнаруженной в соединении, наряду с источниками логов, трасс и метрик, обнаруженными из таблиц OpenTelemetry.
"Под капотом" запросы PromQL теперь используют Prometheus HTTP API от ClickHouse, если сервер его поддерживает. ClickHouse поддерживает обратную совместимость для этого интерфейса, пока движок TimeSeries находится в стадии предварительного просмотра. Тайлы PromQL и маршруты /api/v1/prometheus/* теперь используют sourceId вместо connectionId, разрешая подключение через источник.
Поставляемые образы ClickHouse обновлены до версии 26.8. Если вы запускаете PromQL на собственном сервере ClickHouse, мы рекомендуем версию 26.8 или новее.
Поставляемые образы ClickHouse обновлены до версии 26.8. Если вы запускаете PromQL на собственном сервере сервер ClickHouse, мы рекомендуем версию 26.8 или новее.
Многие развертывания ClickStack используют общий кластер ClickHouse с другими рабочими нагрузками. До сих пор тяжелый запрос в system.query_log сообщал только о том, что он исходит из ClickStack, и больше ничего, поэтому отслеживание нагрузки на чтение до дашборда или алерта означало сопоставление текста SQL вручную.
Чтобы решить эту проблему, каждый выполняемый ClickStack запрос теперь содержит небольшой JSON log_comment с указанием интерфейса, который его инициировал, а также идентификаторов, которые его определяют: дашборд и тайл, сохраненный поиск, алерт, инструмент MCP или проводник диаграмм. Его query_id начинается с hdx- и имени интерфейса, поэтому запрос можно распознать в system.processes, пока он еще выполняется, без необходимости синтаксического анализа JSON.
Комментарий фиксирует то, о чем просили, но никогда — кто просил, поэтому идентификаторы пользователей или команд не записываются.
Комментарий фиксирует то, о чем просили, но никогда — кто просил, поэтому идентификаторы пользователей или команд не записываются.
Следующий запрос позволяет пользователям быстро определить, откуда исходит нагрузка для службы ClickStack:
Вы даже можете запустить его в самом ClickStack, чтобы посмотреть, что происходит "под капотом". Немного наблюдаемости для вашей наблюдаемости:
Запросы PromQL включают ту же атрибуцию независимо от того, выполняются ли они через Prometheus API ClickHouse или функции таблиц, поэтому вы можете отслеживать их нагрузку наряду с другими дашбордами. Помимо отслеживания затрат, это позволяет проследить медленный запрос до тайла, который его создал. Это также закладывает основу для рекомендаций по запросам, которые мы планируем разработать.
Мы внесли три улучшения в чтение трасс на боковой панели. Все три работают с трассами, которые вы уже собрали.
Раньше поиск логов трассы означал просмотр спанов в каскадной диаграмме (waterfall), что могло быть неудобно для трасс со множеством логов. Теперь на боковой панели событий есть вкладка Логи трассы (Trace logs), которая отображает логи в виде плоской хронологической таблицы с теми же возможностями пагинации, сортировки и разворачивания JSON, что и на странице поиска.
Вкладка появляется для любого спана или лога с идентификатором трассы и связанным источником логов. Выберите лог для его изучения на панели или используйте Открыть в поиске (Open in search), чтобы продолжить фильтрацию на странице поиска с тем же источником, трассой и временным окном. Мы также добавили общую длительность трассы и количество спанов на панель управления каскадной диаграммы, чтобы вы могли видеть обе величины без их вычисления по временной шкале.
SDK OpenTelemetry могут записывать исключения как логи с атрибутами exception.*, а также как события спанов. Панель Исключение (Exception) теперь появляется для любого лога или спана, содержащего exception.type, exception.message или exception.stacktrace. Каскадная диаграмма также подсвечивает логи ошибок и события исключений красным цветом, что облегчает их обнаружение.
Источники трасс по умолчанию теперь автоматически загружают события спанов и ссылки, поэтому исключения спанов отображаются без какой-либо ручной настройки источников.
Мы уделили много внимания странице поиска за последние два месяца, и сообщество тоже внесло свой вклад. Некоторые из улучшений ниже созданы силами сообщества, за что мы ему чрезвычайно благодарны. Спасибо всем, кто прислал PR, сообщил о проблеме или рассказал, что могло бы сделать их работу немного проще.
Заметили всплеск на гистограмме поиска и задаетесь вопросом, какая служба за него отвечает? Раньше для этого пришлось бы создавать диаграмму в другом месте. Теперь элемент управления Группировать по (Group by) на гистограмме позволяет разбить объем по полю. Выберите поле из того же списка ключей, что и боковая панель фильтров, или введите выражение SQL. Совместимые группировки остаются выбранными при переключении источников.
Иногда вам просто нужно отправить коллеге несколько строк логов. Теперь вы можете выбирать отдельные строки с помощью флажков или диапазон с помощью Shift+клик, а затем выбрать «Загрузить CSV», «Копировать как CSV» или «Копировать как JSON». Экспорт включает только выбранные строки и те столбцы, которые отображаются в данный момент.
Флажки появляются при наведении указателя мыши и остаются видимыми после того, как вы что-то выбрали.
Если вы добавили в таблицу столбцы MATERIALIZED или ALIAS, вы могли заметить, что они отсутствуют в деталях строки. Панель извлекает строки с помощью SELECT *, что исключает эти столбцы. Теперь их можно включить, выбрав «Показывать материализованные и алиасные столбцы» в меню параметров просмотра значений столбцов. Пока что по умолчанию эта опция отключена.
В том же меню теперь можно выбрать порядок свойств: от A до Z, от Z до A или исходный порядок. Последний вариант удобен, если вы предпочитаете сохранить порядок ключей в столбце Map или теле JSON.
Мы также получили отзывы о том, что некоторые пользователи предпочитают разворачивать строки внутри списка, а не открывать боковую панель. Теперь вы можете перейти в «Настройки» → «Результаты поиска» → «Клик по строке» и установить значение «Разворачивать внутри», что делает кликабельной всю строку целиком, а не только маленький значок шеврона. Вы по-прежнему можете открыть боковую панель с помощью кнопки, которая появляется при наведении.
Судя по последним изменениям, поиск ключа в длинном списке атрибутов должен стать немного менее утомительным. Группы Map, такие как LogAttributes и ResourceAttributes, имеют собственный поиск по ключам, во многом похожий на поиск по значениям в обычных фильтрах. Каждый столбец Map также получает собственный лимит выборки ключей, поэтому сотни атрибутов логов не вытеснят ResourceAttributes из боковой панели.
Мы также перестали заставлять всю боковую панель ждать выполнения самого медленного запроса. Значения фильтров появляются по мере завершения каждого запроса. В течение более длительных диапазонов времени вы сначала увидите ключи, а значения будут заполняться по мере их поступления, так что вы сможете начать фильтрацию до того, как загрузится остальное.
Мы продолжаем инвестировать в создание оповещений на основе ваших потребностей и запросов, поэтому, пожалуйста, продолжайте делиться своими отзывами.
Хотите настроить оповещение, не создавая плитку дашборда, которую вы никогда не откроете? Раньше для каждого оповещения требовался сохраненный поиск логов или плитка дашборда для метрик. Это требует много лишних хлопот, если вы переносите более тысячи правил Grafana.
Теперь вы можете составить график в проводнике, используя логи, трейсы или метрики, с помощью конструктора запросов или сырого SQL, и сразу же добавить оповещение. Оповещение сохраняет собственную конфигурацию графика и появляется на странице оповещений со значком графика. Перейдите по ссылке обратно в проводник, и ваш запрос будет готов к просмотру или редактированию.
Группированные оповещения теперь могут подсказать, какая именно группа требует внимания. Используйте {{var.<column>}}, чтобы включить значение группы, вызвавшей срабатывание, для любого столбца группировки. Например, {"summary": "{{var.ServiceName}} имеет повышенный уровень ошибок"} указывает название сервиса в каждом уведомлении. Эти значения также включаются в уведомлениях о разрешении проблемы.
Теги оповещений также доступны через {{tags}}. Эта функция появилась благодаря пользователю, которому нужно было перенаправлять оповещения в нужную команду через общий вебхук incident.io.
Мы также добавили несколько способов обнаружения ошибок в шаблонах до того, как оповещение сработает. Ошибки появляются в редакторе вебхуков по мере ввода текста, а API отклоняет тела запросов, которые не компилируются. Для автоматизированных рабочих процессов POST-запрос /api/v2/webhooks/validate проверяет конфигурацию вебхука без ее сохранения, что удобно при выполнении плана Terraform. В редакторе также перечисляются все доступные переменные с описанием, а функция «Отправить тест» заполняет их примерными значениями.
Мы активно тестировали MCP-сервер ClickStack в продакшене и в нашем наборе тестов. Наблюдение за тем, где агенты застревают или идут длинным путем, дало нам много пищи для размышлений.
«Как поживают мои сервисы?» — звучит как простой вопрос. Раньше для ответа на него агенту требовалось сделать несколько вызовов для получения таблиц и временных рядов, а затем собрать результаты воедино.
Новый инструмент clickstack_service_health возвращает пропускную способность, частоту ошибок, перцентили задержки и основные группы ошибок для каждого сервиса за один вызов. Он сравнивает результаты с тем же временным окном вчерашнего дня и выделяет проблемные сервисы, а также новые или растущие ошибки. В нашем тестировании проверки работоспособности сервисов агенты набирали больше баллов, выполняя примерно в два раза меньше вызовов инструментов.
Мы продолжим инвестировать в инструменты, которые помогают агентам успешно начинать расследования, тратить меньше токенов на сбор контекста и делать расследования более последовательными и эффективными с целью более быстрого решения проблем.
Мы также доработали детали, которые помогают клиентам MCP работать с сервером. Теперь каждый инструмент объявляет все четыре подсказки о своем поведении: является ли он только для чтения, деструктивным, идеопотентным и открытым (open-world). Клиенты используют эти подсказки при принятии решения о том, какие вызовы требуют утверждения, а некоторые проверки совместимости требуют наличия всех четырех.
Теперь сервер также включает заголовок, описание, веб-сайт и значок в своем ответе на инициализацию, поэтому каталоги MCP и клиенты имеют всю необходимую информацию при добавлении его в список.
Если ваше приложение уже использует StatsD для подсчета неудачных платежей, отслеживания размеров очередей или измерения времени выполнения задачи, вам не придется переписывать эту инструментировку для использования ClickStack. Коллектор ClickStack теперь включает StatsD-приемник, так что вы можете отправлять эти метрики напрямую в него. Он также понимает теги DogStatsD, что делает его полезным для приложений, которые в настоящее время отправляют пользовательские метрики в Datadog.
Мы также добавили коннектор метрик спанов для другой, но связанной задачи: превращения трейсов в метрики. Трейсы описывают отдельные запросы, но вам часто нужен общий обзор того, сколько запросов обрабатывает сервис, сколько из них завершаются ошибкой и сколько времени это занимает. Коннектор генерирует счетчики вызовов и гистограммы задержек из входящих спанов, включая трейсы от агента Datadog, поэтому вы можете создавать такие представления без добавления отдельной инструментировки метрик.
В совокупности эти дополнения позволяют переносить существующие метрики приложений в ClickStack и генерировать метрики сервисов на основе уже собираемых вами трейсов. Для команд, переходящих с Datadog, это означает меньше работы по инструментированию на начальном этапе и больше возможностей для поэтапной миграции. Вы можете сравнивать метрики в обеих системах и перестраивать дашборды, прежде чем отключать что-либо.
Оба компонента являются опциональными и настраиваются с помощью пользовательского конвейера с использованием CUSTOM_OTELCOL_CONFIG_FILE. Коннектор метрик спанов генерирует traces.span.metrics.calls и traces.span.metrics.duration с поддержкой экспоненциальных гистограмм, которые ClickStack сохраняет в исходном виде.
Хотите увидеть общую сумму и вклад каждого сервиса без необходимости складывать строки самостоятельно? Плитки временных рядов теперь поддерживают отображение линий с накоплением наряду с гистограммами с накоплением. Каждый ряд имеет заполненную область, наложенную на остальные, поэтому вы можете видеть как общую тенденцию, так и индивидуальный вклад.
Вы также можете выбрать способ соединения линий между точками с помощью настройки интерполяции линий: сглаженная, линейная или ступенчатая. Ступенчатая удобна для значений, которые изменяются дискретными скачками, например количество запущенных реплик. Эта настройка доступна в приложении, внешнем API и на MCP-сервере.
Экспорт Terraform ранее пропускал оповещения, которые не были привязаны к сохраненному поисковому запросу. Теперь оповещения плиток панели мониторинга включаются в экспорт с использованием формы source \= "tile", добавленной в версии 3.28.0 провайдера ClickHouse Terraform.
Плитки панелей мониторинга теперь могут содержать описание, поясняющее, что они отображают или как их читать. Установите его рядом с названием графика в редакторе плиток, и оно появится в виде информационной подсказки рядом с заголовком плитки. Описания также поддерживаются через внешний API.
При масштабировании графика автодискретность может выбирать интервалы, которые меньше интервала сбора метрики. Метрика, собираемая раз в минуту, может отображаться в 30-секундных интервалах, оставляя каждый второй интервал пустым и создавая впечатление, что данные отсутствуют. Чтобы избежать этого, теперь вы можете установить «Минимальную автодискретность» в разделе «Настройки команды» → «Источники», чтобы автоматические интервалы были как минимум не уже вашего интервала сбора данных. Плитки с явной дискретностью остаются без изменений.
Источники PromQL также имеют настройку «Минимальная автодискретность», предотвращающую создание коротких временных диапазонов с интервалами мельче вашего интервала сбора данных. Это значение также используется для расчета $__rate_interval, в противном случае предполагающего 15-секундный интервал сбора.
Переключатель «Использовать время UTC» в пользовательских настройках теперь представляет собой выбор часового пояса с закрепленными наверху вариантами «Локальное» и «UTC» и всеми поддерживаемыми браузером зонами ниже. Значок на боковой панели и заголовки столбцов с метками времени показывают выбранную вами зону.
Запускаете несколько экземпляров ClickStack, возможно, по одному на регион? Установите для NEXT_PUBLIC_INSTANCE_LABEL короткую метку, такую как «UK». Она появится в заголовке вкладки браузера и на боковой панели, что упростит поиск нужного экземпляра среди множества вкладок.
Теперь вы можете установить ограничение на запросы /api/v2/* с помощью EXTERNAL_API_RATE_LIMIT_MAX, предоставляя больше возможностей интенсивным интеграциям или заданиям экспорта. Значение по умолчанию остается равным 100 запросам в минуту.
Имена метрик теперь передаются потоком из первичного индекса таблицы вместо ожидания агрегации данных. В источниках с тысячами метрик первые варианты появляются за десятки миллисекунд. Ввод текста выполняет исчерпывающий поиск, поэтому вы все равно сможете найти любую метрику, которую пропустил индекс.
Плитки с числами, гистограммами, круговыми диаграммами, таблицами и тепловыми картами теперь сохраняют видимость предыдущих данных и пульсируют во время обновления, как это уже делали временные графики. Вы можете видеть, когда обновление все еще выполняется, не теряя текущих результатов. Спасибо сообществу за этот вклад.
Консольный просмотр в реальном времени теперь поддерживает предустановки на 3 ч и 6 ч, увеличивая предыдущий часовой лимит. Более длительные диапазоны остаются отключенными с объяснением в средстве выбора: каждое обновление заново запрашивает все окно.
Страница оповещений теперь загружается по одной странице за раз с фильтрацией на стороне сервера, а не загружает все оповещения в браузер. Команды с тысячами оповещений могут фильтровать их по состоянию, имени и тегам, не замедляя работу страницы.
На этом за сентябрь и октябрь все. Опробуйте новые функции и расскажите нам о своих впечатлениях.
Одна деталь, которую следует проверить перед обновлением локального развертывания (self-hosted): если аутентификация включена, теперь необходимо явно задать параметр EXPRESS_SESSION_SECRET. API больше не возвращается к общедоступному значению по умолчанию.
Начните работу сегодня
Хотите посмотреть, как ClickHouse работает с вашими данными? Начните работу с ClickHouse Cloud за считанные минуты и получите 300 долларов бесплатных кредитов.
