Grafana: График: пределы автомасштабирования по оси Y (мин. Макс.)

Спасибо, интересная идея. Кажется, небольшой крайний случай. Но согласен, временами может быть полезно.

Да, я просто хотел изложить свои мысли на бумаге. :пиво:

Не думаю, что это крайний случай.
Установите автоматическое масштабирование. Установите 0–100 в качестве минимального значения, но позвольте графику масштабироваться по своему усмотрению. Это несколько раз вызывало панику среди директоров и вице-президентов, пока я не убедил их оценить масштабы этого.

+1 Многие данные временных рядов, которые я визуализирую в графане, находятся на нулевом уровне + шум, и это делает графики беспорядочными и нечеткими.

+1 от пользователя Grafana.net.

Минимальный масштаб может помочь для таких вещей, как сетевые интерфейсы, где некоторые из наших частных / vpn-каналов неактивны (~ 20 Кбит / с), но при использовании 50-100 Мбит / с. Если я установил масштаб на 100 Мбит / с, и все закончилось, я не знаю, а если я установлю его на 200 Мбит / с, я не смогу четко видеть данные, когда они только 5-10 Мбит / с.

Я понимаю, что эта функция, вероятно, полезна только очень немногим людям. Но я немного взломал это. И я придумал кое-что, что мне подходит. Коммит в моей вилке добавляет поле Y-Span на вкладку Axes.

Где X - целое число или число с плавающей запятой:

~X Span X around average
=X Span X around current value
>X Span is atleast X
<X Span is clamped to X

https://github.com/thoj/grafana/commit/7dcdccbd42e9f63b7388e439f7194fe7ead8039a

Пример, зачем мне это нужно:

Есть интерес к PR?

@thoj Это было бы отличным дополнением. Мы используем пороговые значения для некоторых графиков и хотели бы показывать их всегда, но все же масштабируем график, чтобы отображать точки, намного превышающие пороговое значение. "> X" здесь будет хорошо работать (и

@lpalm Ага! Я добавлю запрос на перенос, чтобы попытаться начать обсуждение,

реализовано в https://github.com/grafana/grafana/pull/6051

Это в шлейфе выпуска 4.0.x? Я пытаюсь использовать «<» и «>» в ​​настройках оси Y, но безуспешно.

не нужно было возвращать его, мы хотели более удобный ввод / пользовательский интерфейс, чем просто скрытая функция, что поле ввода поддерживает такие выражения, как > и < поэтому функция была возвращена в ожидании времени, чтобы выяснить пользовательский интерфейс

Может ли это быть в дропбоксе, кроме Y-min и Y-max?

Привет,

Я создал эту функцию для графитового проекта некоторое время назад и пришел к следующему выводу, что я никогда не хотел бы использовать yMax , так как я всегда хочу знать значения графика, чего я не буду с yMax .
Есть ли кто-нибудь, кто думает, что yMax - полезная функция или нужно ли просто перепроектировать yMax для работы как

Я имею в виду, если я установлю yMax на x, а счетчик превысит x, разве кто-нибудь не захочет увидеть, насколько он превысил лимит?

Я использую yMax, когда у меня есть проценты, чтобы убедиться, что 100% всегда находится точно в верхней части графика (даже если есть небольшая отметка)

Мне также нужно yMax. Это связано с некоторыми зашумленными сигналами с очень высокими пиками, искажающими графики.

@iksaif да, но это не требует исправления yMax. Поскольку ваш график никогда не превысит 100% и ваш динамический yMax, тогда будет 100% ваш график будет выглядеть точно так же, как с текущей реализацией yMax ?

@thoj , это не похоже на надежную метрику? Разве вы вместо этого не хотели бы, чтобы эти всплески были исключены из графика, или, если они вам важны, действительно знаете значение?

@Kvistian , да, бывает, по причинам, что он отображает 100,02%, и мне нравится, что я могу это ограничить.

Также бывают случаи, когда я хочу видеть только то, что я хочу «увеличить», и я могу использовать для этого yMax.

Хорошо, но вы согласны с тем, что в большинстве случаев потребуется динамический yMax ? В таком случае, имеет ли смысл сделать yMax динамическим и новую функцию, например staticYMax или fixedYMax, для этих крайних случаев? Таким образом, использование динамического yMax по умолчанию, поскольку это общий вариант использования.

Похоже, что установка нижней границы верхней части графика может быть полезной, но я бы не стал менять семантику существующего yMax (который на самом деле является максимальным y, который может отображаться).

Было бы интересно узнать, как эта штука называется в другом подобном софте.

@Kvistian Не все хотят использовать графану только для отображения хороших чистых показателей с серверов. Я хочу отображать метрики физических процессов, которые являются шумными и иногда могут возвращать странные данные. Вот мои примеры и объяснения: https://github.com/grafana/grafana/pull/5720

@thoj Я не предлагал удалять его, если это полезная функция, я просто спросил, есть ли это. Но похоже, что для него есть несколько вариантов использования, поэтому в этом случае его не следует удалять. Но лично я считаю, что должно быть больше случаев, когда вам нужен динамический yMax решит мою проблему (поскольку я не видел никакого полезного случая для фактического статического yMax ). В конце концов, это просто проблема с именами.

Мне все равно, называется он yMax или minYMax , просто подумал, что yMax больше похож на функцию default которая должна решать наиболее распространенный вариант использования.

Я показываю значение состояния заряда батареи (SOC), и мне бы очень понравилась возможность устанавливать верхний и нижний предел при сохранении автоматического масштабирования в этих пределах.

Вот несколько изображений проблемы, с которой я сталкиваюсь, устанавливая или не устанавливая значение Y-Max.

Если я _ не_ устанавливаю значение Y-Max, то график показывает значения SOC по шкале Y> 100%, чего никогда не будет. Другими словами, в случае состояния заряда аккумулятора:

0% <= y_scale_values <= 100%

Если я _do_ установил значение Y-Max, тогда, когда у меня низкие значения SOC в течение длительного времени, график не масштабируется автоматически, как показано на изображении ниже.

Я хотел бы иметь возможность установить верхний (100%) и нижний предел (0%), но при этом автоматически масштабировать график в этих пределах, как это происходит в момент, когда пределы Y не установлены.

Просто добавляем наш вариант использования. Мы отслеживаем веб-сайт и имеем базовый уровень трафика проверки работоспособности для «рабочих» экземпляров, который я хотел бы отображать в виде графической «нижней» линии графика (например, 0,1 запроса / сек, но по оси будет минимум 1, в то время как по-прежнему позволяя оси графика увеличиваться при поступлении «реального» трафика.

Есть хитрость, чтобы иметь минимальное максимальное значение оси Y.

Создайте метрику Baseline для желаемого минимального масштаба. Здесь я выбрал единицу для процессорного времени:

Добавьте переопределения для базовой метрики, чтобы она исчезла с графика:

Вот и все.

Единственный недостаток в том, что вы можете видеть базовую линию, наведенную на нее:

Мне это также нужно для отображения ввода-вывода.

например, скорость чтения может составлять 50 кб / мин или 500 МБ / мин, установка некоторого минимального масштаба - например, 100 МБ / мин по умолчанию сделает мои графики более согласованными.

+1
Пожалуйста?

@dstensnes Пожалуйста, не оставляйте в этой форме комментарии по вопросам на GitHub. Вы можете добавить реакцию на исходный пост, чтобы показать, что вам нужна эта функция. Когда вы комментируете +1, все, кто следит за этой проблемой, получают уведомление по электронной почте без какой-либо соответствующей информации. Это просто дурной тон.

Хорошо, я могу с этим жить :) Кто-нибудь хоть когда-нибудь смотрит на реакцию? Я заметил, что вы можете сортировать по количеству реакций, так что это хоть что-то. благодаря

Я думаю, что для большинства случаев использования людей можно будет добавить флажок «мягкий предел» рядом с полями Y-Min и Y-Max. Если вы переместите Y-Max на следующую строку, должно быть достаточно места как для флажка, так и для метки, а функциональность должна быть довольно понятной :)

Я не уверен, как это можно считать пограничным случаем, основное приложение, которое у нас есть, - это сетевой трафик, но на большинстве графиков вы не хотите видеть крошечные значения, показанные как «горы».

есть ли в настоящее время обходной путь для этого?

Есть обновления к этому? Это очень затрудняет настройку хороших информационных панелей.

Одна из идей пользовательского интерфейса:

• YMax (мягкий) - вершина графика всегда простирается, по крайней мере, здесь
• YMax (сложно) - верхняя часть графика никогда не выходит за пределы этого
• YMin (мягкий) - нижняя часть графика всегда простирается как минимум до этого
• YMin (сложно) - нижняя часть графика никогда не выходит за пределы этого места

Другой подход к этому может быть минимальным диапазоном для оси Y, определяющим, что диапазон от текущего Y-low до Y-high никогда не должен быть меньше заданного значения. Таким образом, рендеринг можно установить, где ось y должна начинаться и заканчиваться - и в то же время избегать незначительных изменений в значениях, которые будут отображаться в виде гор.

Я тоже считаю, что это очень распространенная проблема с зашумленными данными, и большинство данных зашумлены.

Я думаю, что настоящая проблема в том, что выбросы искажают масштаб оси Y, в результате чего все остальное исчезает. На мой взгляд, правильное решение состоит в том, чтобы позволить диапазону оси Y быть динамическим на основе отображаемых данных при обрезке экстремальных значений выбросов. Лучший способ сделать это - основать диапазон на стандартных отклонениях от среднего значения отображаемых данных. Например, если установить 1 стандартное отклонение, на графике будет обрезано все, что более чем на 1 стандартное отклонение выше среднего. Это легко настроить и легко вычислить на стороне клиента, поэтому он не зависит от источника данных и будет достаточно легким для понимания людьми.

Почти 2 года назад:

вернул функцию в ожидании времени, чтобы выяснить пользовательский интерфейс

Пожалуйста, верните > и < пока рассматривается возможность улучшения пользовательского интерфейса.

Очень жду такой фичи, как ту, что убрали 2 года назад!

Даже шаблонные диаграммы, которые отслеживают одну и ту же метрику в разных системах, бок о бок дают неточную визуализацию, поскольку шкалы автоматически настраиваются независимо, основываясь исключительно на текущих данных на диаграмме.

Есть хитрость, чтобы иметь минимальное максимальное значение оси Y.

Создайте метрику Baseline для желаемого минимального масштаба. Здесь я выбрал единицу для процессорного времени:

Добавьте переопределения для базовой метрики, чтобы она исчезла с графика:

Вот и все.

Единственный недостаток в том, что вы можете видеть базовую линию, наведенную на нее:

Для тех, кто читал полезный обходной путь @bobrik , в наши дни вы также можете скрыть элемент baseline из всплывающих подсказок в переопределении.

@bobrik @ sb3tcs Привет, я хотел бы использовать ваш обходной путь, но Grafana заканчивает синтаксической ошибкой запроса, если все, что я ввел в запрос, - это просто 20 или другое число. Как создать базовую метрику? Или моя Grafana 5.1 слишком стара, чтобы поддерживать такого рода запросы?

Я использовал несколько связанных функций во втором запросе, чтобы графики не увеличивались слишком сильно по оси Y.
В этом примере я рисую на одном графике зарегистрированных пользователей с нескольких серверов.

Я добавил дополнительный запрос с теми же точками данных:
смещение (-20) aggregateBy (1m, min) removeBelowValue (0) setAlias ​​(hidden_min)

Это изменяет динамическое масштабирование с
мин до макс
к
мин-20 (не переходя в минус) до макс.

Чтобы скрыть поддельный график:
переопределение визуализации с помощью регулярного выражения "/hidden_.*/"
Линии: false
Легенда: ложь
Скрыть во всплывающей подсказке: true

Возможно, вы даже могли бы синхронизировать ось Y между несколькими графиками. Как панель для каждого сервера и собирать минимальные / максимальные значения из точек данных всех серверов на каждой панели.

Я нашел другое решение. Я только что добавил минимальную и максимальную таймсерии с тегами min и max. Линия была такой
weather,sensorID=min temperature=0
weather,sensorID=max temperature=20
Они добавляются к графику и скрываются, как указано выше. Единственная проблема в том, что вам нужно регулярно вводить его.
Вот как это выглядит, возможно, потребуется установить максимальную температуру на 19, чтобы она автоматически настраивала ось на 20.

Изменить: вставьте max как 19, и это сработало.

Я наткнулся на эту ветку в поисках решения для установки гибкого y-max в Grafana. В моем случае я рисую график задержки и объема запроса для API. Я хочу установить гибкий y-max примерно на 500 мс (0,5 секунды), чтобы я мог лучше видеть нюансы вызовов с более низкой задержкой, исключая резкие выбросы и автоматически настраивая y-max, когда максимальная задержка ниже этот порог.

Я попытался установить: y-min на 0 и y-max на <0,5, но тогда моя ось y либо полностью исчезла, либо игнорировала y-min. Эта проблема возникла независимо от графика задержки и запросов объема запросов вместе / отдельно. Есть ли какие-то новые успехи в этом вопросе? Это было бы действительно полезно для моей команды.

Я прилагаю несколько снимков экрана моего графика с разными настройками y-max (каждый случай отмечен заголовком графика)

если вы не хотите отображать значения выше 500 мс, вы можете попробовать использовать removeAboveValue (0.5)
затем сообщите графику, как следует обрабатывать нулевые значения

не знаю, есть ли способ использовать вычисленные параметры для этой функции

Немного более современный обходной путь базового плана выглядит следующим образом:

Это останавливает отображение базового запроса в графике, легенде и всплывающей подсказке, а также предотвращает возникновение проблем с наложением.

На самом деле это не крайний случай, а, скорее, очень распространенный случай. Я действительно думаю, что очень часто требуется ось Y с "мягкими" минимальными / максимальными значениями. Основная причина установки шкалы оси Y заключается в том, что нужно выровнять ее с ожидаемым диапазоном данных, а также иметь несколько графиков с выровненной осью Y, чтобы можно было легко сравнивать значения.

Было бы интересно узнать, как эта штука называется в другом подобном софте.

Highchartjs называет это softMin / softMax.
https://api.highcharts.com/highcharts/yAxis

AnyChart называет это мягким мин. / Макс.
https://docs.anychart.com/Axes_and_Grids/Scales#soft

В Chartjs есть опция «предложенное мин. / Макс.» Для обработки этого варианта использования.
https://www.chartjs.org/docs/latest/axes/cartesian/linear.html#axis -range-settings

amCharts называет их min / max и strictMin / Max.
https://www.amcharts.com/docs/v4/reference/valueaxis/#strictMinMax_property

RRDtool, например, имеет «мягкие» ограничения по умолчанию при использовании автомасштабирования, но имеет параметр rigid который устанавливает «жесткие» ограничения на масштаб.

[-u | --upper-limit value] [-l | --lower-limit value] [-r | --rigid] [--allow-shrink]

По умолчанию график будет автоматически масштабироваться, так что ось Y будет регулироваться в соответствии с диапазоном данных. Вы можете изменить это поведение, явно установив пределы. Отображаемая ось Y будет располагаться по крайней мере от нижнего до верхнего предела. Автомасштабирование по-прежнему позволяет растягивать эти границы, если не задана опция жесткости. allow-shrink изменяет поведение жесткого диска, разрешая автоматическое уменьшение масштаба, график не выходит за указанные пользователем пределы.
https://oss.oetiker.ch/rrdtool/doc/rrdgraph.en.html

Tableau имеет функцию, позволяющую разрешить единый диапазон оси для всех строк или столбцов, и вы можете сделать это, например, только для оси y. Это решает проблему немного по-другому, но это все тот же случай использования, когда нужно, чтобы несколько диаграмм имели один и тот же диапазон / масштаб оси.

Хотя многие дискуссии по этому поводу были сосредоточены на реализации отдельных мягких минимальных и максимальных значений для масштабирования, я думаю, что есть большая ценность в реализации функции «минимального диапазона оси Y» как части этого, в отличие от «мягкого "мин. / макс., как предлагалось на оригинальном плакате. Мягкие минимумы и максимумы будут использоваться для определения фиксированных положений по оси Y, которые всегда должны быть видны во время автоматического масштабирования. Это можно использовать, когда у вас есть известный диапазон значений оси Y, которые вы всегда хотите видеть видимыми, что полезно для предотвращения появления небольших отклонений в виде преувеличенных пиков и впадин из-за эффекта масштабирования при автоматическом масштабировании. Однако это работает только в том случае, если вы знаете, какими будут значения по оси Y во время разработки, что не всегда так, особенно для людей, создающих шаблоны для использования конечными пользователями, у которых может быть другое оборудование и схемы нагрузки.

Параметр минимального диапазона оси Y для автоматического масштабирования устранит это требование. При использовании в наборе значений, где диапазон данных (например, abs(max(Y)-min(Y)) ) не превышает настроенный минимальный диапазон оси Y, минимальные и максимальные значения по оси Y будут установлены таким образом, чтобы данные центрируется по вертикали. Это позволяет избежать проблемы преувеличения небольших отклонений, поскольку разработчику графиков не нужно заранее знать точные значения оси Y.

Небольшой фрагмент псевдокода для демонстрации расчета:

minRange = 25
dataRange = abs(max(Y)-min(Y))
if dataRange < minRange:
    yAxisExtension = (minRange - dataRange) / 2
    yAxisMin = min(Y) - yAxisExtension
    yAxisMax = max(Y) + yAxisExtension

Такой подход не будет выталкивать выбросы за пределы шкалы, в отличие от центрирования среднего значения.

В качестве примера использования представьте, что вы разрабатываете приборную панель для мониторинга данных из NUT / upsd и составляете график энергопотребления. В то время как мой ИБП может в среднем 400 Вт, у кого-то может быть в среднем 100 или 1000 Вт, в зависимости от того, как выглядит их оборудование. Это невозможно узнать заранее. Однако количество потребляемой мощности обычно довольно постоянное в течение короткого промежутка времени, что означает, что оно склонно к преувеличению оси Y при выполнении автомасштабирования. Это идеальный вариант использования для минимального диапазона по оси Y, когда вы можете сделать разумные предположения о масштабе дисперсии за данный период времени, но не о величине абсолютного значения.

Если датчик имеет ограниченное разрешение, все, что вы видите, - это шум квантования, когда величина очень мало меняется в выбранном временном интервале. Я хотел бы, например, видеть минимальный диапазон по оси Y, чтобы не слишком сильно усиливать этот шум квантования на графике.
В случае небольшого диапазона значений y как по левой, так и по правой осям Y было бы неплохо «подтолкнуть» центр одной оси Y к верхней половине, а центр другой оси Y к нижней. половина. Будет подавлено ненужное пересечение значений Y слева и справа. Конечно, если обе оси Y показывают одинаковую величину, оси не должны перемещаться таким образом, но уже есть опция «синхронизировать оси Y».