Grafana: система оповещения для графана

Я бы хотел помочь с этим! Я предлагаю придерживаться руководящих принципов в стиле nagios. Таким образом, инструменты можно было легко использовать с другими инструментами мониторинга. например, Nagios, Zenoss, Icinga и т. д.

Самая важная вещь в этой функции - это правильная базовая архитектура.

Некоторые вопросы, которые я хотел бы изучить
1) Какие компоненты требуются, как они запускаются (в процессе в графане, вне процесса),
2) Как все должно быть согласовано.
3) Следует ли игнорировать оповещения "в потоке" (фокусироваться только на вытягивании)

Более подробно рассмотрим 1)
Меня беспокоит превращение графана-сервера в монолит. Хотелось бы найти способ разделить графана-сервер на службы, которые более изолированы друг от друга (и могут запускаться либо внутри процесса, либо как отдельные процессы). Это был своего рода план с абстракцией автобуса. Другой вариант - сделать так, чтобы компонент оповещения говорил только с grafana через HTTP api, что может ограничить интеграцию, не уверен.

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

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

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

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

Продолжайте в том же духе.

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

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

С нетерпением жду работы, которая будет здесь проделана!

1. Он должен использовать пороговые значения, определенные на панели инструментов, чтобы предупреждать о
   Давайте будем простыми; если на приборной панели отображается цвет для предупреждения, это должно быть предупреждение.
2. Вероятно, это что-то вне самого процесса графана-сервера.
   ... Что-то, что будет использовать остальной api для очистки панелей мониторинга и его настроек, а также их рендеринга и предупреждений с помощью внешней команды.
3. Уровень оповещения; просто поле, которое нужно добавить в редактор, чтобы контролировать эту панель; и это нужно проверять каждую минуту. Если нет данных, он должен еще какое-то время предупреждать? (флажок)

Наконец; так как мы больше зависим от Grafana, я признаю, что готов сказать 2. Может быть, я был бы готов заплатить за это.

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

Абсолютно правильный @dennisjac; Графана только визуализирует.

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

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

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

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

В новом проекте Telegraf (сборщик метрик от разработчиков Infxdb) также рассматриваются функции мониторинга / оповещения, которые не нравятся по той же причине. Я подробно остановился на этом здесь:
https://influxdb.com/blog/2015/06/19/Announcing-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

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

Что касается infxdb, им нужно как-то заработать немного денег; либо от поддержки Influxdb и профессиональных услуг или продуктов для него.

Последнее звучит гораздо более жизнеспособно

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

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

Также я согласен с идеей разделения процессов. У Grafana есть интерфейс для просмотра и создания предупреждений, есть еще что-нибудь для обработки предупреждений. Наличие api части оповещения также позволит другим инструментам взаимодействовать с ней.

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

+1 это замкнет цикл - предложение получить метрики.

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

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

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

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

У нас есть два варианта использования:

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

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

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

Что еще более важно, я бы тоже хотел увидеть какое-нибудь интегрированное решение для обнаружения аномалий!

15 июля 2015 г., в 17:40, Пьериг Ле Саукс [email protected] написал:

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub.

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

ИМХО было бы разумнее сосредоточиться на _интеграционной_ части.

Пример: Определите динамические пороги предупреждения / крита в графане (например, как в примере @Dieterbe выше) и предоставьте API (REST?),

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

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

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

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

Как бы я ни хотел, чтобы Grafana решила все мои проблемы, я думаю, что falkenbt попал в самую точку с этим.

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

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

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

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

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

Продолжайте в том же духе, и удачи!

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

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

Вот пара скриншотов в действии

Изменения в части графаны включали добавление конечных точек «/ alerts» и «/ subscriptions», а также взаимодействие с другим маленьким api, который находится наверху, чтобы Риман выполнял всю работу.

Приятно то, что изменения в определениях предупреждений отражаются немедленно, без необходимости отправлять SIGHUP в riemann. Таким образом, включение / отключение настроек периода времени для изменений состояния - это просто вопрос их изменения в пользовательском интерфейсе, и это изменение распространяется на riemann.

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

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

@sudharsh, ваша реализация звучит очень интересно. Вы планируете выпустить это на волю?

много хороших идей, спасибо всем.
Вдохновленные некоторыми комментариями и проектом @pabloa https://github.com/pabloa/grafana-alerts, мы решили сосредоточиться в первую очередь на пользовательском интерфейсе и пользовательском интерфейсе для настройки правил оповещения и управления ими в рамках одного рабочего процесса. редактирование дашбордов и панелей. Grafana где-то сохранит эти правила и обеспечит легкий доступ к ним, чтобы другие скрипты или инструменты могли получить правила предупреждений.
Возможно, через файл, вызов API, раздел в конфигурации панели управления или запись в базе данных.
(Мне нравится идея иметь его как часть самого определения панели мониторинга, чтобы проекты с открытым исходным кодом могли поставляться с json-файлами панели управления grafana, в которые были бы включены правила предупреждений, хотя они не обязательно активны по умолчанию. С другой стороны, наличие их в база данных кажется более надежной)
В любом случае, мы хотим обеспечить легкий доступ, чтобы вы могли сгенерировать конфигурацию для любой другой системы, которую вы хотите использовать, которая фактически выполняет правила оповещения и обрабатывает события. (далее я буду называть это "обработчиком").
Таким обработчиком может быть nagios, или sensu, или bosun, инструмент, который вы пишете, или планировщик-исполнитель лакмусовых предупреждений, который представляет собой обработчик, который вы можете скомпилировать в grafana, который обеспечивает красивую и простую интеграцию, поддерживаемую bosun, но мы действительно хотим, чтобы убедитесь, что вы можете использовать любую систему, которую хотите.

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

@sudharsh , это очень хороший подход. Мне нравится, как ваше решение может напрямую взаимодействовать с удаленным API, минуя промежуточный шаг, описанный выше (конечно, это означает, что оно работает только для одного заданного бэкэнда, которого мы стараемся избегать), и что оно может автоматически перезагружать конфигурацию. (Вы правы, боцман в настоящее время его не поддерживает, возможно, в будущем. FWIW обработчик лакмусовой бумажки справляется с этим штрафом и использует механизм оценки выражений боцмана). Я никогда особо не увлекался Риманом. В основном я был обеспокоен добавлением в стек такого другого языка, который не многие люди понимают или могут отлаживать, когда что-то идет не так. Но мне очень любопытно узнать больше о вашей системе и о коде Riemann CLJ. (Мне бы понравилось, если мои подозрения неверны)

@dennisjac да, это было бы необязательно.
@elvarb есть билет для ES в качестве источника данных . Фактически цель состоит в том, чтобы, если grafana поддерживает рендеринг данных из заданного источника данных, она также должна поддерживать составление правил предупреждений для него. Что касается выполнения запросов / запросов, это, конечно, зависит от того, какой обработчик вы решите использовать. (для обработчика лакмусовой бумажки мы начнем с самых популярных, таких как graphite и Influxdb)
@rsetzer : согласен, хорошо иметь возможность указать, как долго должен быть превышен порог, прежде чем мы сработаем
@falkenbt : Я считаю, что многие вещи можно описать как проблему запросов к таймсерию (например, пример ping). Но вы правы, некоторые вещи на самом деле не связаны с таймсериями и выходят за рамки того, что мы пытаемся здесь построить. И я думаю, что это нормально: мы хотим предоставить лучший способ настройки и управления предупреждениями в таймсериях и стремимся к интеграции с другими системами, которые, возможно, более оптимизированы для случая «разных сценариев» (например, nagios, icinga, sensu, .. .). Что касается таких проблем, как надежность доставки, эскалация и т. Д., Вы можете подключить такую ​​услугу, как pagerduty.
@activars & @falkenbt соответствует ли это вашим ожиданиям или что, по вашему мнению, можно было бы улучшить?
@jemilsson, спасибо! и это именно то, как я это вижу: боцман отлично подходит для оповещения, но не хорош для визуализации. Grafana отлично справляется с визуализацией и пользовательским интерфейсом, но не имеет предупреждений. Я пытаюсь наладить сотрудничество, которое, я думаю, со временем будет расти.

Есть ли у кого-нибудь мысли о том, какой контекст отправлять в уведомлениях, таких как электронные письма?
По крайней мере, уведомление должно содержать визуализацию данных, о которых вы предупреждаете, но должно быть возможно включить другие связанные графики. Здесь мы могли бы использовать серверную часть рендеринга png grafana при генерации содержимого уведомления. Я также думаю об использовании функции моментальных снимков графаны. например, когда срабатывает предупреждение, сделайте снимок определенной панели мониторинга для контекста.
и, возможно, этот снимок (html-страница) может быть включен в электронное письмо, или это может быть слишком много данных / сложности. также функции javascript в любом случае будут недоступны в почтовых клиентах (так что вы не сможете увеличивать графики в электронном письме). Возможно, мы могли бы связать электронное письмо с моментальным снимком размещенной панели управления.

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

Influxdb будет поддерживаться для оповещения? или только графит?

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

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

Это пример, который я позаимствовал из старого документа, написанного мной некоторое время назад. Да, пожалуйста, не обращайте внимания на использование слова «Struts». Это СТАРОЕ, ладно? Это представляет собой очень простую иерархию для одного сервера.

В какой-то момент сервер испытывает устойчивую загрузку ЦП на 75%, поэтому эти предупреждения переводятся в состояние предупреждения: ЦП- # -> ЦП -> Хост / ОС -> Система

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

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

@felixbarny Мне нравится эта терминология. мы, вероятно, примем эту формулировку.
@JulienChampseix да, стандартный обработчик будет / будет поддерживать infxdb
@nickman , это интересно. на самом деле это соответствует конечной цели, которую мы имеем в виду, а именно возможности создавать предупреждения очень высокого уровня, которые могут включать или зависеть от более детализированных правил предупреждений и информации. bosun уже делает это, и в долгосрочной перспективе мы хотим сделать эту функцию доступной через более удобный интерфейс, но мы должны начать с более простого.
@amirhosseinrajabi выглядит классным проектом, и я думаю, что создание графитового маяка в обработчике предупреждений, настроенных через пользовательский интерфейс grafana, имело бы большой смысл.

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

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

Привет @Dieterbe

есть ли обновления о ходе работы системы оповещения ??

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

@mattttt, можете ли вы предоставить обновления вашей UX-работы?

Да, конечно. Завтра загрузю несколько экранов / пользовательских потоков.

Нам нужны предупреждения: пользовательский интерфейс для определения правил, API для определения правил и API для уведомлений о предупреждениях. Буду с интересом смотреть эту ветку. У нас есть мультитенантная система, и мы любим графический интерфейс и серверную часть Grafana.

Да, мне тоже очень интересно и не терпится увидеть эту новую функцию!
Большое спасибо, Мэтт! ;)

2015-08-27 6:49 GMT + 02: 00 andyl [email protected] :

Нам нужны оповещения: пользовательский интерфейс для определения правил, API для определения правил и API.
для уведомлений о предупреждениях. Буду с интересом смотреть эту ветку.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -135290295.

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

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

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

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

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

@mattttt здорово!

Обожаю зеленую и красную линии под графиком!

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

О всплывающей подсказке вы говорите о статистике, которая появляется при наведении курсора на линии?

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

Не могу дождаться, чтобы увидеть это, когда это будет сделано!

Я рад видеть, что все идет хорошо!

В настоящее время мы используем Grafana + Bosun + OpenTSDB в качестве нашего стека для мониторинга и оповещения. Я определенно согласен, что было бы здорово иметь силу боцмана с великолепным UX Grafana.

Вот пример того, где UX конфигурации Grafana лучше, чем у Bosun:

Контекст

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

Сравнение

С помощью HTTP API Grafana команды могут ПОСТАВЛЯТЬ свои собственные информационные панели при развертывании своего сервиса. В настоящее время Bosun имеет только один файл для хранения конфигурации; это затрудняет обмен между разными командами и в разных проектах.

@mattttt @torkelo @Dieterbe есть идея выпустить часть оповещения (или бета-версию)?

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

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

@mattttt, хотите ли вы сделать цвета исторической шкалы работоспособности настраиваемой? Зеленый и красный плохо сочетаются с дальтонизмом;)

Что касается предупреждений: меня очень интересует, как это закончится. Мы уже некоторое время собираем и визуализируем данные, и в настоящее время мы пытаемся понять, в чем заключаются предупреждения. У Графаны могло бы быть хорошее место там, тем более что визуализации уже на месте. Но вот что мне интересно: насколько Grafana должна быть более осведомлена о «сущностях», а не о сериях показателей для предупреждений? Я могу представить, что хочу автоматически переключать изменение визуального состояния (проверка ping или http) или вручную (выполнение обслуживания) для того, что в моем случае было бы сервером, в дополнение к предупреждению на основе метрик.

Мне интересно посмотреть, куда идут оповещения в Grafana, но для тех из вас, кому что-то нужно сейчас, есть плагины nagios, такие как https://exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/details которые могут запускать предупреждения при превышении пороговых значений.

@baaym

Но вот что мне интересно: насколько Grafana должна быть более осведомлена о «сущностях», а не о сериях показателей для предупреждений? Я могу представить, что хочу автоматически переключать изменение визуального состояния (проверка ping или http) или вручную (выполнение обслуживания) для того, что в моем случае было бы сервером, в дополнение к предупреждению на основе метрик.

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

скажем, вы установили предупреждение в строке movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warn . это позволит проверить пороговое значение на всех ваших веб-серверах в данном кластере и сгенерировать предупреждения о любых нарушениях, таких как movingAverage(cluster1.web-123.cpu.idle,10) is currently 3! .
возможно, мы могли бы позволить вам сказать «первое поле - это имя кластера, второе - имя хоста» и т. д., чтобы предупреждения могли содержать более точную информацию.
но дело в том, что предупреждение _outcome_ содержит информацию, необходимую для определения того, у какого объекта есть проблемы, но это выходит за рамки возможностей Grafana. Grafana была бы скорее источником конфигурации правил предупреждений, а панели мониторинга Grafana могли бы быть настроены для загрузки аннотаций и прочего, чтобы визуализировать состояние предупреждений, но у него не было бы понятия высокоуровневых концепций, таких как хосты или кластеры. Я думаю, что с этим можно было бы справиться в обработчиках предупреждений.

@Dieterbe

При создании функции оповещения существует два типа проблем пользователей / организаций:

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

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

При сообщении о рабочем состоянии каждое предупреждение должно дополнительно содержать поле документации / ссылки для объяснения цели предупреждений и исторического поведения.

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

Я думаю, что @ deebs031 является хорошим должного внимания: «приложения, созданные для конечных пользователей, должны предоставлять определенные пользователем предупреждения».
IMHO Graal - это мониторинг на основе метрик самообслуживания , в моем случае Grafana является основным интерфейсом для людей, которые хотят смотреть на метрики, имеет смысл дать им возможность создавать оповещения для себя в одном и том же - пусть это УДИВИТЕЛЬНЫЙ - UI.
Я лично делал оповещения Sensu на основе показателей, но предоставление их в качестве самообслуживания на самом деле не так просто по сравнению с тем, насколько бесшовно это было бы при интеграции с Grafana. Я также посмотрел на Cabot, потому что у него были возможности визуализации, но он не был построен с учетом самообслуживания, поэтому не мог использовать его как есть.
Я сторонник того, чтобы «делать что-то хорошо», но я думаю, что в конкретном случае оповещений самообслуживания, основанных на метриках, сочетание этой возможности со слоем визуализации метрик имеет большой смысл:

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

слайды моей презентации графанакон об оповещениях:
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
их сложно понять без контекста, видео должно быть онлайн примерно через неделю, я опубликую его, когда оно будет готово.

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

предполагается, что вы хотите использовать выбранную вами программу оповещения (bosun / cabot / sensu / nagios / ...)
поэтому был бы отдельный инструмент, который запрашивает grafana через его http API, чтобы получить все правила оповещения. этот инструмент может затем обновить вашу конфигурацию bosun / cabot / sensu / nagios / ..., чтобы вы могли использовать выбранную вами программу оповещения для запуска и выполнения оповещений и отправки уведомлений.
но мы хотим иметь возможность правильно визуализировать текущее и историческое состояние, поэтому либо ваша программа оповещения должна иметь возможность вызывать скрипт, либо веб-перехватчик, либо что-то еще, чтобы информировать графану о новом состоянии, либо графана должна будет запрашивать его. (что кажется противным, учитывая, что у большинства инструментов, похоже, нет отличных API)
это все немного сложно, но это должен быть способ поддержки людей, для которых важно, чтобы они могли использовать свое программное обеспечение для оповещения по своему выбору, используя графану для определения правил оповещения и визуализации состояния.

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

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

Является ли встроенный исполнитель предупреждений (см. Выше) чем-то, что, по вашему мнению, будет достаточно для обработки всех правил предупреждений, которые вы установили в Grafana?

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

@jaimegago аминь;)

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

Именно так было сказано, если все остальные не согласны;)

Быстрое редактирование: потрясающие слайды. Если конечный продукт выглядит наполовину так же хорошо, как этот, то это потрясающе.

+1
Я согласен, что внутренний обработчик уведомлений с этой интеграцией идеален! для наиболее распространенного варианта использования.

Я буду рад пройти бета-тестирование :) и слайды будут потрясающими!

Я думаю, что последний пост

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

Мы отправим обработчик предупреждений Grafana, а также предоставим платформу для интеграции с выбранным вами программным обеспечением для предупреждений:

+1 для создания своего рода моста к другим системам оповещения (возможно, мы могли бы подумать о реализации какой-то общей системы плагинов оповещения :-))

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

@grobie , хороший улов, исправлено в исходном комментарии.

@mattttt @Dieterbe , это здорово! Похоже, вы идете по пути «батарейки в комплекте, но съемные», что, по-моему, лучшее из обоих миров. Вы уже думали о том, как вы собираетесь передавать данные авторизации обработчику предупреждений? Я думаю о такой истории:
Как пользователь Grafana я хотел бы получать уведомления через _email_ и / или _pagerduty_ и / или _foo_, когда (какое-то условие, созданное с помощью пользовательского интерфейса оповещения Grafana) происходит.
Этот пользователь должен иметь возможность отправлять оповещения только в систему уведомлений, для которой он авторизован, это требование для самообслуживания, и его нужно будет каким-то образом решить. Начиная с Grafana 2, у нас есть серверная часть SQL + аутентификация / авторизация пользователей с интеграцией LDAP, поэтому не кажется ли, что у нас есть такая возможность с первого дня оповещения?
С Sensu (это инструмент, который я бы подключил) передача цели предупреждения (например, адреса электронной почты) через обработчик должна быть довольно простой, не могу сказать о других.

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

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

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

Продолжайте хорошую работу, ребята!

Ваше здоровье

Я хотел бы увидеть общий обработчик HTTP POST, который запускается сразу же при появлении предупреждения. Я думаю, что большинство администраторов могут быстро создать что-то, способное принимать HTTP, а затем делать с ним все, что им нужно (отправлять его nagios, riemann, younameit)

поэтому, если срабатывает предупреждение (скажем, «web123 имеет критический простой ЦП! значение 1 ниже порога 15») и мы отправляем эти данные в http-сообщение, как бы вы поступили с этим в nagios? вы имеете в виду, что nagios примет это как пассивную проверку службы, а затем nagios отправит уведомления?

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

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

поэтому, если срабатывает предупреждение (скажем, «web123 имеет критический простоя процессора! значение 1 ниже порога 15»), и мы делаем> http-сообщение этих данных, как бы вы справились с этим в nagios? вы имеете в виду, что nagios примет это как> пассивную проверку службы, а затем nagios отправит уведомления?

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

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

Ваше здоровье

Хотя я вижу логику в этой стратегии интеграции, я не могу не думать, что это немного излишне. Насколько я понимаю (и что я мог прочитать в теме), единственная причина, по которой большинство пользователей Grafana продолжают использовать автономную технологию оповещения, заключается в том, что Grafana ее не предлагает. Итак, не было бы более «бережливым» сосредоточиться сначала на части оповещений Grafana и разработать ее как компонент, который взаимодействует с остальной частью стека через API, чтобы другие участники могли имитировать поведение и создавать конкретные переходники позже?

tl; dr: сконцентрировавшись в первую очередь на создании собственных «батарей», у Grafana будет полнофункциональная система оповещения, которая впоследствии может превратиться в сервис для интеграции со сторонними инструментами оповещения.

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

Спасибо за обновления! В моем случае встроенные предупреждения в Grafana - это все, что мне нужно на данный момент. Я терпеливо и нетерпеливо ждал предупреждения Графаны.

Как я и обещал в IRC, вот наш пример использования:

У нас есть устаревшее приложение Rails, которое searches our logs за patterns и имеет
HTTP API для ответа, если некий pattern пересек thresholds и
таким образом имеет статус {OK,WARNING,CRITICAL} .

Threshold может быть либо:

• a status of CRITICAL если pattern вообще существует.
• что status равно WARNING если pattern встречается более X раз
  и status равно CRITICAL если найдено более Y раз.
• если pattern меньше 1 часа, тогда status будет OK ,
  менее 3 часов status равно WARNING иначе status равно
  CRITICAL .

Если я правильно понимаю эту функцию, Grafana будет поддерживать это использование
шаблон (конечно, через Logstash и Elasticsearch), когда эта функция и
Источник данных Elasticsearch полностью реализован?

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

• Самообслуживание - очень важно . Наши пользователи громко и четко заявили, что они хотят создавать непрерывные оповещения внутри Grafana.
• Единый рабочий процесс - я хочу минимизировать количество движущихся частей, а не увеличивать их. Как отметил @Dieterbe , сторонний обработчик предупреждений потребует не менее 4 шагов, в то время как внутренний обработчик предупреждений потребует только 1 (может быть, 2, если вам нужно определить метод уведомления для каждого порога? - не уверены в презентации).
• Тесная интеграция и отсутствие зависимости от сторонней инфраструктуры оповещения.

Несколько проблем:

• Каковы пороги проверки частоты?
• Как он справляется с частотой опроса, которая слишком высока для возврата данных? Журнал, предупрежден и поставлен в очередь или отброшен?
• Что касается масштабирования, обеспокоенный тем, что Grafana может не справиться с большим количеством проверок, высокой частотой и особенно с задержкой между источниками данных, что нам, вероятно, потребуется для добавления / масштабирования серверов Grafana для поддержки внутренних предупреждений. Я знаю это, потому что сейчас нам нужно несколько экземпляров сторонних обработчиков предупреждений. В этом случае, как мы могли бы беспрепятственно назначать или ставить в очередь проверки пороговых значений среди кластера серверов Grafana, особенно если проверки из одного источника данных? Исходя из опыта пользователя, я бы хотел, чтобы пользователи без проблем создавали пороговые значения с помощью кластера серверов Grafana с балансировкой нагрузки, не заставляя пользователей переходить к конкретному «назначенному» экземпляру Grafana для конкретной проверки.
• Для уведомлений будет ли это поддерживать какую-то архитектуру плагинов, чтобы уведомления можно было легко разрабатывать и интегрировать? В общем, нам нужно что-то, что может выполнять HTTP POST. Это наиболее часто встречается с такими, как PagerDuty, xMatters, VictorOps, Opsgenie и т. Д. Для каждого из них требуется немного другой формат, аутентификация и т. Д. Как ранее упоминалось в этом потоке, возможно, будет работать общий обработчик HTTP POST, который будет отправлять на настраиваемая служба HTTP, способная делать с ней все, что вы хотите. В качестве альтернативы также должна работать возможность настраиваемого сценария.
• Я предполагаю, что пороги могут быть установлены, получены и получены нарушения через API? Я думаю это было бы полезно

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

Но я не думаю, что это действительно должна быть тесная интеграция со всеми этими обработчиками предупреждений. Хороший, хорошо документированный api должен позволить людям, знакомым с этой системой, интегрироваться с небольшими усилиями. Мне кажется привлекательным слайд с «grafana api -> handler».

Скотт

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

Во всяком случае, некоторые мысли по поводу оповещения:

• Оповещение по отдельным показателям - отстой. Я работаю в компании, которая управляет тысячами серверов, и создание / настройка / управление отдельными предупреждениями для каждой серии показателей «% свободного дискового пространства» с технической точки зрения невозможно. Инструменты корпоративного мониторинга часто связывают несколько серий показателей с помощью регулярных выражений (или просто выражений с подстановочными знаками). StatsAgg был построен на той же предпосылке; несколько серий показателей связываются вместе, а затем для группы показателей выполняется проверка пороговых значений предупреждений с помощью одного «предупреждения». В масштабе такая возможность является необходимостью.
• Если принять мое предыдущее утверждение о том, что средство оповещения не должно выводить оповещения об отдельных показателях, то из этого следует, что инструмент должен иметь механизм для быстрого получения списка соответствующих показателей и значений показателей. Многие инструменты полагаются на запросы к хранилищам данных для получения списка метрик и значений метрик, и это решение, откровенно говоря, не очень хорошо работает в масштабе. Логика предупреждений по своей природе должна выполняться часто (каждые X секунд или по мере поступления каждой новой квалифицируемой точки данных). Хранилища данных (graphite, opentsdb, Infxdb и т. Д.) Просто не были созданы для обработки постоянных запросов типа «дайте мне текущий список метрик, соответствующих этому шаблону» и «покажите мне последние значения X для этих метрик Y». У них либо нет соответствующего API / языка запросов, либо они просто не справляются с нагрузкой. Чтобы быть ясным, я говорю о масштабах выполнения логики предупреждений для 10 000 серий метрик, когда в хранилище данных имеется 10 000 000 доступных серий метрик. Это вариант использования не всех, но это моя компания.
• Я обнаружил, что решение проблемы с помощью потоковой обработки - единственный жизнеспособный способ решить проблемы, поднятые моим последним пунктом. Вот почему StatsAgg был создан для размещения перед хранилищем данных. Логика предупреждений может работать с метриками, не затрагивая хранилище данных, а метрики просто передаются в хранилище данных. Основные замыслы этого подхода заключаются в том, что 1) вновь созданные оповещения не могут / не будут использовать старые / заархивированные значения метрик для оценки оповещений 2) если программа обработки потока (например, StatsAgg) дает сбой, то точки данных не справляются с этим. в хранилище данных 3) значения метрик, необходимые для оценки предупреждений, хранятся в памяти, что может быть проблемой для стабильности сервера. 4) программа потоковой обработки должна иметь возможность деконструировать и реконструировать входящие метрики (что InfluxDB не упростил за последний год ...). Даже с этим тщеславием это решение работало очень хорошо для моей компании и в очень большом масштабе. Время от времени у нас было 200000+ живых серий метрик, в среднем более 30 тысяч входящих метрик в секунду, сотни предупреждений, оценивающих тысячи серий метрик, и сервер, на котором запущен StatsAgg, который почти не вспотел. В то же время хранилище данных вообще не запрашивается.

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

Я хотел бы предложить запуск с обработчиком уведомлений, который может отправлять данные в Alerta: https://github.com/guardian/alerta

У Alerta есть очень разумный REST API для получения уведомлений.

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

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

Я настоятельно рекомендую реализовать только два типа обработчиков. Одним из них, безусловно, является HTTP POST, это будет наиболее универсальный и гибкий инструмент. Другой - это настраиваемые сценарии, поэтому пользователи могут реализовать интеграцию со своим конкретным инструментом по своему выбору. Модель плагина неплохая, но она заставляет использовать определенный язык плагина, что является ограничивающим. Внешние скрипты лучше - если вы передадите скрипту все детали, скрипт может быть написан на любом языке - скрипт оболочки, Python и т. Д.

Я с @ 007reader

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

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

Привет всем,
видео с моей презентацией графанакон онлайн!
это на https://www.youtube.com/watch?v=C_H2ew8e5OM
Я думаю, это многое прояснится, хотя, как видите. специфика интеграции еще предстоит выяснить, и это также была тема, которую хотели обсудить многие люди. (хотя время было ограничено, и я попросил людей продолжить разговор здесь, чтобы все могли принять участие)

@simmel, да, именно так. вы бы использовали запрос ES и установили для него правило.
@activars для группировки и обнаружения, я думаю, что многое из этого будет зависеть от вашего источника данных, но наиболее распространенные требования должны быть рассмотрены, если вы используете что-то вроде графита или ES, которые, как я знаю, очень хороши в "автоматическом обнаружении" ранее невидимых показателей / серий / документы, которые соответствуют заданному выражению (с подстановочными знаками) для графита или запроса (для ES). не уверен насчет других источников. ваш комментарий о необходимости применения исключений к правилам сложнее, нам, вероятно, придется заняться этим в какой-то момент, но я думаю, что это может подождать, пока все не прояснится и не уляжется. может быть, мы сможем как-то избежать нужды в этом.
Частота @mgravlin будет настройкой в ​​правиле,
@sknolin, если я правильно понимаю, на ваш взгляд, grafana будет выполнять планирование предупреждений, выполнение, запускать уведомления и т. д., даже при использовании другой системы, такой как nagios / bosun. тогда какова будет роль внешней системы (nagios / bosun / ...). похоже, это тоже похоже на то, о чем говорил @Crapworks .
@ jds86930 StatsAgg выглядит довольно интересно. Думаю, здесь тоже имеет смысл интеграция с графаной. Я считаю, что потоковая обработка - это допустимый подход, который может использоваться как альтернатива повторным запросам. но с последним проще начать работу и, как мне кажется, в целом проще. Но оба должны поддерживаться. Так что да, в Grafana вы сможете создавать шаблоны / запросы, которые соответствуют спектру данных и потенциально охватывают новые серии / данные, когда они становятся живыми. на наш взгляд, вы могли бы просто использовать любую функциональность, имеющуюся в вашем источнике данных (например, графит неплохо справляется с этим со своими подстановочными знаками, выражениями глобуса и т. д., а также с богатыми данными и моделью запросов elasticsearch), или если бы кто-то использовал grafana + StatsAgg, они могли бы просто используйте StatsAgg, чтобы решить эту проблему. Вы хотите сказать, что сама графана должна делать здесь что-то конкретное? Я думаю, что если ваш источник данных недостаточно быстрый, решите проблему с источником данных. получить что-то более быстрое, с кэшированием метаданных метаданных, возможно, с сервером памяти на переднем плане или потоковой обработкой. но в любом случае, что касается Grafana, мало что изменилось бы, о чем я могу думать?
@blysik да смотрится интересно. так много инструментов оповещения, с которыми мы должны интегрироваться :) чтобы быть ясным, вам нравится идея управления правилами оповещения и визуализации их в графане, как это было представлено до сих пор, но вы хотите использовать оповещения, чтобы позаботиться об уведомлениях ? будет главным местом, где вы можете посмотреть состояние своих предупреждений (что кажется разумным решением), но хотите убедиться, что я полностью понимаю, как вы видите интеграцию.

@ 007reader , @shanielh , @activars просто для ясности, эта интеграция через общий HTTP-пост или скрипт, какова будет цель. сообщить внешней системе: «Есть новое правило, вот запрос, пороговые значения, частота и т. д., теперь идите, пожалуйста, выполните его»? или графана будет тем, что выполняет правила, а затем обновляет внешние системы с новым состоянием?

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

Верный. Alerta становится нашим центром уведомлений. Всевозможные вещи, отправляющие в него предупреждения. Например: пользовательские скрипты, Cabot, Zenoss, vCenter и, возможно, Grafana. Это дает оператору единое место для просмотра всех предупреждений. И это единственное место, откуда отправляются уведомления инженеру по вызову.

@sknolin https://github.com/sknolin, если я правильно понимаю, в вашем
view, grafana будет выполнять планирование предупреждений, выполнение, триггер
ловушки уведомлений и т. д., даже при использовании другой системы, например
нагиос / боцман. тогда какова будет роль внешней системы
(нагиос / боцман / ...). это похоже на то, что @Crapworks
https://github.com/Crapworks говорила.

Думаю, я не очень хорошо объяснил. Это не то, что я хотел бы, графана не
делать все это. @Crapworks (это забавно печатать) говорит пассивно
сервисные проверки, я бы просто использовал активный опрос.

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

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

Скотт

@sknolin

Так что все, что мне нужно, это api, где я могу читать статус предупреждений Grafana.

как бы этот статус был обновлен в графане? какой процесс будет выполнять предупреждения и обновлять статус в графане?

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

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

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

Скотт

@Dieterbe Последний:

grafana - это то, что выполняет правила, а затем обновляет внешние системы с новым состоянием

@Dieterbe Я согласен с тем, что опрос источника данных (Graphite, OpenTSDB и т. Д.) С использованием собственного синтаксиса запроса источника данных является самым простым / легким и, вероятно, самым быстрым способом получить некоторую форму предупреждений непосредственно в Grafana. Для многих людей такое решение удовлетворит их потребности, и я думаю, что это лучшее решение для первоначальной реализации Grafana (на мой взгляд). Моя основная мысль заключалась в том, что существует предел конфигурируемости и производительности предупреждений, который будет трудно преодолеть с помощью модели «опрос источника данных».

Что касается направлений, в которых Grafana могла бы предложить долгосрочные решения для оповещения, я мог видеть несколько вариантов:

• Работайте со специалистами по обслуживанию хранилища данных, чтобы создать более быстрые / лучшие специализированные API-интерфейсы для сценария использования предупреждений. Мне не нравится этот вариант, потому что многие из этих проектов продвигаются медленнее (от месяцев до лет), и они могут не принять некоторые / все запросы на улучшение. Они, вероятно, также захотят писать код на родном языке своих хранилищ данных, который не всегда быстр (например, Graphite в python).
• Создавайте уровни потоковой обработки / кеширования для каждого хранилища данных как отдельные проекты raintank. Я думаю, что это в конечном итоге даст лучший результат, чем попытки уговорить различных специалистов по обслуживанию хранилищ данных разработать решения для своих проектов. Это также позволит вам продолжить работу, которую вы уже выполняете (используя существующие механизмы запросов к хранилищу данных). Вы даже можете встроить свои собственные пользовательские API в уровни потоковой обработки / кеширования, которые могут упростить синтаксис запросов Grafana для хранилища данных.
• Придерживайтесь собственного решения, над которым вы работаете, и сделайте так, чтобы оно хорошо работало. Сторонние инструменты, такие как StatsAgg, bosun и т. Д., Будут доступны для более требовательных / специализированных / сложных случаев использования. Интеграция Grafana с этими инструментами определенно была бы дополнительным преимуществом для пользователя, но добавила бы Grafana нетривиальной сложности. Тем не менее, похоже, что вы все равно можете это сделать (прямо сейчас я смотрю «Предупреждающие серверы» на слайде 35 вашей презентации). Я лично готов реализовать дружественный к Grafana набор API в StatsAgg; нам просто нужно было понять, что такое API, и составить проект документации по протоколу API. Не стесняйтесь написать / написать мне, если вы хотите обсудить что-либо из этого.

Всем привет,

@Dieterbe Я только что посмотрел вашу презентацию, и все выглядит потрясающе. Я действительно ценю, что вы пытаетесь построить систему оповещения «правильным» способом, используя большой вклад сообщества! Спасибо!

Я также хочу прояснить свою точку зрения, поскольку не думаю, что было очевидно то, что я пытался сказать. Я _НЕ_ НЕ требую, чтобы графана была осведомлена о любой другой системе мониторинга, такой как Nagios, Icinga, Bosun и т. Д. Мне на самом деле нужно только это:

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

Поток событий, о котором я думаю:

• Вы визуализируете свои данные в графане
• Вы добавляете пороги для алертов в графане
• Как только порог превышен, запускается обработчик HTTP POST
• С этого момента работа с графанами закончена.

Подобно упомянутым @mgravlin и @ 007reader , большинство служб уведомлений и предупреждений используют HTTP POST, запрашивая разные типы данных. Итак, самая общая вещь, о которой я мог подумать, - это позволить пользователю определять свои данные POST и заголовки, чтобы вы могли кормить несколько систем одним обработчиком, используя разные шаблоны. Пример псевдокода:

"notificator": {
    "httppost": {
        "data": {
            "host": "$hostname",
            "alert": "$alertname",
            "state": "$state"
        },
        "header": {
            "content-type": "application/json"
        }
    }
}

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

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

Поскольку это безгражданство, оно также масштабируется. Просто поместите балансировщик нагрузки перед backend / api / something, и все готово.

По крайней мере, это решило бы большинство / почти все мои проблемы;)

Ваше здоровье

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

Торкело сказал ГРАФИЧЕСКИ 3 месяца на IRC.
Если я правильно его понял, это действительно грубая оценка, и к ней следует относиться соответствующим образом.

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

Если у вас есть ранняя альфа / бета-версия, я хотел бы протестировать и дать раннюю обратную связь с производственными данными.

++

Мне 2 лол

+1

Сег, 16 ноя 2015 в 21:03, Jing Dong [email protected]
escreveu:

Если у вас есть ранняя альфа / бета-версия, я хотел бы протестировать и дать пораньше
обратная связь с производственными данными.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -157202686.

+1
Если у вас есть ранняя альфа / бета-версия, я хотел бы протестировать и дать раннюю обратную связь с производственными данными.

+1 мне 2

2015-11-21 14:44 GMT-02: 00 chaosong [email protected] :

+1
Если у вас есть ранняя альфа / бета-версия, я хотел бы протестировать и дать пораньше
обратная связь с производственными данными.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -158661279.

+1

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

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

+1>; п

Пн, 30.11.2015, 10:33:52 -0800, Вадим Чекан написал:

Да, пожалуйста, 484 человека «смотрят» этот выпуск. Каждый раз, когда вы ставите +1, 484 человека получают уведомление по электронной почте.

Извините, я знаю, что вы, ребята, очень много над этим работаете. Есть ли сроки выхода первого релиза?

Я был бы более чем счастлив, если бы имел возможность настраивать метрики и пороговые значения предупреждений (через веб-интерфейс или API) и cronjob / демон Grafana, который проверяет эти метрики и выполняет HTTP POST с JSON или вызывает скрипт с JSON в stdout. Для людей было бы чрезвычайно просто написать простой скрипт на Python, который передает эту информацию в Pagerduty, Slack, IRC, SMS, электронную почту или что-то еще.

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

Полностью согласен с @anlutro . Для начала предоставьте что-нибудь простое. Для меня самое интересное - дать возможность людям самостоятельно устанавливать простые оповещения (самообслуживание). Grafana не должна пытаться заменить существующие решения для оповещения / эскалации.

Я также согласен с @anlutro . Но вместо того, чтобы просто предоставлять простой api, лучше используйте часть оповещения, способную обрабатывать настраиваемые плагины, которые взаимодействуют с api. Таким образом, базовый пакет может включать электронную почту, pagerduty и несколько других, а сообщество может добавлять к нему по мере необходимости. Аналогично тому, как сейчас обрабатываются плагины Logstash.

+1

Есть новости о системе оповещения? Есть оценки?

+1

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

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

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

@Dieterbe @torkelo Было бы здорово иметь хотя бы очень приблизительную "догадку" по этому поводу. Лично я придерживался этого мнения, поскольку самообслуживание на основе метрик - очень необходимая функция в моем случае, и я убежден, что Grafana - правильный пользовательский интерфейс для этого. Проблема в том, что прошло уже 6 месяцев, и давно не было обновлений ETA или даже комментариев от одного из вас, поэтому у меня появляются контрпродуктивные мысли: «Мне просто нужно что-то взломать». .. Если бы я мог просто знать, будут ли это еще 6 месяцев или еще несколько недель, я мог бы принять гораздо более обоснованное решение.

Спасибо!

+1
18 января 2016 г. в 21:54 «Хайме Гаго» [email protected] написал:

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo Было бы здорово иметь даже очень грубый
"предположить" по этому поводу. Лично я держался с тех пор, как метрики
основанное на самообслуживании оповещение - очень необходимая функция в моем случае, и я
убежден, что Grafana - правильный пользовательский интерфейс для этого. Проблема в том, что это сейчас
прошло 6 месяцев, и не было обновлений ETA или даже комментариев одного из
вы в течение некоторого времени, поэтому я начинаю думать "Мне просто придется
взломать что-нибудь "контрпродуктивные мысли ... Если бы я только знал, что это
будет еще 6 месяцев по сравнению с еще несколькими неделями, я мог бы заработать много
более обоснованное решение.

Спасибо!

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -172722684.

+1

+1

@jaimegago очень извиняюсь за то, что не

Еще в сентябре я начал работать над поддержкой источников данных Elasticsearch, которая стала основой для выпуска 2.5, ориентированного на источники данных, после этого проблема с наивысшим рейтингом в Grafana, поскольку v1 была табличной панелью, и особенно после поддержки Elasticsearch я почувствовал небольшой выпуск с таблицей панель была важнее предупреждений, поэтому она стала основой для 2.6.

В последнее время у нас появилось много пользователей и компаний, желающих больше интегрироваться с Grafana, что побудило нас поработать над улучшением API и возможностей плагина, что привело к очередной отсрочке решения этой проблемы. Мне очень жаль, что мы так плохо об этом сообщили. У нас всегда были амбиции начать СКОРО, но СКОЛЬКО нам снова и снова давили :(

Но есть надежда! Мы расширили штатную команду Grafana, в декабре к нам присоединился

@torkelo Спасибо за обновление; Не могу сказать, что я счастлив, но, по крайней мере, мы знаем, где мы находимся.

Остается один вопрос: будет ли 2.x получать больше точечных выпусков или 3.x будет следующим выпуском. ;)

@RichiH насчет другого точечного релиза, не уверен, но вполне вероятно, что еще один точечный релиз до 3.0 будет выпущен в феврале.

@torkelo Большое спасибо за то, что

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

+1 для уведомлений SNMP!

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

+1

Любой администратор (@Dieterbe?) Может заблокировать комментирование этой проблемы от лиц, не являющихся соавторами? Так что мы будем получать только интересный контент о продвижении функций, а не бесполезные +1 ...

Если вы не знаете эту функцию, вот ссылка на специальный документ GitHub .

Спасибо: heart:

@Mayeu эээ, как один из "не-соавторов", который внес больше чем +1 в эту проблему и в других местах, я не думаю, что блокировка этой проблемы для соавторов - это выход. Просто создайте умный фильтр для своей электронной почты ;-).

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

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

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

Что касается системы голосования, чтобы предотвратить накопление +1, см. Https://github.com/dear-github/dear-github - 27 дней просрочено и никакой реакции со стороны GitHub.

+1

Есть новости об этом?

Я не думаю, что пока что есть новости по этому поводу. Но что хорошо в следующем выпуске Grafana:

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

Мне нравится идея настраивать оповещения в одном месте с визуализацией. Удивительные насмешки на https://www.youtube.com/watch?v=C_H2ew8e5OM, но есть ли даты, когда он будет выпущен?

хорошее видео, спасибо!

некоторая обратная связь.

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

уведомители самые полезные:

• exec - можно использовать что-то вроде ssh или sendmail
• webhooks - пользователь может установить webcgi, чтобы подбирать веб-хуки, чтобы делать что-то ...
• email - запустить простое электронное письмо с json-дампом данных уведомления.
• плагины ... на самом деле не нужны

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

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

+1

+1

Это очень необходимая функция для нас, сотрудников Work Market.

Запущены ли оповещения?

Нет
25 февраля 2016 г. в 23:13 kskaran94 [email protected] написал:

Запущены ли оповещения?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -189143056.

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

_suspense усиливается_
26 февраля 2016 г., 10:23, «Ян Ха» [email protected] написал:

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

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -189320869.

есть новости об этом?

+1

+1 было бы неплохо уже, люди ждут уже целый год, а то и больше.

: +1: Мне это нравится. Спасибо за видео и презентацию, @Dieterbe. Доступно ли это для тестирования / первых пользователей?

@torkelo Вы объявили

Мы хотим, чтобы эта функция стала заголовком для Grafana 3.0.

Но, глядя на журнал изменений невыпущенной ветки 3.0 (1), не упоминается об оповещениях, должен ли я начать плакать или в планах по-прежнему есть функция заголовка Alerting 3.0?

(1) https://github.com/grafana/grafana/blob/master/CHANGELOG.md

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

@Dieterbe Не могу сказать, что я счастлив, но в этом есть смысл. Очевидное последующее действие - есть ли что-нибудь в стиле ETA для оповещения; и если это подтвержденная и подтвержденная функция для 3.1.

Кроме того, в качестве обходного пути http://alerta.io/ выполняет часть того, что я хочу, чтобы Grafana выполняла; люди, ожидающие этой функции, могут захотеть попробовать.

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

Бет
16 марта 2016 г., 8:44, "Ричард Хартманн" [email protected]
написал:

@Dieterbe https://github.com/Dieterbe Не могу сказать, что я счастлив, но это
имеет смысл. Очевидное продолжение - есть ли что-нибудь в стиле ETA для
оповещение; и если это подтвержденная и подтвержденная функция для 3.1.

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -197214149

@Dieterbe Я думаю, было бы неплохо иметь возможность создавать уведомления на стороне клиента. Например, голосовые сообщения на общедоступном мониторе с приборной панелью, поэтому вам не нужно смотреть на приборную панель, чтобы знать, что есть какие-то проблемы. Как звуковые оповещения Zabbix. Для этого я написал простой код JavaScript, который сканирует конкретную панель управления и, если есть какие-то проблемы, уведомляет меня с помощью Web Speech API . На данный момент он отлично работает для меня.

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

Теперь, когда вышла версия 3.0, я очень рад, что, надеюсь, у меня появятся предупреждения в графане. Предупреждение сделает графану идеальным инструментом.

Привет @Dieterbe!

Как я могу видеть из этой версии https://github.com/raintank/grafana (о которой вы сказали, что у него есть пакет предупреждений), репо теперь устарело, и в нем говорится, что вся новая разработка идет в https: // github. com / raintank / worldping-api. Это заставляет меня задаться вопросом, разрабатывается ли эта функция предупреждений или она была запланирована и изменена для чего-то еще (например, worldPing, который не похож на то, что мы здесь обсуждали).

Привет, @minhdanh , цель всегда заключалась в том, чтобы добавить оповещение «должным образом» в графану, а не просто как взлом в вилке, специфичной для raintank, о котором вы говорите (и это в любом случае охватывало только очень узкую область, хотя может иметь смысл повторно использовать часть этого кода, как только мы начнем работу над планировщиком / исполнителем, который был в этом репо). Вот почему мы усердно работали над тем, чтобы графана могла быть подключена к предстоящему выпуску Grafana 3. (и, как результат, это позволило нам перенести наши собственные потребности в отдельное приложение, о котором вы говорите worldping-api).
Стало очень ясно, что в качестве первого шага мы должны просто создать пользовательский интерфейс для управления правилами изнутри ваших панелей и панелей Grafana и выставлять их через какой-то api, чтобы плагины могли использовать их для их выполнения. Это будет самый быстрый способ подать оповещение. "батарейки, включенные в планировщик / исполнитель" затем появятся позже и могут повторно использовать часть кода, на который вы ссылались.

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

Спасибо @dieterbe.

Как всегда, возникает вопрос о приблизительных сроках, даже если это всего лишь "не
перед X ».

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

Ричард

Отправлено с мобильного телефона; извините за краткость.

Всем привет,

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

@flyersa , большое спасибо за вклад! Как мы можем положить наличные?

Джон

Всем здравствуйте,

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

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

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

Мы пытаемся найти баланс между прибыльностью и скоростью, и мы ОТЛИЧНО ценим коммерческую поддержку наших клиентов, таких как @flyersa. Если другие хотят поддержать разработку этой функции и Grafana в целом, рассмотрите возможность приобретения плана поддержки . Это поможет нам разработать отличное программное обеспечение со 100% открытым исходным кодом.

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

-raj dutt | генеральный директор / соучредитель | дождевая банка

Привет @ nopzor1200!

Спасибо за ваше сообщение. У вас есть оценка, когда будут доступны оповещения?

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

10x!

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

• Каждый хост, за которым я хочу наблюдать, выдает «Проверки». «Чек» состоит из:
  
  
  
  • имя хоста
  
  
  • отметка времени
  
  
  • Состояние: 0 = ОК, 1 = ПРЕДУПРЕЖДЕНИЕ или 2 = КРИТИЧЕСКОЕ
  
  
• Эти проверки могут поступать из множества произвольных источников (сценарии оболочки + cron, statsd / collectd, проверки Nagios и т. Д.) И накапливаются в Elasticsearch. Одна и та же проверка может иметь разные конфигурации на разных хостах, но это будет непрозрачно для Grafana.
• Я настрою Grafana подключиться к Elasticsearch и буду предупреждать, когда любая проверка, исходящая от любого хоста, имеет значение State> = 1.
• Если к кластеру присоединяются новые хосты, конфигурация Grafana не требуется; Grafana просто увидит любую точку данных в состоянии 1 или 2 независимо от того, откуда она пришла.
• Если хост внезапно умирает и перестает передавать чеки, нам нужно это обнаружить. Чтобы справиться с этим, когда хост запускается, он зарегистрирует главную проверку как статус «ВКЛ», и значение перейдет в «ВЫКЛ», только когда он будет нормально остановлен. Таким образом, я могу найти все "включенные" хосты, которые не отправляли проверки за последние X секунд.
• В общем, я не буду использовать предупреждения на основе пороговых значений для данных временных рядов в Graphana. Другими словами, я не буду выполнять «проверку использования ЦП> 80%» в самой Grafana, а скорее, Grafana получит проверку «Состояние использования ЦП» (0/1/2) и предупреждение в состоянии 1 или 2.

Привет @johnnyshields ,

Выглядит неплохо, но вместо «0 = ОК, 1 = ПРЕДУПРЕЖДЕНИЕ или 2 = КРИТИЧНО» почему бы не использовать стандартное определение уровня? Тот, который используется syslog, в значительной степени является стандартом де-факто для следующих вещей:

• Значение -> Серьезность
• 0 -> Авария
• 1 -> Предупреждение
• 2 -> критическое
• 3 -> Ошибка
• 4 -> Предупреждение
• 5 -> Уведомление
• 6 -> Информационное
• 7 -> Отладка

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

Учитывая это, я бы добавил в ваш пост следующие изменения:

• предупреждение, когда любая проверка, исходящая от любого хоста, имеет значение состояния> = CONFIGURABLE_ALERT_LEVEL.
• Grafana просто увидит любую точку данных в состоянии> = CONFIGURABLE_ALERT_LEVEL независимо от того, откуда она пришла.
• Grafana получит уровень проверки «CPU Usage State» и предупреждение, если настроено соответствующим образом.

@brunorey, спасибо, имеет смысл!

Уровни журнала и состояния - это разные вещи. Вы могли бы иметь 6-информационное сообщение журнала, но как что-нибудь может быть в 6-информационном состоянии?

Состояния ОК, ПРЕДУПРЕЖДЕНИЕ и КРИТИЧЕСКОЕ нормальны и могут быть слишком хорошими для тех, кто заботится только о ОК и КРИТИЧНО. Добавление большего количества состояний добавляет путаницы, если их значение не понимается повсеместно, и я предлагаю ограничиться тремя.

Что касается только предупреждений о «состоянии ЦП> = ПРЕДУПРЕЖДЕНИЕ» против «ЦП> 80%», я утверждаю, что некоторые люди захотят сохранить свои трехуровневые состояния в базе данных временных рядов, чтобы они могли видеть, как состояние меняется с течением времени. Эти люди будут предупреждать на основе данных своего временного ряда. Другие захотят предупредить о том, что необработанное значение ЦП превышает 80%. Дело в том, что нужно только предупреждать о данных временных рядов.

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

Например, рабочие серверы обычно имеют ЦП почти на 100%, и это не проблема - я хочу, чтобы они работали на полную мощность на всех ядрах. Но веб-серверы не должны иметь ЦП выше 20%. Так что, если бы я сделал общий ЦП> 80%, это было бы слишком высоко для веб-сайтов и слишком мало для рабочих. (Это всего лишь один случай).

@johnnyshields Я не понимаю, почему вы не использовали бы предупреждения на основе пороговых значений для данных временных рядов, ИМО, вот где действительно сильная (единственная?) ценность добавления предупреждений в графана / графит. Ваш стиль "в шахматы" лучше подходит для чего-то простого, например, monit - я что-то здесь пропустил?

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

Кроме того, некоторые проверки являются «да или нет», например, запущен ли процесс X, отвечает ли эхо-запрос на порт Y и т. Д.

Понял. Иногда определить эти состояния просто (> 80%), а иногда сложно. Когда они сложны, некоторый код определяет уровни и отправляет их в базу данных TS. Это обычная практика, когда данные преобразуются в информацию. Я хочу сказать, что нет никакой разницы от чувства предупреждения.

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

Упростите систему оповещения. Скрыть сложность в конвейере TS.

Преимущество создания новых данных TS в конвейере по сравнению с системой предупреждений, основанной на правилах, заключается в том, что они позволяют визуализировать предупреждения и упрощают их настройку и получение предупреждений. Есть визуализация, которая может быть отправлена ​​по электронной почте или sms, показывая только то, о чем предупреждают - даже если это простая диаграмма состояний, где они видят, что состояние перешло с WARN на CRITICAL 20 минут назад.

Я думаю, что если вы хотите контролировать то, что считается заслуживающим внимания для каждого хоста / роли, вы также можете добавить логику к тому, что считается WARN и что считается CRIT, как вы добавляете 8 уровней детализации к серьезности тревога.

Похоже, что почти все другие современные системы оповещения сошлись на OK / WARN / CRIT, и, хотя, вероятно, отчасти это связано с желанием совместимости с проверками Nagios, я думаю, что идея простой простоты более важна. Если Grafana сделает то же самое, интеграция с другими службами оповещения / мониторинга будет проще. Например, в моем случае я, вероятно, в конечном итоге отправил бы оповещения Grafana в Sensu, который затем отправил бы электронное письмо, сообщение о задержке или что-то еще. У Sensu есть только OK / WARN / CRIT, поэтому дополнительная детализация будет потрачена впустую.

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

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

12 мая 2016 г. в 8:49 RWhar [email protected] написал:

@johnnyshields Я не понимаю, почему вы не использовали бы предупреждения на основе пороговых значений для данных временных рядов, ИМО, вот где действительно сильная (единственная?) ценность добавления предупреждений в графана / графит. Ваш стиль "в шахматы" лучше подходит для чего-то простого, например, monit - я что-то здесь пропустил?

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую или просмотрите его на GitHub

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

Кроме того, было бы неплохо иметь вариант, при котором предупреждения могут запускаться при пороговом значении и определенных интервалах после порога - например, установка порога предупреждения «rpl_delay» 200 int 50 - вызовет предупреждения на 200, 250, 300 и т. Д. Без необходимо вручную указать дополнительные пороговые уровни.

@johnnyshields Я не понимаю разницы между 1 = WARN или 2 = CRITICAL. Предупреждение либо срабатывает, либо не срабатывает. Вы либо выше 80%, либо не выше 80%. Поэтому я вижу только два состояния: 0 и 1.
Также было бы неплохо иметь более умные оповещения, позволяющие определять, что вы превышали 80% в течение 5 минут подряд, чтобы не получать оповещения о временных всплесках. Еще более продвинутыми являются такие вещи, как изменение пороговых значений, когда, например, вы отслеживаете трафик своего веб-сайта и получаете X объем трафика, который медленно увеличивается, скажем, на 1% в месяц, но внезапно вы получаете 10% -ный всплеск трафика в час. Вы также хотели бы иметь возможность отслеживать противоположное - внезапное падение трафика. Что-то похожее на https://github.com/etsy/skyline, поскольку Skyline не работает.

Ребята, в моем сообщении здесь не говорилось о точном количестве используемых состояний предупреждений - я спрашивал в более общем плане: "Будет ли Grafana поддерживать перечисленные состояния в качестве варианта использования предупреждений?"

Поскольку есть разногласия по поводу оптимального числа (Nagios использует 3, syslog использует 7, некоторые люди любят 2 и т. Д.) Grafana должна поддерживать произвольное количество состояний.

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

Причина выбора WARN vs. CRITICAL заключается в том, что вы выполняете разные действия. Одна группа людей и действий обычно получает уведомление о WARN, а другая группа / разные действия - о CRITICAL.

Это довольно ценное различие, и я бы не хотел отказываться от него с системой 0-1.

@lorenwest, если вам нужна другая проверка для другого порога, создайте дополнительный порог для этой отдельной группы.
поэтому каждый порог равен 0 или 1.
Например, еще одна причина, по которой вы хотели бы настроить оповещение таким образом, - это электронная почта, когда порог превышает 70%, но страница, когда вы превышаете 80%. Так же, как вы хотите отдельные группы. WARN vs. CRITICAL слишком двусмысленны.

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

так:

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

чтобы привести пример:

• У меня есть некая метрика со значениями 0 = ОК, 1 = ПРЕДУПРЕЖДЕНИЕ, 2 = КРИТИЧНО.
• Настраиваю 3 алерта:
  
  
  
  • если значение = 1, показывать желтый флаг на моей панели инструментов
  
  
  • если значение = 2, показывать красный флаг на моей панели инструментов
  
  
  • если значение> = 1, пришлите мне электронное письмо
  
  

Всем здравствуйте,

Я не знаю, подходящее ли это место, чтобы спросить об этой теме, но я попробую любым способом в отношении предстоящего модуля предупреждений Grafana.
В нашей организации у нас есть все наши датчики предупреждений безопасности, которые используют Logstash / Elasticsearch для событий, и мы используем Yelp / elastalert для выполнения предупреждений с определенными шаблонами со следующими критериями:

"Match where there are X events in Y time" (frequency type)
"Match when the rate of events increases or decreases" (spike type)
"Match when a certain field matches a blacklist/whitelist" (blacklist and whitelist type)
"Match on any event matching a given filter" (any type)
"Match when a field has two different values within some time" (change type)

Кроме того, при обнаружении критериев предупреждения мы выполняем внешний скрипт Python с аргументами, который передает аргументы из Elastalert в скрипт с такой информацией, как поле IP-адреса источника / назначения, поле события и отметки времени, и наша система NAC позаботится об этом.

Теперь, глядя на модуль Grafana Upcoming Alerting и с Elasticsearch в качестве источника данных, мне интересно, сможет ли модуль Grafan Alerting сотрудничать так же, как Elastalert, и в конечном итоге заменить указанную выше информацию?
пожалуйста, порекомендуйте

Спасибо

Я знаю, что команда Grafana усердно работает над этим, и этот поток длинный, но я хочу отметить, что Kapacitor только что объединил функцию, которая значительно упростит разработку приложений для настройки предупреждений во внешнем интерфейсе: infxdata / kapacitor # 577

Насколько я понимаю, цель на стороне Grafana - сделать подключаемый бэкэнд оповещения (так же, как Grafana поддерживает несколько хранилищ TSDB), но я хотел упомянуть в надежде, что Kapacitor получит первоклассную поддержку, когда функция оповещения Grafana будет выпущена. Похоже, он отлично подходит, как и InfluxDB + Grafana.

@ thom-nic спасибо за подсказку Kapacitor - это именно то, что я ищу ...

Риман тоже велик и очень силен. telegraf -> riemann (предупреждение) -> Influxdb <- grafana

Мы делаем успехи в ветке alertting_definitions.

Теперь у нас есть простая модель правил предупреждений, которую вы можете определить в пользовательском интерфейсе и через HTTP API. Вы можете получать правила, изменения правил, состояния правил через HTTP API. Простое планирование правил предупреждений и выполнение запросов и выполнение правил также начинают объединяться.

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

Текущая модель правил:

description
query: #A  (referencing a query in the metrics tab)
aggregation: avg
timerange:  3600   (seconds from now to look back when fetching data)
frequency: 60  (how often to execute alert rule query and evaluation rule)
critLevel: 80
warnLevel: 50

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

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

Простой запрос:

"alert": {
   "name": "CPU usage last 5min above 90%",
   "frequency": "1m",      
   "expr": "query(#A, 5m, now, avg)",
   "operator": ">",
   "critLevel": 90,
  },

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

"alert": {
   "name": "CPU usage last 5m is 20% higher compared to last 24hours avg",
   "frequency": "1m",
   "expr": "query(#A, 5m, now, avg) => percentDiff() => query(#A, 1d, now, avg)",
   "operator": ">",
   "critLevel": 20,
  },

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

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

Или выражение должно содержать оператор и уровни?

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

expr: "
let last5mAvg = query(#A, 5m, now, avg)
let last24hAvg = query(#A, 1d, now, avg)

return percentDiff(last5minAvg, last24Avg)
"

@torkelo :

1. вы проектируете это как отдельный компонент? В конечном итоге вы создаете сигнальный процессор, похожий на Kapacitor для Influxdb **, который сам излучает сигнал (0 = "хорошо", 1 = "предупреждать", 2 = "крит"). Можно ли будет отправить этот сигнал куда-нибудь, кроме Grafana, например A) в Nagios или B) передать его обратно в БД?
2. аналогично, будет ли у Grafana возможность не использовать указанный выше движок сигналов, а получать сигнал 0/1/2 от стороннего источника, такого как плагин Nagios, многие из которых уже существуют в дикой природе?

** = предоставлено Kapicator использует потоковую обработку таймсерий, тогда как ваш движок основан на опросе, но все же он излучает сигнал.

Спасибо за ваш вклад.

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

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

Если у вас есть только один руководящий принцип, вам потребуется простая визуализация предупреждения.

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

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

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

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

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

tl; dr совершенно новый язык может быть излишним и слишком сложным. Построение правил мышью = хорошо.

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

IIRC, Grafana хочет пойти путем «батарейки в комплекте, но съемные». Т.е. он должен работать автономно со встроенным механизмом оповещения, но также должен быть подключаемым к существующим платформам.

Я бы сказал, что он должен иметь несколько встроенных методов - электронная почта (предоставление хоста SMTP) и WebAPI / Webhook. Остальное может быть добавлено с плагинами, такими как интеграция с PagerDuty.

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

@GriffReborn, ты думаешь на другом уровне. Существующие серверные модули оповещения, о которых я уже упоминал, _ уже_ поддерживают такие выходы, как SMTP, PagerDuty и т. Д.:
https://docs.influxdata.com/kapacitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

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

@ thom-nic Я согласен. Основное внимание следует уделять созданию панели мониторинга предупреждений, которая может использовать существующие каналы информации предупреждений («агностик каналов»). Создание поддерживаемого Grafana облегченного механизма обработки сигналов (в идеале как автономного) должно быть второстепенной задачей.

@johnnyshields создавать новые панели, отображающие информацию из существующих

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

@torkelo, честно говоря, я не очень знаком с платформами оповещения, такими как bosun, и не знаю, как конкретно может выглядеть правильная интеграция. Я имел в виду то, что сказал http://de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarny ну, это то, что мы планируем сделать. Иметь API-интерфейсы для других бэкэндов оповещения, которые можно использовать для чтения правил, определенных в Grafana. Но мы не будем предоставлять мост, который считывает правила предупреждений из Grafana и переводит их в другой механизм выполнения правил.

Итак, одна идея, которая у нас сейчас есть, - определить простые правила, подобные этим

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

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

Похоже, лучшее из обоих миров. Обожаю эту идею! Являются ли функции «Evaluate Against» частью Grafana или они специфичны для TSDB?

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

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

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

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

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

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

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

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

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

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

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

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

Рад, что мы на одной странице @torkelo. Это соответствует описанию в исходном посте.

Я не хочу создавать совершенно новую платформу оповещения, чтобы привязаться к Grafana. Я надеюсь на то, что оповещения Grafana заменят NewRelic, но с потрясающими возможностями, которые дает Grafana. Возможность инициировать оповещение (будь то электронная почта, API или что-то еще), когда один из моих графиков достигает порогового значения ... это ЗОЛОТО. Вещи, меняющие жизнь.

Даже простые предупреждения о пороге были бы хорошим простым решением.

Если вы будете следовать этому правилу, вы станете золотым:

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

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

@woodsaj Я согласен с тем, что мы хотим поддерживать связь между тем, о чем вы предупреждаете, и тем, что вы видите, и мы никогда не обсуждали отказ от этого. Мы пытаемся провести мозговой штурм, насколько далеко зашли статические пороговые значения одного запроса, достаточно ли они подходят для версии 2 Grafana Alerting или версии 3? И зажечь дискуссию о том, какие ограничения в правилах предупреждений возможны при использовании одного запроса и статических пороговых значений.

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

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

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

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

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

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

Я не верю, что существует «правильный» однозначный ответ о том, на каком уровне следует предупреждать. Иногда это зависит от команд, важности сервиса, общей инфраструктуры (например, облако против оборудования, кластер против монолита) и т. Д. Таким образом, учитывая многоуровневые области действия, иерархия предупреждений кажется хорошей. Но я не думаю, что определение этих иерархий вообще можно поддерживать. Это большой объем работы, изменений, и часто встречаются отношения, которые не подходят для красивых деревьев в реальных системах. Книжная агрессия Google SRE:

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

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

Итак, для Grafana мои предупреждения могут отображаться на:

• Панель
• Группа панелей
• Панель управления
• Группа информационных панелей (которые, как я полагаю, будут иметь детализацию)

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

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

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

@torkelo Решение об оповещении всегда сводится к логическому (истина / ложь). Могут быть разные уровни (предупреждение, критика и т. Д.) Или даже нечеткая логика, но в конце концов это логическое решение. Графическое изображение этого bool на одной панели не всегда будет полезным.

Итак, $metric > $threshold - это самое простое предупреждение, и оно, конечно же, возвращает истину, если метрика превышает пороговое значение. Это хорошо вписывается в панель (визуализируйте метрику и визуализируйте порог внутри панели). Но для того, чтобы устранить предупреждающий шум, объем и условия имеют тенденцию расширяться за пределы этого в большинстве случаев (когда мы начинали работать над боцманом, я думал, что таких случаев будет меньшинство, не так много, оказывается, если вы хотите контролировать шум). Вы можете сказать что-то вроде:

Оповещать, если:

• ЦП выше 80% в течение X минут
• Задание A не запущено (мы знаем, что это увеличивает нагрузку на ЦП, и нам все равно), а задание A не выполняется более часа.
• Дитер выпил более 3 чашек Starbucks за последние 24 часа (потому что, когда у него есть больше, он делает глупые вещи, которые поднимают процессор, и мы не хотим предупреждать об этом)

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

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

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

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

alert1:
  select: CPU is above 80% for X minutes
  output: null
alert2:
  select: Job A is not running
  output: null
alert3:
  select: Job A has being running for more than an hour
  output: send alert
alert4:
  select: Dieter has had more than 3 cups of starbucks in the last 24 hours
  output: null

(alert joiner does simple true/false logic and perhaps can graph it.)
alert5:
  database: alerts
  select: alert1 & alert2 &!alert4
  output: send alert

@torkelo Я вытащил ветку собрал по инструкции. Но, к сожалению, я не вижу вкладки «Предупреждения» (представленной выше) на панели «График».
Вдобавок я обнаружил «alertting: enabled = false» в «Настройках сервера» раздела «Администрирование сервера». Это влияет на функцию оповещения? Есть ли какой-нибудь флаг сборки или времени выполнения, который я должен использовать?
пожалуйста посоветуй.

Я попробовал использовать последний код (ebada26b85d8410142c2942ef7ba78b17e88313c), включил оповещения и получил пользовательский интерфейс.

Но получил массу ошибок

EROR[06-17|14:38:23] Failed to extract alerts from dashboard  logger=alerting.extractor error="missing query.query"
EROR[06-17|14:38:23] Failed to save alerts                    logger=context userId=1 orgId=1 uname=admin error="Failed to extract alerts from dashboard"

Я пробовал с источниками данных InfluxDB, в режиме proyy и direct.

Этого чего-то ждут?

Да, пока не готов к тестированию.

Хорошо, хорошо знать.

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

да, мы надеемся объединить его в мастеринг, может быть, в середине июля там примерно

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

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

Пришла зима, будьте настороже :)

Во вторник, 12 июля 2016 г., в 1:41, c-val [email protected] написал:

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

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390,
или отключить поток
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
.

Дипак

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

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

1. Мы думаем о наших функциях с точки зрения «управления бизнес-процессами (BPM)»; а также
2. Мы используем «язык моделирования бизнес-процессов (BPML)», поэтому мы можем приступить к моделированию требований и реализаций в одном месте с UML.
3. Мы определяем нашу архитектуру на уровне предприятия.

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

• Оставьте графану в покое, это презентационный слой ! Если вы хотите добавить рабочий процесс для моделирования и определения правил генерации предупреждений, это нормально, но оставьте все как есть. Ведь именно поэтому панели и плагины были реализованы правильно?
• Оставьте данные там, где им суждено было быть. К показателям, которые звонят домой, следует относиться как к первоклассным гражданам, и постоянное сохранение их значений является высшим приоритетом. Находится ли он в кеше, documentdb, tsdb или на сервере sql, это не имеет значения. Подразумевается отказоустойчивость ... с правильным "выбором технологии", конечно, для архитектуры).
• Чтобы настроить доступность + масштабируемость, нам нужно использовать правильные структуры, которые были разработаны специально для этого: соответствовать сервис-ориентированной архитектуре («SOA»). На очень высоком уровне мы можем использовать протокол очереди сообщений для передачи и приема событий и сообщений по протоколу «AMQP». Забудьте пока о REST и HTTP ... Используя сервер очереди сообщений, такой как RabbitMQ или ZeroMQ, у нас есть распределенный, отказоустойчивый, высокодоступный коммуникационный конвейер, который могут использовать как издатели / отправители данных, так и рабочие / получатели для его обработки. Это «служебная шина предприятия». (Посмотрите эту презентацию, объясняющую ZeroMQ).
• Используйте язык запросов, созданный специально для разрозненных, несвязанных, составных моделей данных. Используя «базу данных графиков » и интерфейс запросов «

SPARQL позволяет пользователям писать запросы к тому, что можно условно назвать данными «ключ-значение» или, более конкретно, к данным, которые соответствуют спецификации RDF W3C. Таким образом, вся база данных представляет собой набор троек «субъект-предикат-объект». Это аналогично использованию в некоторых базах данных NoSQL термина «ключ-значение документа», например MongoDB.
[..]
Таким образом, SPARQL предоставляет полный набор аналитических операций запроса, таких как JOIN, SORT, AGGREGATE, для данных, схема которых является неотъемлемой частью данных, а не требует отдельного определения схемы. Однако информация о схеме (онтология) часто предоставляется извне, чтобы можно было однозначно объединить различные наборы данных. Кроме того, SPARQL предоставляет специальный синтаксис обхода графа для данных, которые можно рассматривать как граф, а рис.
..
https://en.wikipedia.org/wiki/SPARQL

Помните, что Grafana дала нам то, что Nagios никогда не делала, сводится к единственной точке отказа: отсутствию масштабируемости. Графана это «быстро» , как вы говорите , но вы не принимая во внимание тот факт , что вы только хранения и обработки данных временных рядов - не слой (ы) метаданных ,

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

Это должно привести в движение механизмы ... Мне нужно немного поспать (потянул всю ночь), и я буду работать над Частью 2. Не стесняйтесь пинговать меня @appsoa по скайпу или yomateo по IRC.

Между тем, некоторые угощения:

• Пример эталонной архитектуры, которую я создал с помощью SOA .
• Microsoft Azure Service Fabric: создавайте и используйте постоянно работающие масштабируемые распределенные приложения.

@talbaror В идеале вы должны захватить сообщения журнала NAC с помощью агента, например, с брандмауэром PIX, и просто отправить / воспроизвести их через rsyslogd или любой другой протокол, который использует сервер обработки событий.

Если у вас нет настройки службы обработки событий, вы можете использовать обработку правил Snort - Network Intrusion Detector . Пингуйте меня, если вам нужна помощь .. Я 4 года проработал в компании, занимающейся безопасностью как услуга;)

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

@torkelo, пожалуйста,

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

Надеюсь объединить его с мастером и сделать его доступным (за переключателем функций) в течение 2 недель, если все пойдет гладко. У нас еще нет установленной даты для следующей версии Grafana, будь то выпуск 3.2 в сентябре или более крупный выпуск 4.0 в конце октября.

@torkelo Надеюсь, мы получим уведомление как можно скорее. Ждет его.
Использование графана для кубернетов.

Для других людей, у которых уже есть statsd / graphite / grafana и которые просто ждут, что система оповещений Grafana будет готова к отправке первых оповещений, я нашел отличную альтернативу для использования тем временем, Сейрен: https://github.com / scobal / seyren

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

Похоже, команда добилась больших успехов в работе с функцией оповещения. Я верю в философию «делать что-то одно, но делать это хорошо». Не очень уверен, что размещение всей логики предупреждений внутри Grafana - лучшая идея. В любом случае, я просто написал небольшой демон node js "flapjack-grafana-Receiver" для публикации событий grafana в flapjack. Я, вероятно, открою его исходный код. Кому-нибудь интересно?

https://github.com/Charles546/flapjack-grafana-receiver

Обновление прогресса!

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

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

Определение правила

Новая модель правила предупреждений состоит из одного или нескольких условий. Условия могут быть разных типов. Прямо сейчас есть только тип запроса. Но позже мы можем добавить такие условия, как Time of day , или Day of week , или, что более интересно, Other alert (чтобы вы могли включить состояние другого правила предупреждения как условие).

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

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

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

Уведомления

На этой прошедшей неделе мы работали над уведомлениями, и все начинает складываться вместе!

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

Хотеть помочь?

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

[alerting]
enabled = true

Слияние с мастером

Мы очень близки к тому, чтобы объединить это в освоение и продолжить работу. Я надеялся сделать это до летних каникул (только что прошло 1 неделя), но все еще есть некоторые незначительные изменения схемы SQL, которые я хотел бы сделать перед объединением в master. Слияние с мастером БУДЕТ произойти к 19 августа, я обещаю :) После этого оповещения будут в последней ночной сборке 4.0, так что вам будет легко тестировать и сообщать об ошибках и отзывы.

Что остается?

Нам не хватает ряда функций, которые нам нужны в бета-версии.

• Больше редукторов и возможность менять редуктор (сейчас только в среднем)
• Уведомление по электронной почте выглядит как дерьмо
• Схема блокировки для веб-перехватчика
• Дизайн для страницы со списком предупреждений
• Просмотр истории предупреждений
• Просмотр истории предупреждений в виде аннотаций на графике
• Планировщик предупреждений и стабильность движка
• Улучшения планировщика предупреждений для распределения нагрузки (поэтому предупреждения не выполняются одновременно)
• Кластеризация планировщика предупреждений

Мне очень жаль, что эта функция работает так долго.

@torkelo, пожалуйста, имейте возможность

@torkelo Спасибо за обновление. Насколько я могу судить, это предназначено для оповещения внутри Grafana. Вы все еще следуете модульному курсу, изложенному в https://github.com/grafana/grafana/issues/2209#issuecomment -149351263?

Также спасибо тем, кто работает над этим скрытыми эльфами. Я подозреваю @Dieterbe , но не знаю.

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

@torkelo Мои мысли были в том же духе, поэтому я решил спросить.

Лично я забочусь о предупреждениях Prometheus, но был бы признателен за хорошую визуальную интеграцию с Grafana. Мне все равно, где я определяю правила, если они хранятся и выполняются Прометеем.

@bergquist Поскольку вы будете на promcon, сесть и поговорить о возможных подходах может иметь смысл. Если хотите, я буду совать разработчикам Prometheus, какое время подойдет лучше всего. Вечером до и / или после уборки может быть, а может и не быть тихого времени, чтобы сесть; Я могу сообщить вам, если хотите.

Привет @torkelo - выглядит отлично.

Я только что вытащил вашу ветку, и когда я тестирую будильник для ElasticSearch, я получаю сообщение об ошибке

firing false
timeMs 0.225ms
error tsdb.HandleRequest() error Could not find executor for data source type elasticsearch

... означает ли это, что ElasticSearch еще не поддерживается: cry:

ps в выводе процесса я получаю следующее:

EROR[08-04|09:15:00] Alert Rule Result Error                  logger=alerting.engine ruleId=1 error="tsdb.HandleRequest() error Could not find executor for data source type elasticsearch" retry=nil LOG15_ERROR="Normalized odd number of arguments by adding nil"

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

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

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

@RichiH Один из вариантов - создать приложение для графаны, как это делает bosun. https://grafana.net/plugins/bosun-app Но это не позволяет простым способом повторно использовать запрос / панель инструментов. Поговорим об этом подробнее на промконсоне. Ждем встречи с Вами! :)

Первоначально тоже нет поддержки infxdb?

я не знал, что это конкретно связано с графитом :( Мы также используем приток и
elasticsearch;)

В понедельник, 8 августа 2016 г., в 14:18, elvarb [email protected] написал:

Первоначально тоже нет поддержки infxdb?

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

Энрико Керн

Ведущий системный инженер

glispa GmbH
Sonnenburger Straße 73
10437 Берлин, Германия

тел: +49 30 5557130-17
факс: +49 30 5557130-50
скайп: flyersaenrico. [email protected]

---

Зитц Берлин, AG Шарлоттенбург HRB 114678B

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

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

+1 Оповещение + InfluxDB.

В понедельник, 8 августа 2016 г., в 6:01, Том Николс [email protected]
написал:

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

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

Дипак

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

Учитывая немедленную и долгосрочную работу по поддержке оповещений для различных источников данных, построение архитектуры плагинов go и т. Д., Разве не будет почти такой же объем работы (если не меньше) для создания сервера оповещений в NodeJS, чтобы он мог использовать существующие плагины источников данных?

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

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

+1 оповещение для ElasticSearch

Привет, мы ждали систему оповещений для ... OpenTSDB! Мы можем
надеюсь скоро получить его для OpenTSDB? (Может, когда?)

Большое спасибо команде!

2016-08-08 17:28 GMT + 02: 00 Слава Вишняков [email protected] :

+1 оповещение для ElasticSearch

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

+1 оповещение для ElasticSearch
Будет ли у него возможность запускать скрипт по тревоге?

Ребята, у вас еще есть ветка предупреждений в образе докера?

1. Запросы предупреждений работают только для запроса «А»? Это жестко запрограммировано?
2. Когда мы можем ожидать полностью работающую версию предупреждений? (19-е по-прежнему цель)
3. Когда можно ожидать, что Elasticsearch будет работать с предупреждениями?

Редактировать:

1. Могу ли я добавить более одного правила тревоги на график?
2. Могу ли я добавить информацию о тревоге в HTTP-сообщение? (панель управления / график / наблюдаемый_запрос / конфигурация_тревоги / запрос_предупреждения / порог / критерий_предупреждения / значение / наблюдаемый_временной_фрейм / время_оказания)

@ DEvil0000

1) Вы можете изменить любой запрос на вкладке метрик.
2) Полностью рабочий, смотря что вы имеете в виду. Мы планируем объединить его в мастеринг на этой неделе. Затем люди могут начать тестирование ночной сборки и оставить отзыв. Альфа-релиз в течение 2-3 недель, бета-версия и стабильная версия зависят от отзывов и от того, как быстро она может стать стабильной.
3) Elasticsearch сложен, требует большого количества кода для запроса и синтаксического анализа ответа во временные ряды, поэтому, вероятно, появится после добавления поддержки Prometheus и InfluxDB.

@torkelo
Я новичок в elasticsearch, grafana и go lang. И я думаю, вы уже искали клиентов, но видели ли вы их?
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
Эти библиотеки могут уменьшить усилия.

Также спасибо тем, кто работает над этим скрытыми эльфами. Я подозреваю @Dieterbe , но не знаю.

Оповещения теперь в основном используются @bergquist (и @mattttt ). Я переключился на нашу предстоящую графитовую серверную часть https://github.com/raintank/metrictank

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

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

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

@superbool извините, не могу прочитать это, и перевод Google не очень помог

Слияние с мастером БУДЕТ к 19 августа, обещаю :)

@torkelo, хе-хе, в следующий раз сделаю ставку. Есть ли новое свидание?

Можем ли мы ожидать, что оповещение для OpenTSDB будет запланировано?
(скромное) основание для поощрения разработчиков.

2016-08-22 10:05 GMT + 02: 00 A. Binzxxxxxx [email protected] :

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

@superbool https://github.com/superbool извините, не могу прочитать это и
перевод Google не очень помог

Слияние с мастером БУДЕТ к 19 августа, обещаю :)

@torkelo https://github.com/torkelo хе-хе, в следующий раз сделаю ставку. Есть ли
новая дата?

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

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

@ DEvil0000 Планировалось слияние в прошлую пятницу, но из-за некоторых незапланированных событий (https://twitter.com/torkelo/status/766514688997732352) нам пришлось немного отложить это :) У нас еще есть кое-какие незначительные дела.

@torkelo Поздравляю!
@bergquist @torkelo Мне нужно оповещение с помощью elastic до октября ( мне подойдет альфа). Могу я помочь вам реализовать это? Вам просто нужно предоставить мне некоторую информацию, чтобы иметь отправную точку;)

Ветвь предупреждений теперь объединена в главную. : Raved_hands:

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

Так что же дальше?

• Альфа-релиз (документы и блог)
• Соберите обратную связь от сообщества.
• Продолжайте работать над остальными проблемами для оповещения
• Выпуск Grafana 4.0 с предупреждением.

Попробовать?

• Вы должны включить оповещение в конфиге .
• Теперь вы можете найти оповещения в боковом меню.
• Вы можете добавить предупреждение, перейдя на панель графиков и выбрав вкладку предупреждений.
• Используйте кнопку _Test alert_, чтобы проверить ваше предупреждение.
• Чтобы сохранить оповещение, вам просто нужно сохранить панель управления.
• Настройте уведомление о / предупреждений / уведомлений, чтобы получать уведомления о предупреждениях об увольнении.
• Добавьте уведомителя к предупреждению на вкладке предупреждений.

Текущие ограничения

• Пока мы поддерживаем только графит.
• В этом выпуске только панель графиков поддерживает оповещения.

Примеры дашбордов

Вы можете найти примеры панелей мониторинга в папке с примерами.
Примеры дашбордов основаны на данных нашего модуля записи поддельных графитовых данных. Вы можете запустить graphite и fake-data-writer из наших файлов docker-compose.

cd docker/
./create_docker_compose.sh graphite
docker-compose up

Это следует рассматривать только как приблизительное руководство, и в следующие недели мы добавим дополнительную документацию по оповещениям.

Удачного оповещения! : cocktail:: tada:

@bergquist Поздравляю.

Есть ли вопрос, за которым мы можем следить в будущем этой функции?

@ Workshop2 https://github.com/grafana/grafana/issues/5858

В Условиях оповещения есть только «И», а не «ИЛИ», чтобы добавить «выше» или «ниже» на одной панели, или есть другой способ поддержать это?

Я думаю, что есть опция «вне диапазона» / «находится в диапазоне». Но я также хотел бы видеть «или».

Всем здравствуйте! Большое спасибо за ваш вклад в эту полезную функцию.

Это действительно интересно для меня, но во многих случаях мне понадобится «ИЛИ» в условиях оповещения, потому что нет возможности создать более одного оповещения в графе.

Я думаю, что без этого «ИЛИ» я не смогу создавать оповещения для таких графиков:

Любая идея? Планируете ли вы добавить опцию «ИЛИ»?

BR

@jmgonzalezp да, мы надеемся также поддержать ИЛИ (пока не уверены в смешивании И и ИЛИ)

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

Вот проблема с нашими текущими мыслями, и мы будем очень признательны за ваш отзыв.
https://github.com/grafana/grafana/issues/6007

Всем привет! Спасибо за такую ​​замечательную функцию в графане!

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

@torkelo У меня тот же вопрос, что и у @akurniawan. Давайте рассмотрим эту настройку: 1 балансировщик нагрузки, 3 экземпляра Grafana за балансировщиком нагрузки, 1 база данных Mysql, которую разделяют все 3 экземпляра. Как серверы Grafana будут обрабатывать предупреждения при таком типе настройки? Должны ли мы тогда включать оповещения только для 1 экземпляра или Grafana отслеживает оповещения, чтобы несколько узлов не проверяли и не отправляли одни и те же оповещения?

@utkarshcmu @akurniawan оповещение в grafana еще не поддерживает HA. Мы планируем добавить поддержку предупреждений о разделении между серверами в будущем.

@bergquist Спасибо за ответ. :)

@bergquist Любое ETA, когда для этого будет добавлена ​​поддержка InfluxDB?

@thisisjaid, судя по этому https://github.com/grafana/grafana/milestone/40, он должен быть здесь 10-го числа.

@Dieterbe Есть ли ETA для поддержки OpenTSDB?

@sofixa Спасибо, надо было самому посмотреть дорожную карту, если не RTFMing. Тем не менее, оценил.

@Dieterbe Есть ли ETA для поддержки OpenTSDB?

Я больше не работаю над оповещением. возможно, ответят @torkelo или @bergquist .

@torkelo @bergquist

Любое ETA для поддержки оповещений для OpenTSDB

@LoaderMick @ naveen-tirupattur Оповещения OpenTSDB добавлены в Grafana, они должны быть частью следующего выпуска. Кроме того, оповещения для OpenTSDB работают в ночных сборках.

Есть ли ETA для поддержки оповещений для InfxDB и prometheus?

Оповещение @nnsaln для обоих источников данных уже есть в основной ветке.

Кажется, я не могу получить предупреждения, работающие с OpenTSDB с (Grafana v4.0.0-pre1 (commit: 578507a)). Я протестировал систему электронной почты (работает), но предупреждения просто не срабатывают, даже если у меня очень низкий порог. Есть ли способ запускать запросы вручную и просматривать данные, которые он извлекает?

Grafana v4.0.0-pre1 (фиксация: 9b28bf2)
ошибка tsdb.HandleRequest () ошибка Influxdb вернул код состояния недопустимый код состояния: 400 неверный запрос

@torkelo
Может ли «уведомление о предупреждении веб-перехватчика» публиковать метрику предупреждения, json или тип формы?

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

Все, попробуйте 4.0 beta; если чего-то не хватает, открывайте новые выпуски.

Ричард

Отправлено с мобильного телефона; извините за краткость.

Я пробовал 4.0 бета, но у меня все еще возникает эта ошибка
ошибка tsdb.HandleRequest () ошибка Influxdb вернул код состояния недопустимый код состояния: 400 неверный запрос

Я не могу сохранить уведомления о предупреждениях - отправить, после того, как я сохранил, строка для отправки снова становится пустой

@nnsaln Здесь вы должны

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

В понедельник, 5 декабря 2016 г., в 2:06, Томас Бартон [email protected]
написал:

@nnsaln https://github.com/nnsaln Вы должны заполнить уведомление
цель там, а не адрес электронной почты. Откройте боковое меню графаны и наведите указатель мыши на
пункт меню «Уведомления», затем нажмите «Параметры меню уведомлений». Там
вы можете настроить цель уведомления, которую вы можете использовать из своих правил предупреждений.

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

-
Дипак

Нет, в настоящее время это не поддерживается. Может быть, в далеком будущем, но

99% дашбордов используют переменные шаблона. Они были разработаны с использованием шаблона
переменные, чтобы избежать проблемы "взрыва приборной панели".

В пн, 5 декабря 2016 г., в 20:20, Торкель Одегаард [email protected]
написал:

Нет, в настоящее время это не поддерживается. Может быть, в далеком будущем, но

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

-
Дипак

Да, но общая панель мониторинга - это не то же самое, что дизайн панели мониторинга для правил предупреждений.

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

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

Am 06.12.2016 11:14 начм. schrieb "Торкель Одегаард" <
[email protected]>:

Да, но общая панель мониторинга - это не то же самое, что панель мониторинга.
дизайн для правил предупреждений.

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

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

+1 Торкель.

Это делает оповещение довольно сложным.

Во вторник, 6 декабря 2016 г., в 14:14, Торкель Одегаард [email protected]
написал:

Да, но общая панель мониторинга - это не то же самое, что панель мониторинга.
дизайн для правил предупреждений.

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

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

-
Дипак

@bergquist относительно этого комментария

оповещение внутри графаны пока не поддерживает HA. Мы планируем добавить поддержку предупреждений о разделах между серверами в будущем.

Есть ли билет для отслеживания прогресса? Любая ветка внести свой вклад?

И большое спасибо за отличную работу!

Керн,

<3 графана.

Я просто пытался поделиться мыслями о предупреждениях с помощью шаблона
приборные панели.

Пт, 9 декабря 2016 г., в 2:53, Дмитрий Жуков [email protected]
написал:

@bergquist https://github.com/bergquist относительно этого комментария

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

Есть ли билет для отслеживания прогресса? Любая ветка внести свой вклад?

И большое спасибо за отличную работу!

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

-
Дипак

@torkelo @Dieterbe Как здорово, что в Grafana наконец-то встроены оповещения! Каков рекомендуемый способ (если есть) для программного создания предупреждений?

@jaimegago для создания предупреждений программно используйте api панели инструментов, предупреждения сохраняются вместе с панелью и панелью управления.

@torkelo Как насчет целей уведомлений (например, создать новое письмо с уведомлением через API)?

edit: Отвечая себе здесь, я нашел конечную точку api / alert-notifications. Я думаю, это просто нужно задокументировать

Конечно, для этого есть http api, просто перейдите на страницу уведомлений, добавьте уведомление и проверьте, что http api вызывает grafana.

@torkelo , есть ли какой-нибудь api, который можно использовать для создания предупреждений (не для создания уведомлений о предупреждениях) программно

@CCWeiZ Alerts - это часть панели инструментов json. Таким образом, вы можете создать только информационную панель, содержащую предупреждения, а не только предупреждения.

Вы можете узнать больше об api приборной панели на http://docs.grafana.org/http_api/dashboard/

доступно ли это: я хочу настроить предупреждение, если значение по сравнению с 3 днями назад не увеличивается. (говорит запросы, если теперь значение - 3 дня назад запросы <100, то мы говорим, что запросов мало.). Как это сделать?