Grafana: Оповещение о поддержке запросов с использованием переменных шаблона

+1

1. В чем разница по сравнению с использованием всего?

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

@bergquist нецелесообразно использовать все, например, когда у вас более дюжины хостов.

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

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

что сказал @calind , у меня есть несколько переменных $host, которые отлично работают с influxDB, но не с предупреждениями

+1 тоже.

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

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

Использование опции all для шаблона — единственный способ, который имеет для меня смысл.

+1

У меня есть настройка среды X с одинаковыми компонентами в каждой среде. В настоящее время мы используем prometheus для оповещения, например, об использовании процессора/диска и т. д. Там мы указываем оповещение для запроса, и когда оповещение срабатывает, оно просто указывает, из какой среды было вызвано оповещение.

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

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

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

+1 за поддержку оповещений по шаблонным запросам.

@bergquist , на некоторых панелях мониторинга нет опции _All_. Например, системные метрики от collectd (https://grafana.net/dashboards/24). Наличие опции _All_ определенно нецелесообразно, скажем, для 10 или более серверов. Вот почему необходимо перебирать переменные шаблона.

Разрешение использования All — хорошее и долгожданное начало.

В Prometheus запросы нужно писать по-другому, чтобы разрешить Все:

some.metric{hostname=~"$Hostname"}

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

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

+1

+1

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

+1
Мы используем Prometheus в качестве источника данных для мониторинга нашей инфраструктуры Kubernetes в отношении наших локальных кластеров K8S и наших кластеров AWS K8S.
Все наши информационные панели используют шаблонные переменные для источника данных ($Environment), $Instance/Node, $Namespace и $Pod.
Из-за того, как устроена структура запросов Prometheus; все запросы имеют шаблонные переменные; что не позволяет правилам предупреждений разрешить сохранение.
Я бы хотел, чтобы к оповещению добавлялись шаблонные запросы переменных.

+1

+1
Мы используем шаблонные информационные панели для многосерверной среды, что является логичным способом (и многие люди используют его), поэтому мы не можем использовать оповещения с помощью grafana прямо сейчас. Единственный способ — иметь отдельную панель инструментов без шаблонов или настроить оповещения с помощью самого prometheus, что непросто.

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

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

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

+1. Почти все наши информационные панели используют переменные шаблона (и вложенные переменные шаблона).

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

ОПАСНО: Теоретически иметь переменные было бы неплохо, но мы должны помнить, что если какой-то парень зайдет в вашу панель управления, изменит значение и сохранит, это повлияет на полученное оповещение. Не знаю, нормально это поведение или нет, будет сложно.

+1

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

+1 за поддержку оповещений по шаблонным запросам.
Кроме того, мы обнаружили, что при использовании китайского ruleName или китайского названия мы получали ненормальное электронное письмо со сработавшим правилом. Например, мы ожидали «个股分时线接口请求时间(getTimeTrend) alert», но получили «ä¸ªè‚¡åˆ†æ—¶çº¿æŽ¥å £è¯·æ±‚æ—¶é—´( getTimeTrend) alert", возможно, кодировка неверна.

+1 за реализацию шаблонных переменных в оповещениях

+1

+1 было бы отличным дополнением

+1

+1 за реализацию шаблонных переменных в оповещениях

+1

+1 с нетерпением жду

+1

+1

+1

+1

Пожалуйста, перестаньте писать +1 !
Все, кто подписался на этот выпуск, получат письмо по электронной почте...

На github есть функция, позволяющая избавиться от комментариев +1 :
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

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

Большой прогресс в оповещении в целом.
Что касается переменных шаблона в оповещении, мне его тоже не хватает. +1 :D

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

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

См. #K (используется #D, который использует #A, а #A использует templ. var):

Я все еще мог выбрать его:

Шаблоны повсюду, а это значит, что оповещения нигде нет.
Не уверен, как было реализовано оповещение, но для простого графика запрос «переводится», переменные шаблона заменяются значениями перед вызовом источника данных, верно? Так почему бы и нет в этом случае? В любом случае, как было сказано ранее, имея почти все запросы, использующие переменные шаблона, оповещение полностью для меня. Пожалуйста, не могли бы вы реализовать это, чтобы нам не приходилось перемещать оповещения за пределы Grafana? Большое спасибо!

Я думаю, мы должны признать, что оповещение с помощью шаблонов не является тривиальным, и я думаю, что варианты ВСЕ — это то, что нужно, потому что мы не хотим, чтобы наши оповещения менялись, когда кто-то использует панель управления.
Но grafana все равно придется создавать новые оповещения, если запрос шаблона возвращает новые результаты... что часто происходит тихо, когда мы масштабируем наши приложения.
Это приводит к большему количеству проблем, если вы используете InfluxDB, так как многие из нас используют теги/значения тегов, и для них нет временного фильтра... поэтому grafana будет создавать оповещения для всех служб, которые когда-либо существовали на любом хосте.. .

+1

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

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

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

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

есть ли у нас какие-либо целевые вехи для этой ошибки?

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

Что я делаю, так это готовлю запрос:

затем извлеките его с помощью инструментов разработчика Chrome (скопируйте значение целевого параметра):

Поместите его в другую строку (сначала переключитесь в режим редактирования):

Настройте оповещение:

Вуаля!

@siteshbehera Это не ошибка. Это запрос функции.

Но нет. У нас нет вехи для этого в настоящее время.

Плагин искусственного интеллекта grafana должен быть включен в коммит для этой функции.

Ожидание шаблонов в Оповещениях тоже +1

Я также очень поддерживаю то, что calind предоставил как возможную реализацию во вступительном посте. Кажется, это точно вписывается в то, сколько (включая меня) используют шаблонные информационные панели — когда у вас есть одна информационная панель, но вы переключаете / ограничиваете некоторые переменные, чтобы вручную просматривать определенные вещи. Я думаю, что пример переменной «сервер» может быть наиболее подходящим. Там переменная шаблона (без _all_-значения) стала бы чем-то вроде «_tab_» на моей панели инструментов — я могу переключаться между ними, чтобы увидеть разные наборы данных. Тогда легко предположить, что при настройке оповещения оповещение будет существовать для каждой возможной "_tab_" отдельно.

Ожидание поддержки шаблонов в Оповещениях +1

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

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

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

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

Есть ли место, где отслеживается дорожная карта grafana? Или каким-либо образом, чтобы мы могли увидеть, будут ли функции (такие как эта) реализованы в будущем (близком или не очень близком), не ковыряясь в мантейнерах на github? :)

Удивительно, очень жду этого

+1

+1

Мы до сих пор не знаем, как это сделать.

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

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

Такое решение, как каждый, будет довольно большой и сложной функцией.

У меня есть два предложения по решению.

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

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

Как я упоминал еще в ноябре. Для пользователей prometheus достаточно просто использовать All в качестве значения переменной, если запросы написаны правильно ( some.metric{hostname=~"$Hostname"} ).

Должно быть, вероятно, также очень легко реализовать.

@bergquist Я думаю, что вариант 2 движется в правильном направлении (частичная реализация того, что я предложил в https://github.com/grafana/grafana/issues/6557#issuecomment-272588490), это не кажется слишком сложным, так как код для обработки выбора шаблона var уже существует для панели мониторинга, и нет необходимости дублировать конфигурацию var, только выбор. Я не думаю, что стал бы связывать выбор приборной панели с оповещением при первом проходе этой функции.

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

+1 за реализацию шаблонных переменных в оповещениях

+1 за реализацию шаблонных переменных в оповещениях

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

Оповещение @alejandroandreu было добавлено в версии 4, оно никогда не работало с шаблонами.

+1 за реализацию шаблонных переменных в оповещениях

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

Введите все желаемые комбинации вручную

• Эта конфигурация должна отображаться на панели конфигурации предупреждений.

Например, если у меня есть 3 переменных шаблона: cloud , region и type , я бы заполнил таблицу, которая выглядит следующим образом:

| облако | регион | тип |
|-------|------------|------|
| авс | сша-восток-1 | производство |
| авс | сша-запад-1 | производство |
| лазурь | Центральная часть США | производство |

В таблице должна быть дополнительная строка для вставки новых строк и кнопка удаления для каждой строки.

Введите возможные значения, и Grafana рассчитает декартово произведение.

• Примечание. Эту конфигурацию можно ввести на панели конфигурации переменных шаблона.

| облако | регион | тип |
|-------|------------|------|
| авс | сша-восток-1 | производство |
| лазурь | сша-запад-1 | |
| | Центральная часть США | |

Комбинации, которые будут созданы для этого входа:

• aws us-east-1 prod
• aws us-west-1 prod
• aws Central US prod
• azure us-east-1 prod
• azure us-west-1 prod
• azure Central US prod

Но Grafana может справиться с этой ситуацией, «введя» первую переменную ( cloud ), а затем отфильтровав доступные значения из второй переменной ( region ), пока не найдет все возможные комбинации (примечание — это должно быть сделано итеративно для всех переменных). Это возможно, когда люди используют такие запросы в тегах:

SHOW TAG VALUES WITH KEY = "REGION" WHERE "CLOUD" =~ /$CLOUD/   

И в этом случае произведенные комбинации будут в порядке (что совпадает с таблицей в первом варианте):

• aws us-east-1 prod
• aws us-west-1 prod
• azure Central US prod

Надеюсь, мои предложения будут полезны.

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

@dbcook звучит как отдельная проблема, для которой вам, вероятно, следует создать отдельную проблему.

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

@tomekit Спасибо за обходной путь, он выглядит многообещающе, пока мы ждем реальной реализации. Однако я не могу найти, где извлечь запрос с помощью инструментов разработчика Chrome, и поэтому не могу скопировать значение целевого параметра для нового запроса. Я пробовал «Проверить элемент», но я изо всех сил пытаюсь найти «Имя», «Заголовки» или «Данные формы», которые вы показали на снимке экрана.

Не могли бы вы проиллюстрировать шаги для этого? Ваша помощь будет высоко оценена!

Спасибо

@mathurj Это вкладка «Сеть» -> «XHR». Помогает ли это сейчас?

Затем нажмите на запрос «рендеринга».

Спасибо , @tomekit , теперь я вижу эту страницу, однако я не вижу ни одного запроса с именем «рендеринг». Однако есть еще один запрос о запросе, который я выполняю, но он не имеет никакого «целевого» параметра.

Любые сведения о том, как выполнить запрос на «рендеринг»?

@mathurj Я получаю запрос на «рендеринг», когда смотрю на один из графиков на панели инструментов и нажимаю «Обновить» (в верхнем правом углу).

Попробовал, у меня все еще нет запроса на «рендеринг» :( И нет «целевого» параметра. В любом случае спасибо за вашу помощь @tomekit . Думаю, мне придется подождать фактической реализации, которая может занять некоторое время, судя по внешнему виду. это @bergquist @torkelo ?

хорошо работать с
some.metric{имя хоста=\~"$Hostname"}
в самом запросе все в порядке,
но это мой источник данных, который является шаблоном здесь...

среда=\~"$среда"
кажется, не работает ... как это работает, я что-то пропустил? или я должен избавиться от шаблона :disappointed:

+2

эта функция особенно полезна при использовании prometheus в качестве источника данных!

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

Нам это нужно!!! :) 👍

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

+1
нам это тоже нужно

+1
нам это тоже нужно

+1
нам это тоже нужно

Могу я спросить, почему так много парней ставят "палец вниз" на ответы +1??

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

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

+1

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

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

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

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

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

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

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

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

Соответствующие предложения по реализации из этой темы:
https://github.com/grafana/grafana/issues/6557#issuecomment -272588490
https://github.com/grafana/grafana/issues/6557#issuecomment -281049641 (вариант 2)

Также сопутствующие вопросы:
https://github.com/grafana/grafana/issues/6041
https://github.com/grafana/grafana/issues/6553
https://github.com/grafana/grafana/issues/6983
https://github.com/grafana/grafana/issues/7252

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

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

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

@pdf Я согласен с тем, что https://github.com/grafana/grafana/issues/6041 — это большое ограничение, которое мы определенно хотим исправить, но оно не связано с этой проблемой. Плохо, что мы еще не исправили это, я согласен, в последние пару месяцев у нас было немного недоукомплектовано персоналом по оповещению, но это скоро изменится!

@danhallin , это не то же самое, кажется, это будет означать запрос в Grafana, который нацелен на многие серии, используя подстановочные знаки или выражения glob в вашем запросе, или фильтрует только ограниченный набор тегов? Правила предупреждений Librato определяются отдельно от информационных панелей, не так ли, как их можно преобразовать в функцию фильтрации данных для всей информационной панели?

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

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

Скажем, в одном запросе используются 2 переменные шаблона, $A и $B, каждая из которых имеет 50 значений. Приведет ли это к оценке правила предупреждений 2500 раз? Я имею в виду, что если переменные имеют «одно значение», то есть запросы построены так, чтобы работать только в том случае, если $A и $B имеют одно значение, тогда нам придется это сделать. Может быть, это не показатель, нам придется объяснить, что поддерживаются только переменные с несколькими значениями. Вероятно, есть еще много ограничений и проблемных деталей, которые сделают эту функцию очень сложной для реализации, использования и понимания.

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

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

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

Скажем, в одном запросе используются 2 переменные шаблона, $A и $B, каждая из которых имеет 50 значений. Приведет ли это к оценке правила предупреждений 2500 раз? Я имею в виду, что если переменные имеют «одно значение», то есть запросы построены так, чтобы работать только в том случае, если $A и $B имеют одно значение, тогда нам придется это сделать. Может быть, это не показатель, нам придется объяснить, что поддерживаются только переменные с несколькими значениями. Вероятно, есть еще много ограничений и проблемных деталей, которые сделают эту функцию очень сложной для реализации, использования и понимания.

Я думаю, что здесь есть две отдельные проблемы. Один _is_ (я полагаю) тесно связан с # 6041, поскольку может возникнуть желание оценить условия оповещения индивидуально для каждого значения серии/шаблона (обобщенный переключатель, о котором я упоминал в предыдущем комментарии). Если мы пока отложим это в сторону, я считаю, что идеальный способ решить большую часть этой проблемы — разрешить несколько конфигураций предупреждений на панель и просто выполнить интерполяцию переменных точно так же, как и для вывода панели: разрешить пользователям выбирать одно- или значения шаблона с несколькими значениями при настройке запросов предупреждений; запросы будут выполняться один раз для каждой конфигурации предупреждений с заполнением выбранных значений; и результаты будут интерпретироваться точно так же, как и сейчас. Если я что-то серьезно не понимаю, я не вижу в этом значительного увеличения сложности и должно быть довольно удобным для пользователя.

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

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

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

Это, безусловно, популярная потребность. Теперь, чтобы добиться оповещения, нам нужно было перейти
отказаться от Grafana и создать собственное решение с помощью Graphite’s Render
Необработанные данные API. Я не думаю, что поддержка предупреждений в динамических / шаблонных
данные - это любой комплекс, по крайней мере, с использованием Graphite..

Еще одна мысль,. Почему в Grafana раздел «Оповещения» является частью панели инструментов
config, если это считается сложным. Вы можете отодвинуть его, чтобы отделить
Предупреждающий вид, в котором пользователи могут просто вводить/настраивать свой динамический запрос,
интервал, условие оценки там.. Может быть, это может означать, что мы
у вас нет дубликатов информационных панелей. Имеет смысл?

БР,
Вишва..

23 августа 2017 г., 8:01, «Питер Ферн» [email protected] написал:

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

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

Скажем, в одном запросе используются 2 переменные шаблона, $A и $B, каждая из которых имеет по 50
значения. Приведет ли это к оценке правила предупреждений 2500 раз? я имею в виду
если переменные имеют "одно значение", т.е. запросы построены так, чтобы работать только
если $A и $B имеют одно значение, нам придется это сделать. Не шоу
возможно, нам придется объяснить, что только переменные с несколькими значениями
поддерживается. Вероятно, есть еще много ограничений и проблемных деталей.
что сделает эту функцию очень сложной для реализации, использования и понимания

Я думаю, что здесь есть две отдельные проблемы. Один ( я полагаю) близко
связанный с # 6041 https://github.com/grafana/grafana/issues/6041 , в
что может возникнуть желание оценивать условия оповещения индивидуально для каждого
значения серии/шаблона (агрегатный переключатель, о котором я упоминал ранее
комментарий). Если мы пока отложим это в сторону, я считаю, что идеальный способ решить
основная часть этой проблемы заключается в том, чтобы разрешить несколько конфигураций предупреждений на панель, и
просто сделайте переменную интерполяцию точно так же, как для приборной панели
output — разрешить пользователям выбирать значения шаблона с одним или несколькими значениями, когда
настройка запросов предупреждений; запросы будут выполняться один раз за оповещение
config с заполненными выбранными значениями; и результаты будут
интерпретируются точно так же, как и в настоящее время. Если я не грубо
что-то недопонимаю, я не вижу в этом существенного увеличения
сложности и должен быть достаточно удобным для пользователя.

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

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAz1sbIwOT7Xb1MwoDYgZCPz182h2ENxks5sbD62gaJpZM4Kwf5K
.

@danhallin , это не то же самое, кажется, это будет означать запрос в Grafana, который нацелен на многие серии, используя подстановочные знаки или выражения glob в вашем запросе, или фильтрует только ограниченный набор тегов? Правила предупреждений Librato определяются отдельно от информационных панелей, не так ли, как их можно преобразовать в функцию фильтрации данных для всей информационной панели?

Теперь я вижу, что то, что я обсуждаю, в основном является копией: https://github.com/grafana/grafana/issues/6041 .

Я поддерживаю этот запрос функции, а не этот.

Мы регулярно запускаем серверы, и у нас есть шаблонные информационные панели, которые измеряют общие параметры для всех хостов (mem, hd, cpu и т. д.). Создание панели «оповещения» с графиками для каждой возможной комбинации слишком утомительно, многие из желаемых предупреждений можно обобщить для всех хостов. AFAIKT, эта проблема требует способа сделать этот вариант использования возможным и не будет решена в # 6041. Если только я что-то не упустил.

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

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

Обошли это, используя шаблонную многозначную переменную (установленную на All), сгенерированную из «Простого источника данных JSON», которая содержит источник правды о том, какие экземпляры должны работать — все работает отлично. Увы, как только я попытался включить оповещения, я получил запрос на эту функцию :)

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

+1

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

Есть новости по этой теме?

Привет,

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

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

Извините за лишний шум, но это была бы действительно замечательная функция в Grafana.

+1, очень-очень важная функция!

Кроме того, если позволить мне изменить выражение запроса метрики prometheus для удаления переменной шаблона, это вообще невозможно. Итак, я думаю, что эта функция наиболее важна для того, чтобы prometheus + grafana попала в производство!

В любом случае, пожалуйста, команда может рассмотреть приоритет, спасибо!

Поскольку версия 5.0 скоро выйдет, я бы хотел, чтобы в следующей серии выпусков уделялось значительное внимание оповещениям. Судя по реакции Github, недостатки, связанные с оповещениями, вызывают наибольший интерес у пользователей.

Я знаю, что было некоторое нежелание заниматься этими вещами из-за проблем со сложностью UI/UX, однако я не уверен, что эти опасения обязательно оправданы. Можем ли мы, как пользователи, сделать что-то, что могло бы помочь в планировании/проектировании или продвижении этих проблем, за исключением запросов на вытягивание с реальным кодом?

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

Это снова ограничения.

Спасибо.

Есть новости об этой функции?

Каковы усилия нового участника, чтобы добавить эту функцию?

+1

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

+1

Надеемся на решение.

+1

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

Во всех приведенных ниже сценариях мы используем одну шаблонную переменную: $env

«Почему бы просто не создать панели оповещения?»

Мы хотим оповещать о нескольких разных средах, а не только о рабочей среде. Таким образом, теперь нам нужно иметь одну и ту же метрику как минимум в 3 разных местах (панель управления устранением неполадок со всеми метриками, а не только метрикой, для которой мы оповещаем; панель оповещений о продуктах; панель оповещений интеграции). Это может довольно быстро выйти из-под контроля и может привести к ошибке пользователя.

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

Попытка решения

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

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

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

Проблемы с этим решением

Однако это не очень хорошо работает. Например:

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

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

Вещи, которые помогут, пока этот конкретный тикет не будет решен

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

Вещи, которые я не знаю, как исправить

Аннотации к графикам с оповещениями, настроенными для нескольких сред/переменных:

При этом мы не можем сказать, какое оповещение срабатывает, не заходя в панель. Предложение легенды могло бы помочь прояснить это, но мало что делает для аннотации, если не выбран правильный $env (на приведенном выше рисунке int предупреждает, но prod — это переменная, выбранная на панели инструментов, поэтому мы отображаем аннотации из оповещения int поверх графика, используя prod .

+1

плюс один :)

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

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

Я согласен, и эта функция нам очень поможет !!!!

+1 пожалуйста

нам нужно это

+1 пожалуйста. Это действительно необходимо.

@bergquist @torkelo, можем ли мы заблокировать эту проблему, чтобы остановить спам +1?