Grafana: [Запрос функции] Несколько предупреждений на график

Конкретный вариант использования: я настроил свое приложение для записи гистограммы в Prometheus для каждой основной функции (например, когда происходит внешний HTTP-вызов или дисковый ввод-вывод) и хотел бы предупреждать, когда какая-либо из них замедляется.

В настоящее время я должен определить для этого фиктивные графики из-за соотношения 1: 1 между графиком и предупреждением. Гораздо логичнее было бы хранить оповещения в том же месте, что и сам график.

А вы не можете определить это в одном запросе?

Нет; цепочка условий OR грубая, и одно название оповещения не может четко определить точную причину оповещения. Я определенно не хочу отправлять оповещения типа Some part of service X is failing — дежурные инженеры не будут моими друзьями...

тогда имеет смысл иметь отдельные панели для оповещений, если вы хотите отдельное имя правила оповещения и сообщение и т. д.

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

это очень маловероятно

может быть, если есть огромный спрос на это :)

ха-ха, хорошо, я посмотрю, смогу ли я поднять разъяренную толпу ;) Серьезно, спасибо за честность.

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

и у каждого танка разные пороги или уведомления?

Точно. Один из них представляет собой бак для мазута на 285 галлонов. Я хотел настроить оповещение о низком уровне мазута, когда этот бак опускается ниже 70 галлонов. Другой - баллон с пропаном на 500 галлонов, для которого я хотел получить предупреждение о низком уровне пропана, когда он опускается ниже 100 галлонов. Я настроил одиночную статистику для каждого, но оповещения недоступны в одиночной статистике.

У меня есть график с медианой и метрикой 90-го процентиля. Я хотел бы получать оповещения о каждом. Для этого мне нужно создать по одному графику для каждого. Затем, если мне нужны предупреждения и критические оповещения для каждого, я должен создать второй график для каждого.

У меня есть 30 или 40 сервисов для мониторинга, каждый из которых имеет от 2 до 5 ключевых показателей. У меня есть графики, на которых я отображаю одну и ту же метрику для нескольких клиентов, и хотя мне не нужно делать оповещения для каждого клиента (пока), это увеличивает количество метрик, по которым я хотел бы получать оповещения. Объем работы по созданию десятков графиков увеличивается очень быстро. В моей текущей производственной среде (и в моих предыдущих производственных средах) было бы очень полезно иметь предупреждения и критические предупреждения, а также отображать несколько показателей на одном графике и предупреждать о них.

Я бы тоже хотел увидеть эту функцию. Хорошим примером является одно оповещение, если метрика выходит за пороговое значение, и другое оповещение, если данные не обновляются. I.e., если значение становится слишком высоким или если значения не сообщаются. Это можно использовать, чтобы показать, что тот, кто сообщает данные, столкнулся с проблемой, препятствующей обмену данными с grafana (или любым другим бэкэндом).

Привет Торкело!

Я получил несколько "лайков" за эту функцию! Войдем ли мы в следующий релиз =) ?

@rmsys , возможно, в какой-то момент, решение этого с точки зрения UX и сложности кода (и сложности UX) потребует времени, этого еще нет в дорожной карте, но, возможно, в следующем году, когда механизм оповещения станет более зрелым, и дизайн UX для этого будет разработан. вне

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

У меня есть график, который возвращает метрику со значением valid и invalid . Это было бы полезно для меня, потому что я мог бы использовать один график, содержащий два запроса, для создания оповещений, которые срабатывают, когда valid слишком низкие, а invalid слишком высокие.

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

Не уверен, что понимаю, что вы имеете в виду под этим. Можете ли вы уточнить?

Можете ли вы описать, как будут работать и выглядеть несколько предупреждений на графике? Что будут говорить аннотации и зеленое/красное сердце рядом с заголовком панели (если, скажем, 2/5 правил оповещения при срабатывании)?

Хотите ли вы поделиться чем-то между правилами предупреждений или они будут полностью изолированы (кроме того, что они живут на одной панели графика и, возможно, ссылаются на одни и те же запросы).

Как бы вы визуализировали пороговые значения, если у вас есть несколько правил оповещения? Будут ли они отображаться как отдельные правила на странице правил предупреждений и на панели списка предупреждений? Затем вам нужен способ перейти к конкретному экземпляру правила, а не только к вкладке предупреждений.

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

@rssalerno , поддерживающий правила предупреждений в панели singlestat, кажется, не имеет отношения к этой проблеме.

@alex-phillips Ваш сценарий звучит так, как будто его можно решить, сделав отдельные правила предупреждений более гибкими.

Есть ли у кого-то конкретные примеры, где это было бы хорошо? Просто не увидеть сценарий, в котором это закончится запутанным графиком с 2-5 пороговыми значениями, которые, как вы не знаете, относятся к каким метрикам и аннотациям истории предупреждений, которые вы также не знаете, из какого правила предупреждений они пришли (без зависания).

Можете ли вы описать, как будут работать и выглядеть несколько предупреждений на графике? Что будут говорить аннотации и зеленое/красное сердце рядом с заголовком панели (если, скажем, 2/5 правил оповещения при срабатывании)?

Я думаю, что несколько правил предупреждений будут аннотированы индивидуально. Сердца могут иметь цветовую кодировку. Правила должны быть названы для дифференциации в предупреждениях/панелях.

Хотите ли вы поделиться чем-то между правилами предупреждений или они будут полностью изолированы (кроме того, что они живут на одной панели графика и, возможно, ссылаются на одни и те же запросы).

Как правило, я бы так не думал, хотя подозреваю, что у групп должен быть общий порог и имя, если они были реализованы (согласно https://github.com/grafana/grafana/issues/6557#issuecomment-324363795).

Как бы вы визуализировали пороговые значения, если у вас есть несколько правил оповещения? Будут ли они отображаться как отдельные правила на странице правил предупреждений и на панели списка предупреждений? Затем вам нужен способ перейти к конкретному экземпляру правила, а не только к вкладке предупреждений.

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

@rssalerno , поддерживающий правила предупреждений в панели singlestat, кажется, не имеет отношения к этой проблеме.

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

Есть ли у кого-то конкретные примеры, где это было бы хорошо? Просто не увидеть сценарий, в котором это закончится запутанным графиком с 2-5 пороговыми значениями, которые, как вы не знаете, относятся к каким метрикам и аннотациям истории предупреждений, которые вы также не знаете, из какого правила предупреждений они пришли (без зависания).

Прежде всего, я бы хотел, чтобы это поддерживало #6557 и #6553, а также для нескольких порогов, как @alex-phillips. Например, один вариант использования, который у нас есть для #6557, заключается в том, чтобы по-разному предупреждать для разных сред ( production , beta , dev и т. д.) в сочетании с несколькими пороговыми значениями, которые решить большинство наших проблем. Если есть лучший способ сделать это без нескольких правил, для меня это неочевидно.

@торкело

Можете ли вы описать, как будут работать и выглядеть несколько предупреждений на графике? Что будут говорить аннотации и зеленое/красное сердце рядом с заголовком панели (если, скажем, 2/5 правил оповещения при срабатывании)?

Мне нравится подход, предложенный @pdf

Кроме того, подход к отображению аннотаций будет таким же, как и в текущем случае, когда у вас есть правило оповещения с > 1 условиями (каждое из которых имеет разные пороговые значения). И зеленое/красное сердце рядом с заголовком панели будет отображаться красным (если есть хотя бы одно предупреждение, которое срабатывает), аналогично текущему сценарию, где хотя бы одно условие правила предупреждения оценивается как истинное). И, вероятно, также показать число (2/5) вместе с красным сердцем в названии.

Хотите ли вы поделиться чем-то между правилами предупреждений или они будут полностью изолированы (кроме того, что они живут на одной панели графика и, возможно, ссылаются на одни и те же запросы).

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

Как бы вы визуализировали пороговые значения, если у вас есть несколько правил оповещения? Будут ли они отображаться как отдельные правила на странице правил предупреждений и на панели списка предупреждений? Затем вам нужен способ перейти к конкретному экземпляру правила, а не только к вкладке предупреждений.

Они будут отображаться как отдельные правила на странице предупреждений. На вкладке «Предупреждение», вероятно, будет определен список предупреждений. Верно, нам нужно выделить/развернуть конкретное правило оповещения на этой вкладке, когда URL-адрес правила оповещения (должен фиксировать идентификатор или индекс оповещения) будет доступен из уведомления. Вроде бы легко разрешима.

На панели списка предупреждений не будет никаких изменений. Показывает все по отдельности. Семантически каждое оповещение является отдельным. Просто он был помещен в ту же панель.

Есть ли у кого-то конкретные примеры, где это было бы хорошо? Просто не увидеть сценарий, в котором это закончится запутанным графиком с 2-5 пороговыми значениями, которые, как вы не знаете, относятся к каким метрикам и аннотациям истории предупреждений, которые вы также не знаете, из какого правила предупреждений они пришли (без зависания).

Учитывая, что многие люди проголосовали за эту функцию, она определенно будет полезной. Если у нас будет поддержка нескольких предупреждений, то я думаю, что каждый пользователь будет сам решать, сбивает это с толку или нет. ИМХО, те, кто считает, что это сбивает с толку, будут использовать текущий подход с отдельными панелями для каждого графика, а те, кто считает, что полезность/удобство использования одной и той же панели для визуализации и оповещения перевешивает предполагаемую путаницу, пойдут по пути множественных оповещений. . Конечно, это несколько изменит UX.

В splunk у нас есть оповещения о высоком/низком уровне. Если бы в grafana было доступно несколько предупреждений, мы бы просто использовали один и тот же поиск, это просто разные пороги для одного и того же поиска.

+1 за эту функцию.

+1 за это. Наш вариант использования следующий: мы хотим определить одну диаграмму, скажем, с использованием процессора для всех наших серверов. Затем на той же диаграмме мы создадим две скрытые метрики: одну для использования ЦП на рабочих серверах и одну для использования ЦП на непроизводственных серверах. Каждая из этих метрик будет иметь собственное предупреждение с разными каналами уведомления. Мы не хотим создавать несколько диаграмм, панелей или информационных панелей для достижения этой цели.

+1 за эту функцию.

Пришел сюда, чтобы прочитать некоторые другие вопросы, касающиеся категорий и серьезности. Я согласен, что все предупреждения должны быть действенными. Но есть разница между предупреждением «решить это первым делом с утра» и предупреждением «вызовите консультанта за 400 долларов в час как можно скорее».

Как уже упоминалось, это чаще всего решается пороговыми значениями Предупреждения и Критического.

Технически это может быть реализовано множеством способов, метками, несколькими алертами на панель, несколькими порогами на алерт и т. д.

Что касается путаницы, если категоризация слишком сложна, в настройке «Предупреждение/Критика» можно просто использовать красный/желтый. Красный превалирует над желтым.

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

Я думаю, что большинство пользователей будет удовлетворено довольно простым разделением Warn/Crit.

Это абсолютно необходимо для программного обеспечения оповещения, особенно для мониторинга сервера. Дисковое пространство, память, загрузка процессора, температура, средняя загрузка .... все основные примеры, когда нужно настроить несколько предупреждений с разными сообщениями с разными пороговыми значениями. Возьмем, к примеру, место на диске. Нужно одно оповещение при использовании диска более 70%, другое при использовании диска более 90%.

Немного крайний случай, но мы используем оповещения, чтобы уведомить нас, если продукт не был продан в течение нескольких дней. У нас есть каждый продукт в качестве метрики, что, в свою очередь, означает, что мы получаем только одно предупреждение, когда одна из метрик достигает порога предупреждения. В идеале мы хотели бы получать оповещение, если оповещение показывает, что какая-либо дополнительная метрика также достигла порога оповещения.

Также мы используем переменные шаблонов, чтобы повторить график для каждого выбранного продукта с наложением двух показателей (объем и валовая прибыль) на левую и правую оси Y. Это убивает любую возможность использования предупреждения, поскольку запрос предупреждения не получает переменную списка $sku для нашего IN ($sku) .

Чтобы обойти это, я попытался использовать другой запрос B , который просто запускает запрос шаблона для поиска всех интересующих нас артикулов и помещает это прямо в запрос предупреждения IN (SELECT skus from interested_product_table) . Однако это начинает отправлять нам оповещения для каждого графика для всех показателей на каждом графике, что означает, что мы получаем:

Email Alert 1 - metric1,metric2,metric3
Email Alert 2 - metric1,metric2,metric3
Email Alert 3 - metric1,metric2,metric3
Email Alert 4 - metric1,metric2,metric3

Email Alert 5 - metric4
Email Alert 6 - metric4
Email Alert 7 - metric4
Email Alert 8 - metric4

Например, это довольно спам.

Полностью согласен с тем, что эта функция является обязательной, и совершенно не согласен с тем, что ВСЕ уведомления должны быть действенными.

Самый простой пример: у вас могут быть оповещения, которые вы получаете, и вам нужно как можно скорее предпринять какое-то действие, например, на следующее утро, в то время как есть другие типы оповещений, которые должны заставить вас вставать даже посреди ночи, чтобы исправить рабочие серверы.

Добавляю свои пять копеек - я бы хотел иметь эту функцию.

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

Пожалуйста, добавьте эту функцию. для такого варианта использования,
из одного графика
если значение > X --> резерв
если Значение > X+Y --> PD

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

Например: ЦП RDS слишком слаб? проверьте поведение другого стека здесь. Слишком высоко? Масштабируйте экземпляр.

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

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

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

Возможно, стоит вернуться к идее привязки предупреждений к графику? Возможно, оповещения следует создавать отдельно, с красивым графиком предварительного просмотра при создании оповещения. Это разъединение может сделать его более трудоемким при изменении метрики графика, но, по крайней мере, у него будет больше гибкости при создании нескольких предупреждений.

Я пытался использовать Grafana + Influx для сенсорных сетей. Панели инструментов работают довольно хорошо, за исключением предупреждений. Мне нужно получать оповещения, когда Sensor123 превышает определенный порог. Для этого мне не нужна диаграмма, просто предупреждение. Кроме того, мне нужно потенциально иметь 1000 датчиков. Я могу настроить оповещение, если «какой-либо» датчик превышает пороговое значение, но мне нужно знать, какой из них выдает/предупреждает. У меня настроены информационные панели с переменными шаблона для просмотра определенного датчика, но я не могу добавить оповещение для переменной шаблона. Для тестирования я просто настроил несколько предупреждений для нескольких датчиков на дополнительной панели, на которую никто не смотрит, но в дальнейшем мне нужно другое решение для предупреждений.

@torkelo , приближается год с момента официального комментария по этому поводу - просто интересно, есть ли какие-либо обновления, которыми можно поделиться сейчас, когда система оповещения уже какое-то время находится в дикой природе?

@MakoSDV , вам следует рассмотреть возможность использования конденсатора для этого случая использования.

+1 за эту функцию; это было бы очень полезно также для двухуровневого оповещения (например: что-то> X = желтое предупреждение, что-то> Y = красное предупреждение)

+1 за более гибкое оповещение

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

Жаль, что эта проблема кажется заброшенной. Кто-нибудь знает, как мы можем привлечь к этому внимание разработчиков?

Похоже, что с точки зрения пользовательского интерфейса было бы сравнительно легко реализовать оповещения так, как реализованы переопределения, чтобы разрешить одно или несколько оповещений без особых изменений пользовательского интерфейса.

@Gaibhne написал:

Кто-нибудь знает, как мы можем привлечь к этому внимание разработчиков?

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

+1 за этот запрос.

В нашем приложении настроен счетчик, когда запрос к внешней службе, которую мы интегрируем, имеет время ожидания, для которого мы создали график в Grafana.

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

+1 и за это.

В настоящее время пытаюсь настроить два отдельных оповещения для графика:

1. Slack-сообщение для данных, достигших уровня _warning_
2. Оповещение Pager Duty для данных, достигающих _критического_ уровня

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

@torkelo есть какие-нибудь новости о планах на 2019 год?

+1

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

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

Было бы здорово, даже если бы требовалось использовать разные запросы для каждого оповещения и просто настроить запрос так, чтобы он не отображался на графике.

То, что вы описываете @itonlytakesvon , похоже, также относится к https://github.com/grafana/grafana/issues/6557, так что вы можете отслеживать и это :)

Как это еще не функция?

@jsterling7 прекрасно описывает наш желаемый вариант использования.

@torkelo Любой выпуск функции

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

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

Мой вариант использования аналогичен другим, упомянутым здесь, и проблеме № 6557. У нас есть несколько кластеров elasticsearch, которые отслеживаются на единой информационной панели шаблона. Я хотел бы запускать оповещения для них по отдельности, и сейчас я не могу просто создать график с жестко закодированными запросами, но должен создать график для каждого кластера, чтобы эти оповещения работали...

+1, это здорово поможет нашей окружающей среде! Даже просто желтое/красное «сердце» с двумя предупреждениями на настройку графика, где, если срабатывает красный цвет, он переопределяет желтый.

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

+1 это было бы очень полезно и для нас. У нас есть множество информационных панелей с шаблонами для нескольких переменных, было бы здорово, если бы подстановка шаблонов выполнялась как для имени оповещения, так и для уведомления об оповещении.

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

+1 и от меня - удивлен, что этого еще не существует!

+1

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

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

Я хотел бы получать отдельные оповещения для каждого значения шаблона, но я ограничен одним оповещением с общим универсальным действием + сообщением. Я могу использовать длинный список ИЛИ для оповещения обо всех моих запросах, но это кажется грубым.

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

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

+1. Это необходимая вещь!

+1 Это очень полезно

@torkelo «тогда имеет смысл иметь отдельные панели для предупреждений, если вы хотите отдельное имя правила оповещения и сообщение и т. д.»

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

@torkelo «тогда имеет смысл иметь отдельные панели для предупреждений, если вы хотите отдельное имя правила оповещения и сообщение и т. д.»

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

Точно. +1 за несколько оповещений на панель

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

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

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

На данный момент нам нужно запрограммировать 16 операторов x OR для серии ячеек и (пере)определить ограничения для каждой ячейки в процессе — болезненная настройка и кошмар обслуживания для изменения.

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

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

Есть новости по этому поводу? Я чувствую, что эта функция необходима для более крупных развертываний. Тем более, что мы хотели бы иметь один график, например, показывающий использование хранилища, нам нужно предупреждение для 70%, 80% и т. д. и т. д., которые не должны иметь огромное количество графиков.

Я только что наткнулся на это, и я очень удивлен, что пока нет способа сделать это D:

Я вижу здесь https://github.com/grafana/grafana/pull/20822#issuecomment -561047900, что это не будет реализовано в будущем, и похоже, что оповещения будут полностью удалены с информационных панелей.

Как это повлияет на json-модель приборной панели? Кто-нибудь может сказать, когда будет больше новостей по этому поводу?

Это была очень нужная функция. Есть новости о предстоящей ситуации?

+1 за несколько оповещений на панель

+1 за эту функцию.

Это была очень нужная функция. Есть новости о предстоящей ситуации?

Нужна эта функция.

Спустя 3 года.. Кто-нибудь может сказать нам, почему это не реализовано (несмотря на количество запросов)?
Это связано с техническими ограничениями для его реализации? Это отклонено? Это в делах?
Как было сказано ранее, кажется «базовой функцией».
Пример: у меня есть панель инструментов и серия с 200 серверами, если я добавлю оповещение:
Один из 200 серверов мертв: круто, я получаю оповещение с именем
Упс, новый сервер не работает: нет оповещения (или нужно обновить панель управления или подождать напоминание через 24 часа после ..)
Это невозможно добавить как флажок для проверки, чтобы мы могли получать предупреждения по строке в серии (вместо «полной» серии)?
Если кто-то из разработчиков, команда grafana может ответить на отзыв...

Не могли бы вы попробовать prometheus для оповещений и оставить grafana для создания информационных панелей?

@beastea Если вам нужно настроить другой инструмент только для того, чтобы заставить Grafana работать, нет смысла использовать Grafana. Мы переходим на Datadog, потому что там есть эта функциональность и это только один инструмент.

@anne-nelson, вам нужно настроить сборщик метрик, хранилище метрик, а для правильной настройки поиграть с HA, чтобы заставить Grafana работать, верно?
Datadog — это не просто один инструмент, он просто скрывает его от вас и делает хорошую работу, кроме того, вы все еще можете использовать grafana с datadog: https://grafana.com/grafana/plugins/grafana-datadog-datasource

@beastea Я не уверен, что это за инструменты, поэтому не думаю, что мы их используем. Наши метрики отправляются в Influx, мы просто собираемся отправлять их в Datadog вместо Grafana. Зачем мне отправлять вещи в Datadog через Grafana, если я могу просто отправить их напрямую? Я хочу использовать как можно меньше инструментов.

@anne-nelson, вы можете внедрить отправку метрик в свое приложение, но иногда очень полезно также отправлять некоторые системные метрики, чтобы вы могли знать, что происходит с вашими дисками и другими вещами. Это то, что я подразумеваю под сборщиком метрик, неким локальным демоном, который делает такие вещи, как телеграф, сбор или плавность.
Influx в вашей настройке — это вещь, которая хранит метрики и дает широкие возможности для выполнения поиска через grafana в качестве веб-интерфейса пользовательского интерфейса для необработанных данных, что дает вам возможность использовать некоторый внутренний язык запросов Influx для манипулирования вашими данными.
В случае использования Datadog вместо Influx все работает точно так же. Графана здесь - это пользовательский интерфейс для доступа к данным. В общей установке. Таким образом, он ничего не делает с вашими данными, он просто представляет их в виде графиков. Так что вы все равно отправляете их напрямую.
В случае, если, как вы описали, вы работаете с inlux, почему вы не рассматриваете возможность использования kapacitor или flux для решения проблемы, которую вы описали, поскольку они предоставляют много возможностей для достижения, тогда grafana может когда-либо предложить вам, и они все еще от того же поставщика и как такая же среда. Flux даже входит в комплект поставки Influx.

Это будет очень полезно.

@beastea , так что, вероятно, лучше удалить функцию «оповещения» в grafana и перевести людей на другой инструмент (чтобы избежать газовой фабрики из нескольких инструментов)?
Я имею в виду, хорошо, мы можем использовать kapacitor, prometheus и т. д. Но функция оповещения уже существует в Grafana, так что в моем случае это бессмысленно.

Кстати, что мешает добавить этот флажок, чтобы получать оповещения по строкам? Вероятно, объяснение может помочь понять.

@beastea Кажется очень странным, что вы пытаетесь убедить кого-то не использовать Grafana.

Как отметил Антош, поскольку оповещения являются функцией Grafana, разумно ожидать возможности добавления нескольких оповещений на график. Если вы считаете, что мы не должны использовать Grafana для оповещений, то Grafana не должна иметь оповещения как функцию. Понятно, что многие люди хотят эту функцию, и что многие конкурирующие продукты уже предлагают ее. Честно говоря, я не понимаю, почему столько негатива по этому поводу.

@anne-nelson Я не пытаюсь никого убедить не делать то, что им хочется. Я пытаюсь дать совет взглянуть в другом направлении, которое уже сегодня может предложить вам решение.
Я не диктую вам, что и для чего вы должны использовать, я предлагаю альтернативы, которые могут дать вам решение уже сегодня. Я не отталкиваю, я даю вам совет. Если вы считаете, что мой совет бесполезен, извините, но это так. Мне жаль, что вы считаете, что я вас раздражаю и что я слишком настойчив со своими советами.
Хорошо тебе провести время.

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

Все ли могут просто сбросить это? Вы потенциально рассылаете спам сотням людей, это непродуктивно.

Извините за дополнительный шум все.

@torkelo , не могли бы вы сообщить нам обновленную информацию об этом запросе функции? Эта тема была открыта в течение ряда _years_ и, как вы можете видеть, до сих пор вызывает интерес. По крайней мере, это может помочь сократить ссоры и ненужную болтовню по этой теме, чтобы получить какой-то «официальный» ответ о том, включено ли это в текущую дорожную карту или нет. Ваше здоровье.

Этот и аналогичный #6041 полностью игнорируются. Интересно, почему.

Для нас это имеет смысл, так как наша операционная команда регистрирует новые интеграции на нашей платформе. Мы автоматически начинаем отправлять метрики в graphite. И за всем этим наблюдает только одна панель в графане.

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

Когда один не работает, а второй тоже гаснет, оповещение больше не срабатывает.

Вариант использования, который у меня есть для этого, - это определение многооконных оповещений о скорости горения с несколькими окнами через prometheus и grafana. Оповещения такого типа для мониторинга SLO являются стандартной практикой, как определено в руководстве Google SRE по адресу https://landing.google.com/sre/workbook/chapters/alerting-on-slos/ .

Абсолютно необходимо, пожалуйста, следите за этим ..

Я также перешел с оповещений Prometheus на оповещения Grafana, и я с нетерпением жду этого!

Может ли кто-нибудь, кто работал над Grafana, перечислить известные проблемы с решением этой проблемы?

Привет, @torkelo , может быть, ты сможешь просветить нас по этому вопросу!

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

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

@torkelo привет.
У меня та же потребность - несколько предупреждений для одной метрики на одном графике, но с мониторингом нескольких серверов.
У меня ~100 серверов с определенной метрикой свободного места на разделе '/' (например, у меня таких метрик десятки). И мне нужно получать одно уникальное оповещение на КАЖДОМ сервере, если свободного места на '/' станет меньше 20%.
В настоящее время этого не произойдет, если, например, server2 выдаст предупреждение, и пока ребята работают над решением проблемы, server4 выдаст такое же предупреждение - мы не получим уведомление. Или я упускаю какой-то функционал?

Путь умножения панелей на сервер на метрику — не путь.
Может ли кто-нибудь посоветовать мне, как сделать это возможным?
Должен ли я обновить свою Grafana (текущая версия 6.3.5)? Добавить расширения? Плагины? Что-нибудь еще?

Я благодарю и ценю всех, кто может посоветовать или помочь.

@torkelo привет.
У меня та же потребность - несколько предупреждений для одной метрики на одном графике, но с мониторингом нескольких серверов.
У меня ~100 серверов с определенной метрикой свободного места на разделе '/' (например, у меня таких метрик десятки). И мне нужно получать одно уникальное оповещение на КАЖДОМ сервере, если свободного места на '/' станет меньше 20%.
В настоящее время этого не произойдет, если, например, server2 выдаст предупреждение, и пока ребята работают над решением проблемы, server4 выдаст такое же предупреждение - мы не получим уведомление. Или я упускаю какой-то функционал?

Путь умножения панелей на сервер на метрику — не путь.
Может ли кто-нибудь посоветовать мне, как сделать это возможным?
Должен ли я обновить свою Grafana (текущая версия 6.3.5)? Добавить расширения? Плагины? Что-нибудь еще?

Я благодарю и ценю всех, кто может посоветовать или помочь.

Эта проблема открыта с 2017 года (И ответ @torkelo : 🤡 «иметь отдельные панели для алертов имеет смысл» 🤡 (очень приятно создавать панель по серверам/алертам, когда у нас 600 серверов) 🤡).

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

@antosz - большое спасибо. Проблема в том, что окружающая среда принадлежит не нам, а клиентам, поэтому для меня было бы очень непростой задачей настаивать на этом для моего лидерства и далее для него преодолевать «за это не будут платить» клиенты. .
Однако, по крайней мере, у меня есть некоторые факты, свидетельствующие о том, что «так организовать такие триггеры/сигналы невозможно».

Еще раз спасибо.

_join(голос, хор)_
У меня есть датчик тока в цепи, контролирующей воздушный насос номиналом 1,5 ампер и номинальным насосом сточных вод 10 ампер. Воздушный насос работает круглосуточно и без выходных, насос для сточных вод работает по требованию в зависимости от уровня бака. Когда все в порядке, ток (I) составляет либо 1,5 А при выключенном сливном насосе, либо 11,5 А при включенном сливном насосе.

Первой распространенной неисправностью является перегорание воздушного насоса, о чем предупреждает сигнал (Imax < 0,5 А или Iavg между 9 А и 11 А), который обнаруживает либо отсутствие тока, либо работу насоса для сточных вод, когда воздушный насос вышел из строя. Это должно быть решено в течение 48 часов, чтобы избежать сбоя системы. Данные 1 точка в минуту, оповещения через 90 минут.

Второе желаемое предупреждение на том же графике (Imax > 14A или Iavg между 2A и 9A), которое указывает на засорение насоса для сточных вод или наличие воздуха в линии, когда он должен работать. Это гораздо более срочное оповещение, которое может потребоваться в течение 3 часов, поэтому оповещение через 5 минут было бы идеальным.

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

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

может быть, если есть огромный спрос на это :)

Привет, @torkelo , что ты считаешь огромным спросом? 96 комментариев и 250 "лайков" в вашем комментарии - это огромно? Это восьмой по количеству комментариев открытый запрос функции, и только один закрытый запрос функции имеет больше комментариев. Это также 3-й открытый запрос функции с большим количеством реакций :+1:. Что нужно для входа в дорожную карту?

@torkelo У меня очень простой сценарий.

Мне нужно другое предупреждение, если значение опускается ниже порогового значения, чем предупреждение, когда значение превышает (другой) порог.

Здесь другой сценарий. Когда я отслеживаю количество работоспособных серверов, мне нужны разные предупреждения, когда я теряю 1 сервер (законный перезапуск, который не является проблемой, если только он не занимает более 10 минут), по сравнению с потерей 5 серверов.

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

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

Просто мои 2 цента.

Привет!

Хотел вмешаться, нам (Spotify) это тоже нужно.

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

Таким образом, с точки зрения пользовательского интерфейса, первая временная серия для оповещения приводит к тому, что панель/оповещение переходит в состояние «Оповещение», а каждое последующее оповещение просто накапливается (в истории состояний будет отображаться несколько обновлений «до» оповещений, а также несколько изменений вернуться к "хорошо")

Нам «нужно» это, поскольку именно так мы всегда делали оповещения, поэтому отказ от оповещений по временным рядам был бы огромным социальным изменением для ~ 10 000 оповещений. Мы очень хотели бы использовать и внедрить собственные оповещения Grafana и обновить наш источник данных для их поддержки.

Хотел вмешаться, нам (Spotify) это тоже нужно.

Вы также использовали Grafana Enterprise? Может поможет/мотивирует разработчиков =)

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

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

@sjoeboo здесь немного не по теме, но есть ли что-нибудь в открытом доступе?

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

примечание: механизм оповещения прямо сейчас специфичен для нашей TSDB (https://github.com/spotify/heroic)

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

Я поражен, что это не было реализовано после 3 лет запросов пользователей.

Необходимость создавать несколько панелей (по одной для каждого оповещения) в конечном итоге засоряет панель мониторинга и делает добавление новых оповещений более сложным, чем должно быть.

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

Интересно, что это до сих пор не реализовано. Я согласен, что «количество» на вкладке предупреждений вводит в заблуждение, поскольку заставляет думать, что их может быть несколько. Кроме того, иметь панель для каждого правила оповещения немного нелепо, поскольку это означает, что у меня есть «бесполезная» панель инструментов, которая представляет собой не что иное, как панели для оповещений. Конечно, это грязная приборная панель, но это единственный способ реализовать это. В основном это делается для того, чтобы я мог иметь разные правила для комбинаций имен и/или конечных точек уведомлений. Это сложно, мягко говоря.

Это сделано?
Версия Графаны = 4.x

Сейчас версия Grafana идет на 7.x и я не увидел этой фичи

Это сделано?
Версия Графаны = 4.x

Сейчас версия Grafana идет на 7.x и я не увидел этой фичи

Такой наивный😁

+1 за эту функцию.
По одной метрике я хотел бы

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

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

Я приведу другой пример.

Я запускаю Synology и хотел бы предупредить об этом. Статус рейда имеет нормальное значение 1. Однако он также имеет значение Degraded, равное 11, и значение Crashed, равное 12. Degraded означает, что данные все еще доступны. Сбой означает высокую вероятность потери данных.

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

Это также может быть применено к чему-то столь же простому, как использование дискового пространства.
Я хочу отправить предупреждение, если использование диска достигает 80%, и критическое предупреждение, если использование диска достигает 90%. Делать несколько графиков для КАЖДОГО из моих дисков неразумно.

И я не понимаю комментарий о том, что это сложно в пользовательском интерфейсе. У вас уже есть нечто подобное, представляющее собой список информационных панелей. Когда вы щелкаете вкладку «Оповещение», она должна отображать список правил оповещения по имени с кнопкой «Создать новое оповещение» внизу. Справа от каждого правила оповещения должен быть параметр «изменить», «отключить» или «удалить». Нажав на предупреждение или на кнопку редактирования, вы должны перейти на существующую страницу редактирования, которая отображается, но для этого конкретного правила оповещения.

Делать несколько графиков для КАЖДОГО из моих дисков неразумно.

Вы можете использовать API для автоматизации создания/обновления информационных панелей и их предупреждений. Если вы хотите, вы можете создать программу, которая запрашивает prometheus (или любой другой источник, который у вас есть), периодически выполняя запросы, чтобы служба обнаруживала цели и автоматически создавала предупреждения или их.

Невероятно, что эта функция еще не реализована, учитывая огромное количество отзывов об этой проблеме.

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

Создание фиктивных графиков — это обходной путь, а не решение. Это кажется элементарным!

+1 необходимая функция

+1

Точно такая же ситуация, как у ОП. Базовая функция, которая уже должна была быть реализована.

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

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

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc бесконечно полезнее для сопровождающего утверждать, какие проблемы «популярны», чем люди, рассылающие спам. все отправляют электронные письма и уведомления на github с информацией, которая уже ясна, просто взглянув на описание проблемы.

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

@thomasf «Могут ли люди перестать рассылать спам в этой теме, не добавляя ничего ценного?» - Так же, как ты?

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

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

Или, может быть, сопровождающие отписались от уведомлений по этой проблеме из-за спама, который не единственный с большим количеством +1 / сообщение без обновления. Пожалуйста, не сравнивайте Grafana и DataDog (мы были пользователями обоих, и нет возможности вернуться к DataDog)

Лучший способ получить это — внести свой вклад (или, возможно, заплатить за Grafana Entreprise)

Вы очень сильно ошибаетесь. Бесплатно или нет, вы не можете поставить
forum/slack/github/feedbackchannel, а затем проигнорируйте его. Если вы думаете, что
размещение программного обеспечения под лицензией с открытым исходным кодом означает «никаких жалоб» и «люди
будет разрабатывать под ваши фичи бесплатно" вы опять очень сильно ошибаетесь.
мой случай я объяснил им, что с этой функцией я могу продать графана до десяти
мои клиенты. Игнорировал меня, значит обозлился на клиента. Здорово
переезжать наверное им "достаточно" денег и они не хотят больше, я доволен
для них....

Вчера 14 октября 2020 г. в 15:35 Томас Фрёссман <
уведомления@github.com> по сценарию:

Могут ли люди перестать спамить эту проблему ветки, не добавляя ничего из
ценность?.

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

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

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
.

Сумма денег, которую я готов потратить на _любое_ программное обеспечение, прямо пропорциональна уровню обслуживания клиентов, который, как я могу ожидать, будет предоставлен для моих инвестиций. Будь то продукт с открытым исходным кодом, предлагающий «платную поддержку», или коммерческий продукт, на самом деле не имеет значения.

То, что этот вопрос остается открытым так долго без малейшего намека на поддержку проекта, к сожалению, экстраполирует на разумное чувство сомнения в том, что что-то изменится, потратив деньги. Если вы пытаетесь продавать программное обеспечение, вероятно, стоит подумать об этом.

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

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

Наконец, если ветка не закрыта/заблокирована, я не вижу причин для того, чтобы кто-то не высказывал свое мнение. Вы можете отказаться от подписки, если это вас не устраивает. Мне действительно нравится читать, как люди жалуются на относительную абсурдность этого. 😁

Оповещения NG (NextGen), запланированные на 8, будут поддерживать несколько экземпляров оповещений из одного определения оповещения. Таким образом, что-то вроде host=* с такой системой, как prometheus, будет создавать оповещения для каждого хоста.

Некоторая общая информация об этом в контексте отдельной статистики добавлена ​​на https://github.com/grafana/grafana/issues/6983#issuecomment -712915673.

Мы все еще занимаемся проектированием и прототипированием, но чтобы ответить на некоторые первоначальные мысли по этому поводу:

Несколько предупреждений на график

Определение предупреждений будет их собственными сущностями, поэтому они не будут привязаны к панели. Из определений предупреждений может стать несколько экземпляров предупреждений. Затем панель может подписаться на экземпляры или определения. Я предполагаю, что нам все еще понадобится хороший путь UX от панели инструментов для создания оповещения, потому что это хороший поток.

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

Как только разрешено множество предупреждений из одного определения, становится проблемой, как их следует сгруппировать (поскольку можно получить множество предупреждений). В настоящее время я вижу два пути того, как это будет работать с Alerting NG:

1. Используйте оповещения NG с IRM, такими как pagerduty или alertmanager, которые могут обрабатывать группировку экземпляров предупреждений.
2. Измените свой запрос, чтобы сгруппировать его по большему размеру области. Так, например, если запросить cluster=* вместо host=*,cluster=* (или сгруппировать по sql, как источники данных). В качестве альтернативы я намерен добавить функциональность к выражениям на стороне сервера (с оповещением ng), чтобы разрешить групповые/поворотные операции, если источник данных этого не делает. Это будет иметь место, если не используется IRM и отправка напрямую в такие службы, как электронная почта / slack.

предупреждение/критическое

Этот более сложный. Для дизайна WIP я удалил его как функцию (по крайней мере, для определения предупреждения, возможно, будет способ дублировать определение предупреждения, изменить его и как-то пометить/пометить его с серьезностью)

Это сложно, потому что во многих случаях это очень полезно:

• Для меня предупреждение/критическое значение имеет четкое назначение: приближение к сломанному/сломанному или деградировавшему/сломанному.
• Без них многие настройки в конечном итоге будут повторять изрядное количество предупреждений для разных уровней серьезности.

Так почему же решили их не иметь? Это добавляет немного неочевидной сложности:

• Предполагая, что вы хотите поддерживать свои пороговые значения, полученные из другой метрики (или чтобы ваши пороговые значения были различными диапазонами времени запроса, а не значениями), теперь необходимо выполнить два условия.
• Для состояний экземпляров предупреждений, как минимум, я хочу поддерживать:
  
  
  
  • Неизвестно: экземпляр исчез.
  
  
  • Ошибка: запрос, который обнаружил бы проблему с экземплярами, не работает.
  
  
  • Оповещение: условие верно
  
  
  • Нормальный. Условие не соответствует действительности
  
  
• Мы также хотим и дальше использовать FOR-подобные выражения. При добавлении большего количества состояний разработка не имеет взмахов, либо приводит к пропущенным уведомлениям, либо к шуму. В общем, конечные автоматы со временем очень подвержены ошибкам, и их трудно исправить (поищите в TLA/временной логике действий, чтобы узнать больше, если вам нравятся подобные вещи). Таким образом, добавление уровней серьезности увеличивает пространство состояний больше, чем можно было бы предположить. Это означает, что у нас больше шансов иметь непреднамеренное поведение или поведение, для которого сложнее иметь ментальную модель.
• При попытке интеграции с другой системой или IRM наличие определенных понятий серьезности может усложнить интеграцию.

(по крайней мере, для определения предупреждения, возможно, будет способ дублировать определение предупреждения, изменить его и каким-то образом пометить/пометить его серьезностью

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

то как они должны быть сгруппированы, становится проблемой (поскольку можно получить много предупреждений)

Пользователь может самостоятельно управлять объемом заявок и генерацией сигналов тревоги. Если вы устанавливаете будильники, каждый из них должен быть отдельным электронным письмом или уведомлением. Подумайте об этом таким образом, если вы создадите автоматизированную систему для создания заявок на основе срабатывания сигналов тревоги, например, группировка нескольких сигналов тревоги в одно электронное письмо сделает это либо сложным, либо просто неприятным. Кроме того, несколько сигналов тревоги, отображаемых в одном электронном письме, означают, что у каждого сигнала тревоги не может быть своего собственного потока электронной почты, пользователи должны будут вручную отделять его и запускать новые потоки. Вместо этого каждое срабатывание аварийного сигнала должно иметь собственное уведомление, чтобы потоки можно было связать с этим конкретным аварийным сигналом.

Надеюсь, это упростит тревожный дизайн, поскольку вам не нужно беспокоиться о группировке. Это зависит от пользователя.