Grafana: Оповещение: ограничения по времени суток

Созданный на 16 нояб. 2016  ·  83Комментарии  ·  Источник: grafana/grafana

Ограничения по времени суток.

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

1) В качестве аварийного состояния
2) Как фильтр уведомлений

arealerting typfeature-request

Самый полезный комментарий

В качестве обходного пути, используя prometheus в качестве бэкэнда:

  • Добавьте в свою метрику следующий запрос: hour() , который возвращает час дня (0–23). Вы можете сделать его скрытым на графике.
  • Добавьте в оповещение дополнительное условие AND , чтобы оно срабатывало только в том случае, если запрос hour() находится в нужном диапазоне (например, рабочее время).

То же самое можно сделать с day_of_week() .

Все 83 Комментарий

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

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

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

@bblazei ты прав! это замечательная функция, которой нужно уделять приоритетное внимание, и она наверняка будет полезна людям!
@torkelo вы знаете, когда эта функция будет запланирована?

Нет, не Eta прямо сейчас, так как его нет в нашей дорожной карте для следующих двух выпусков (4.3 и 4.4).

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

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

Мы (не очень) терпеливо ждем и этого. В настоящее время мы периодически используем графики curl to Slack.

@торкело торкело. это было некоторое время, я не вижу обновления по этому поводу. мы также ищем что-то вроде того, можем ли мы отключить предупреждения grafana на определенное время. это возможно?

Есть ли у кого-нибудь обновление для этой функции?

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

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

Было бы сложно добавить операцию по модулю для этой цели?

Очень нужна эта функция!

Есть новости по этому поводу? Это незавершенное производство или что-то еще только «рассматривается» прямо сейчас?

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

+1

+1

+1

Почему люди ( @bascarsija & @maizy) голосуют против запросов людей об этом?

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

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

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

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

Любые обновления расписания оповещений в определенное время дня, недели, месяца и года?

В качестве обходного пути, используя prometheus в качестве бэкэнда:

  • Добавьте в свою метрику следующий запрос: hour() , который возвращает час дня (0–23). Вы можете сделать его скрытым на графике.
  • Добавьте в оповещение дополнительное условие AND , чтобы оно срабатывало только в том случае, если запрос hour() находится в нужном диапазоне (например, рабочее время).

То же самое можно сделать с day_of_week() .

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

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

Пример:

```
метрика A: production.application_a.actual_metric = 123 (это моя фактическая метрика)
метрика B : helper.time_helper.hour = от 1 до 24 (поддельные метрики времени, которые каждую минуту отправляются в графит)

   alert requirement :

(показатель A ниже 100 И час находится в пределах диапазона 10 и 20)
ИЛИ
(метрика А ниже 50 И час выходит за пределы диапазона 10 и 20)
```

другими словами:

metric A threshold is 100 between 10AM to 8PM and it is 50 for rest of the time

Мой вопрос :

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

image

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

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

час между 1 и 2 И

+1 был бы очень признателен!

Просто комментарий к грубой работе
Я использую collectd/Influxdb
У меня есть процесс cron, который записывает значение часа в плоский файл ext.
Плагин сбора таблиц читает это как Table_Value - Instance "Hour"
В любом предупреждении, где мне нужно использовать только диапазон, я добавляю метрический час (макс.) на панель инструментов в качестве скрытой метрики, затем в предупреждении использую значение диапазона AND - срабатывает только в том случае, если час находится между X и Y
То же самое работает и по дням недели

Грубо, но эффективно

@torkelo есть предположения, когда это может быть реализовано?

Нет, извините, этого нет в дорожной карте основной команды.

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

У меня есть процесс cron, который записывает значение часа в плоский файл ext.
В любом предупреждении, где мне нужно использовать только диапазон, я добавляю метрический час (макс.) на панель инструментов в качестве скрытой метрики, затем в предупреждении использую значение диапазона AND - срабатывает только в том случае, если час находится между X и Y

Это довольно эффективный обходной путь с тонким, но полезным преимуществом по сравнению с простым игнорированием предупреждений между X–Y: если ситуация не исправлена ​​до Y, я получаю свое первое предупреждение в Y. Если я просто игнорирую предупреждения между X–Y, я не будет предупрежден даже после Y (хотя, я думаю, можно было бы использовать функцию «Отправить напоминания»).

Оказалось, что задание cron не нужно при использовании графита в качестве источника данных:

Я добавил метрику C из timeSlice(isNonNull(identity(1)), '02:30 -9h', '06:00 -9h') и добавил условие оповещения AND max() OF query(C, 1m, now) HAS NO VALUE , чтобы исключить оповещения с 2:30 до 6:00. (Это -9h потому, что смещение моего часового пояса равно +9:00, а timeSlice() отображается в формате UTC.)

РЕДАКТИРОВАТЬ: После нескольких дней попыток этот трюк с timeSlice() , похоже, не работает ... Похоже, он застрял во времени, когда я сохранил панель инструментов и не переходит на каждый день.

Это огромная недостающая функция. Почему этого нет в дорожной карте? Кажется тривиальным для реализации

Большое спасибо @albertvaka за его обходной путь с использованием функции hour() Prometheus.

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

Подробнее о прометее/prometheus#4160

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

Есть ли прогресс по этому запросу?

Не уверен, но я не смог найти ничего нового, связанного с этим в Grafana 6.1.3.

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

+1, хотелось бы, чтобы это было реализовано.

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

+1, пожалуйста, реализуйте это как можно скорее - мне придется портировать все на Thingsboard, если это не будет реализовано в ближайшее время https://thingsboard.io/

@torkelo , не могли бы вы дать нам некоторую информацию об этой проблеме? Есть ли прогресс?

Привет, есть ли кто-нибудь, у кого достаточно знаний, чтобы реализовать это и сделать запрос на включение?

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

Я реализовал несколько запланированных cron функций [SomeCloudProviderOfYourChoice] Lambda, которые использовали Grafana REST API для обновления целых информационных панелей из экспортированных полезных данных JSON с его предупреждениями и пороговыми значениями в зависимости от периодов активности / простоя системы соответственно (наша система активна 8-10 часов в день). вне выходных). Это работает очень хорошо.

Но.

Всякий раз, когда вы работаете с информационными панелями в графическом веб-интерфейсе Grafana, вы должны иметь в виду, что всякий раз, когда вы вносите какие-либо изменения во что-либо, дамп информационных панелей JSON и их фиксация в репозитории «Grafana Scheduler» является ОБЯЗАТЕЛЬНЫМ . Если вы забудете о сбросе полезной нагрузки (Южный парк S11E09), ваши изменения будут потеряны при каждом срабатывании планировщика (восстановимое, но болезненное). И вы должны распространить свои изменения как на активные, так и на бездействующие дампы JSON, что в основном означает удвоение усилий (плюс даже больше, если различия не задокументированы соответствующим образом). По сути, это «решение» означает, что вам нужен хорошо документированный, поддерживаемый, видимый и строго соблюдаемый _процесс_, который в долгосрочной перспективе может быть еще более отстойным, чем отсутствие этой функции вообще. Мы так редко меняем наши пороги предупреждений, что кажется, что нам не составит большого труда иметь дело с _процессом_ накладными расходами.

Так или иначе...

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

Оставайтесь с нами, удачи!

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

Самый простой способ с запросами T-SQL — обмануть GRAFANA (обходной путь):

SELECT timestamp AS time,
        CASE 
            WHEN DATEPART(HOUR, SYSDATETIME()) NOT IN (0,1,2,3,4,5,6) 
            THEN COUNT(document_number)
            ELSE 0 
        END AS Receipts
FROM GRAFANA.dbo.ReceiptsErrorsHistory
WHERE timestamp >= DATEADD(DAY, -7, GETDATE())
AND document_type = 'receipt'
GROUP BY timestamp

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

В случае Elastic search я нашел простой способ решить эту проблему.
Используйте математику даты: https://www.elastic.co/guide/en/elasticsearch/client/net-api/7.x/date-math-expressions.htm.

например, если вам нужны данные с диапазоном (AM 00:00 ~ PM:12:00), то @timestamp :[now/d TO now/d+12h] может вернуть желаемый результат

@sukjoonhong Я не могу заставить это работать. У вас есть скриншот, пожалуйста?

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

В crontab на коробке с графаной я добавил:

1 * * * * root /root/do-alert-thing.sh

И в /root/do-alert-thing.sh:

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Просто замените Somewhere/Sometime своим часовым поясом (совет: запустите timedatectl list-timezones для списка) и добавьте свои учетные данные вместо [email protected] . Согласно документации , эта конечная точка администратора работает только в базовом режиме аутентификации.

Надеюсь, это поможет кому-то там.

@Atem18
2019-10-14-094215_3840x1080_scrot

В моем случае этот запрос сработал.

@sukjoonhong Спасибо, попробую!

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

В crontab на коробке с графаной я добавил:

1 * * * * root /root/do-alert-thing.sh

И в /root/do-alert-thing.sh:

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Просто замените Somewhere/Sometime своим часовым поясом (совет: запустите timedatectl list-timezones для списка) и добавьте свои учетные данные вместо [email protected] . Согласно документации , эта конечная точка администратора работает только в базовом режиме аутентификации.

Надеюсь, это поможет кому-то там.

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

Я подошел к этому с другой точки зрения, когда вы генерируете метрику включения/выключения prometheus на основе вывода скрипта, например, команды ps, которая проверяет, запущен ли скрипт резервного копирования. Затем на моей панели инструментов у меня есть «Резервное копирование активно» для отображения состояния резервного копирования, а на моей основной панели со всеми моими запросами и предупреждениями я добавляю проверку условия, которая не будет предупреждать, если метрика резервного копирования = 1. Этот подход будет также позволяет добавить отдельное оповещение, которое срабатывает, если резервное копирование выполняется дольше, чем должно, с учетом исторических данных метрик.

У меня есть обходной путь для этого, который использует cron для включения и выключения предупреждений. Это будет работать только в том случае, если вы хотите отключить ВСЕ оповещения на ночь (или если вы можете быть обеспокоены написанием отдельных оповещений).
В crontab на коробке с графаной я добавил:
1 * * * * root /root/do-alert-thing.sh
И в /root/do-alert-thing.sh:

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Просто замените Somewhere/Sometime своим часовым поясом (совет: запустите timedatectl list-timezones для списка) и добавьте свои учетные данные вместо [email protected] . Согласно документации , эта конечная точка администратора работает только в базовом режиме аутентификации.
Надеюсь, это поможет кому-то там.

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

Не уверен, почему вы видите такое поведение; для меня он приостанавливается и остается приостановленным в течение 9 часов, пока я не сниму его с паузы, используя утреннюю строку cron.

У меня есть обходной путь для этого, который использует cron для включения и выключения предупреждений. Это будет работать только в том случае, если вы хотите отключить ВСЕ оповещения на ночь (или если вы можете быть обеспокоены написанием отдельных оповещений).
В crontab на коробке с графаной я добавил:
1 * * * * root /root/do-alert-thing.sh
И в /root/do-alert-thing.sh:

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Просто замените Somewhere/Sometime своим часовым поясом (совет: запустите timedatectl list-timezones для списка) и добавьте свои учетные данные вместо [email protected] . Согласно документации , эта конечная точка администратора работает только в базовом режиме аутентификации.
Надеюсь, это поможет кому-то там.

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

Не уверен, почему вы видите такое поведение; для меня он приостанавливается и остается приостановленным в течение 9 часов, пока я не сниму его с паузы, используя утреннюю строку cron.

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

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

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

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

Это может быть просто статус предупреждения; например, если бы предупреждение было в порядке, оно бы показало:

image

Я предполагаю, что если он был приостановлен на час, он сказал бы «ПАУЗА на 1 час»?

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

Спасибо за разъяснения!

Планируется ли реализовать эту функцию в версиях 6.6.x > через четыре года?

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

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

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

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

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

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

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

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

+1 по запросу функции

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

Было бы здорово иметь возможность настроить различные каналы уведомлений в отношении периодов времени, например:

  • обычный понедельник -> уведомить через Slack
  • 1 января понедельник -> уведомить по СМС

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

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

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

Не существует хорошего способа оповещения об этом без ограничения по времени.

«Оповещать, если нет данных за последние X часов» не будет работать для любого количества X часов. Например, если я предупреждаю об отсутствии данных за последние 24 часа, это работает до тех пор, пока все задания выполняются правильно каждый день. Однако, если я получу ошибку и перезапущу задание в 11 утра, чтобы наверстать упущенное. Затем мое оповещение на следующий день нарушается (поскольку оно не сработает до 11:00). Это мой основной вариант использования ограничения по времени. Единственное осуществимое оповещение состоит в том, чтобы включить логику оценки оповещений с 2:00 до 8:00 и оповещать, если «нет данных за последние 8 часов».

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

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

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

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

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

+100000

👍 +1
Я думаю, что это важная функция для использования Grafana в качестве настоящего механизма оповещения.

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

+1

Было бы неплохо иметь эту функцию на стороне клиента. Прямо сейчас нам нужно получить такие поля, как hourOfDay, dayOfWeek, в Logstash, чтобы они присутствовали в ES для добавления дополнительной метрики в набор метрик и добавить ее в правила оповещения.

Оповещать меня, если средний показатель A, который представляет собой загрузку ЦП, превышает 90 % в течение 1 минуты.
И
если метрика B, которая равна max hourOfDay тех же документов, находится в диапазоне RANGE.

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

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

В crontab на коробке с графаной я добавил:

1 * * * * root /root/do-alert-thing.sh

И в /root/do-alert-thing.sh:

#!/bin/bash

#Enable at 6am local
TZ='Somewhere/Sometime' date +%H | grep '06' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":false}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

#Disable at 9pm local
TZ='Somewhere/Sometime' date +%H | grep '21' && (
  curl http://localhost:3000/api/admin/pause-all-alerts -d '{"paused":true}' -u [email protected]:letmein -H 'Content-Type: application/json'
)

Просто замените Somewhere/Sometime своим часовым поясом (совет: запустите timedatectl list-timezones для списка) и добавьте свои учетные данные вместо [email protected] . Согласно документации , эта конечная точка администратора работает только в базовом режиме аутентификации.

Надеюсь, это поможет кому-то там.

Привет
Можете ли вы сказать мне, как получить URL-адрес отдельных предупреждений?

Привет
Можете ли вы сказать мне, как получить URL-адрес отдельных предупреждений?

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

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

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

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

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

Было бы сложно добавить операцию по модулю для этой цели?

Звучит безумно, но это работает, и в моем случае этого было достаточно. 😅

time() % 86400

Тем не менее, это боль, что нет более удобного решения, которое не является очевидным взломом. 🤦

Звучит безумно, но это работает, и в моем случае этого было достаточно. 😅

time() % 86400

Тем не менее, это боль, что нет более удобного решения, которое не является очевидным взломом. 🤦

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

Звучит безумно, но это работает, и в моем случае этого было достаточно. 😅

time() % 86400

Тем не менее, это боль, что нет более удобного решения, которое не является очевидным взломом. 🤦

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

v6.6.2 🙈

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

Звучит безумно, но это работает, и в моем случае этого было достаточно.

time() % 86400

Тем не менее, это боль, что нет более удобного решения, которое не является очевидным взломом.

Привет @ochrstn :) Не могли бы вы рассказать подробнее, как вы это сделали?

Была ли эта страница полезной?
0 / 5 - 0 рейтинги