Новые типы фильтров панели мониторинга
Демо от @pulpdrew
Раньше фильтры панели мониторинга поддерживали только один вид значений — значения из запроса, когда варианты в выпадающем списке берутся из столбца в ClickHouse. Откройте модальное окно фильтров и переменных: теперь на выбор доступны ещё два типа.
Статические значения позволяют задать варианты вручную при создании фильтра — так, фильтр по окружению может просто предлагать
dev, staging и prod, без какого-либо запроса. У фильтра со статическим списком нет expression, поэтому он поддерживает только режим переменной и не может быть преобразован в SQL-условие для режима broadcast.
Значения меток PromQL берут варианты из конечной точки <label>/values источника PromQL. Вы выбираете нужную метку и при желании сужаете выборку с помощью матчера, который сам может ссылаться на другие переменные. Так фильтры становятся зависимыми друг от друга: выберите окружение — и список инстансов в следующем фильтре сузится соответствующим образом, а диаграммы PromQL будут фильтроваться по ходу дела.
Оба типа можно предоставить в виде переменных, а значит фильтр может управлять не только предложением WHERE. В демонстрации статический фильтр со списком ServiceName и SeverityText используется как размерность группировки для диаграммы: выбор значения в выпадающем списке меняет то, по какому полю группируется диаграмма, в любых сочетаниях.
Связанные PR: #3017 добавление фильтров со статическим списком значений в схемы и API, #3022 отрисовка полей ввода для фильтров со статическим списком значений, #3020 возможность создавать и редактировать статические списочные фильтры в интерфейсе, #3060 поддержка статических пользовательских фильтров значений в MCP, #3053 поддержка фильтров панели мониторинга на основе значений меток Prometheus, #3072 поддержка автодополнения для фильтров по меткам PromQL, #3039 приём необязательных временных границ в конечной точке значений меток Prometheus, #3079 поддержка match[] в конечных точках меток и значений PromQL, #3080 поддержка match[] в фильтрах по меткам PromQL, #3083 устранение дубликатов меток и значений PromQL для предотвращения сбоя Mantine, #3005 подтверждение перед отменой несохранённых изменений при закрытии редактора фильтров, #3078 поддержка настройки фильтров панели мониторинга как обязательных, #3093 необязательное применение фильтров панели мониторинга к предпросмотру в редакторе tile
Пользовательские шаблоны легенды для диаграмм PromQL
Демо от @pulpdrew
Легенды PromQL было тяжело читать, на что и обратил внимание Vladimir. По умолчанию мы показываем название метрики, а за ним — каждую метку, которая различается у возвращённых серий. Для запроса, возвращающего много серий, получается длинная строка, в которую приходится вчитываться, кликнув по ней.
Теперь в настройках отображения диаграммы можно задать шаблон легенды. Это шаблон Handlebars, поэтому вы ссылаетесь только на действительно нужные вам метки и получаете короткое название серии как в легенде, так и в tooltip.
Если шаблон ссылается на отсутствующую метку, такая ссылка отображается пустой. Если результат пуст или не unique в пределах серий, мы возвращаемся к полному набору различающих меток — так что двух неразличимых серий у вас не получится.
Связанные PR: #3055 поддержка пользовательского шаблона для легенд серий PromQL
Сохранение относительного диапазона дат как значения по умолчанию для панели мониторинга
Демо от @knudtty
Теперь панели мониторинга могут сохранять относительный диапазон дат как значение по умолчанию. Задайте нужный временной диапазон и нажмите «Save Query and Filters as default» — и в дальнейшем панель мониторинга будет открываться именно с этим диапазоном.
Вся суть — в относительных диапазонах. Если сохранить «последние 6 часов», панель мониторинга будет актуальной при каждом открытии, а не привязанной к фиксированному окну, которое быстро устаревает. Диапазон при этом можно менять и во время работы с панелью: посмотреть последние 7 дней, перейти в другой раздел и вернуться к сохранённому значению по умолчанию.
Связанные PR: #3073 относительные диапазоны дат можно сохранять для панелей мониторинга
Оповещения без сохранённого поиска или плитки панели мониторинга
Демо от @wrn14897
Раньше за каждым оповещением должно было что-то стоять: сохранённый поиск для журналов или плитка панели мониторинга для метрик. Такой подход плохо масштабируется, когда вы переносите тысячи оповещений из Grafana.
Встроенные оповещения снимают это требование. В панели действий Chart Explorer появилось действие Create alert: вы можете построить диаграмму по метрикам или событиям и сразу настроить по ней оповещение, ничего предварительно не сохраняя. Встроенное оповещение можно создать и со страницы оповещений — этот путь стоит выбрать, если вы намеренно не хотите связывать оповещение с сохранённым поиском или панелью мониторинга.
Встроенное оповещение хранит собственный
chartConfig в документе оповещения — ровно в той же форме, в какой его сохраняет плитка панели мониторинга, — поэтому обрабатывается тем же путём в коде, что и оповещения плиток, а не параллельным. Поддерживаются и конструктор, и raw SQL для отображений line, stacked_bar и number. PromQL пока не поддерживается.
Та же форма source: 'inline' принимается внешним API v2 и инструментом MCP save_alert — с тем же диалектом конфигурации плиток, что используют панели мониторинга v2, так что оповещения можно создавать программно и в больших количествах. Маршрутизатор переиспользует конвертеры плиток панели мониторинга, благодаря чему две части системы не расходятся между собой.
Связанные PR: #3010 поддержка создания оповещений без сохранённых поисков и плиток панели мониторинга (backend), #3069 интерфейс для создания и редактирования встроенных оповещений по диаграммам, #3043 поддержка оповещений по диаграммам во внешнем API v2 и MCP
Имена и теги оповещений
Демо от @pulpdrew
Теперь у оповещений могут быть собственные имя и теги. Форма оповещения на плитке панели мониторинга или в сохранённом поиске содержит поля для имени и тегов, а новое оповещение по умолчанию получает имя диаграммы или сохранённого поиска и наследует теги той панели мониторинга или того сохранённого поиска, к которым оно привязано.
Именно эти имена отображаются на странице оповещений, и именно по ним выполняются поиск и фильтрация. Для оповещений, которые уже есть в базе данных и не имеют заданного имени, имя по-прежнему берётся из сохранённого поиска или панели мониторинга, на которые они ссылаются.
Теги, возвращаемые конечной точкой
team/tags, теперь включают теги из документов оповещений — наряду с тегами панелей мониторинга и сохранённых поисков. Иначе тег, используемый только в оповещении, не предлагался бы при добавлении тегов к следующему оповещению.
Это задел для постраничного вывода на странице оповещений с сохранением поиска и фильтрации по тегам: для этого имя и теги должны храниться в самом документе оповещения, а не подтягиваться через JOIN с collection панелей мониторинга и сохранённых поисков. Сам постраничный вывод пока не реализован.
Связанные PR: #3063 сохранение displayName и тегов на уровне оповещения, #3065 поддержка записи displayName и тегов оповещения, #3067 отображение и редактирование displayName и тегов оповещения в интерфейсе, #3092 включение тегов оповещений в ответ API тегов, #3029 дозагрузка имени и тегов оповещения (открыт)
Прототип Explore
Демо от @elizabetdev
Это исследовательская работа, и обязательств выпустить её мы не даём.
Прототип — это единая страница Explore, которая заменила бы сразу и страницу поиска, и explorer диаграмм. Пока он существует в виде черновика в репозитории HyperDX. Он может заменить эти страницы, может остаться рядом с ними третьей страницей, а может и вовсе ни к чему не привести.
Он призван решить проблему постоянных переходов между двумя имеющимися сегодня страницами. Пользователи говорят, что переносить вопрос из поиска в explorer диаграмм неудобно: часто приходится заново выбирать источник данных и пересобирать тот же запрос. Explore оставляет всё на одной странице, переключая представление между событиями, шаблонами, дельтами и диаграммами, а не подменяя страницу целиком.
Вторая тема — снижение порога входа для тех, кто не владеет языками запросов свободно. Добавление столбца в таблицу, сортировка и выбор группировки выполняются через выпадающие списки, но SQL по-прежнему под рукой, если он нужен. Группировка — хороший пример нынешнего пробела: гистограмма на странице поиска сгруппирована по коду состояния без возможности это изменить, поэтому всем, кому нужна другая группировка, приходится уходить в explorer диаграмм. Здесь же вы задаёте группировку в представлении событий, переключаетесь на диаграмму временных рядов или столбчатую диаграмму, когда небольшой гистограммы недостаточно, меняете агрегацию на что-нибудь вроде
p99 и сохраняете результат на панель мониторинга.
Панель фильтров — это небольшой query builder, скрывающий и Lucene, и SQL: выберите поле, выберите оператор, введите значение, а продвинутым пользователям доступны полноценный редактор запросов и macros. Нужны ли вообще два языка запросов — один из открытых вопросов.
Многое пока не решено. PromQL ещё нет, и неясно, место ли метрикам на этой странице или это уже слишком большая нагрузка для одной страницы. Прототип сосредоточен на работе с журналами и трассировками.
Мы будем рады вашим отзывам.
Связанные PR: #2985 Explore как визуализация с приоритетом поиска (прототип) (открыт)