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

[pavelkq7]

Доброго дня! Поставили задачу сравнивать текущее количество обращений через Nginx со средним за прошедшие 5 недель, но именно в эти же самые дни и это же время. Если текущее значение на 10% отличается, то алертить.
Сделал такой триггер:

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

[Griboed0ff]

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

[Hamardaban]

Для отлова "выбросов" лучше подходит процентиль.
Посмотрите на статейки по использованию функций - может чего пригодиться
https://blog.zabbix.com/zabbix-in-ex...-part-1/25802/
https://blog.zabbix.com/zabbix-in-ex...-part-2/26151/

[pavelkq7]

Придумал ещё такой алгоритм - сделать скрипт, который по API извлекает данные из базы, а потом предобработкой сделать нужные расчёты на java-script.
Готового ключа, который сразу все данные из базы извлечёт я не нашёл((

[Griboed0ff]

Для отлова "выбросов" лучше подходит процентиль.

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

[Griboed0ff]

Выглядит пугающе, но работает.

Судя по формуле дни вы вообще не сравниваете. Можете пояснить чего в формуле ожидаете?

[pavelkq7]

Судя по формуле дни вы вообще не сравниваете. Можете пояснить чего в формуле ожидаете?

Если сегодня понедельник 9:00, то мне нужно взять значение со всех предыдущих понедельников именно за 8-9 час. Затем сосчитать среднее из них и сравнить с текущим в процентах.

[Griboed0ff]

Если сегодня понедельник 9:00, то мне нужно взять значение со всех предыдущих понедельников именно за 8-9 час. Затем сосчитать среднее из них и сравнить с текущим в процентах.

Если речь про часы, то все сходится. Вместо avg кстати можно как раз вставить percentile, получится среднее без пиков, то есть более чистое значение. У меня получается задача один в один такая же. Если найду более изящное решение, то отпишусь. А то у меня получаются такие же громоздкие конструкции. Разница лишь в том, что я делал это через вычисляемые элементы данных, по расписанию. То есть все эти агрегируемые значения вычисляются раз в начале часа, а уже потом сравниваются с последним полученным. Получается меньше агрегириующих вычислений, а если считать это в триггере, то получается, что с каждым полученным последним значением все пересчитывается снова и снова, у меня это раз в минуту.

[Griboed0ff]

Никак не удается прикрутить forecast, если указывать анализируемый интервал как 1 час неделю назад, то получаются неадекватные значения, либо минусовые, либо на несколько сотен больше чем надо. Хотя таких значений не было в этом интервале и близко. И чем старше анализируемый интервал, тем неадекватней значения. Примерно так пытался forecast(//item,1h:now-1w,1h). Да и похоже нужно как-то выпрямить график, например, усреднив значения, иначе эта функция вообще неприменима.

[pavelkq7]

У меня сама метрика текущего значения собирается раз в час. Поэтому у меня нет нагрузки на вычисление в триггере. К тому же я попробовал сделать вычисляемый элемент и сравнить его значение с тем, что получает триггер при вычислении напрямую. Как ни странно, но значения немного разошлись.
Forecast я тоже прикрутил с такими значениями forecast(/s-nginx-1/log.count[/var/log/nginx/access.log,"^.*sqldbadapter.*$"],4w,1h). Но результат меньше вычисляемого на 15-20%.

[Griboed0ff]

Forecast я тоже прикрутил с такими значениями forecast(/s-nginx-1/log.count[/var/log/nginx/access.log,"^.*sqldbadapter.*$"],4w,1h).

А смещение time shift вперед для этого значения удалось настроить? На небольших интервалах работает корректно, но нужно перенести значения вперед. Красная и зеленая это прогнозы.

[pavelkq7]

Ну его в баню, этот прогноз. С таймшифтом ещё хуже разница стала - в 2 раза меньше от среднего.

[teddy]

в моей задаче нужно было выборку по среднему значение в "рабочее время" без учета ночи и выходных. я сделал отдельный item который просто не собирал данные в нерабочее время. через возможность опрашивать в диапазоне времени. вполне коректно работает. понятно что нерабочий день среди недели такое не "споймает" но в среднем по больнице чтоб считал с пнд по пятн. с 9-00 до 18-00 и давало средний показатель - вполне.

[pavelkq7]

У меня вырезать отдельные элементы в разные часы - это уже перебор будет - 24 часа умножить на 30 вариантов данных. И даже если ночные часы убрать, выйдет слишком много.
Оставил пока один forecast для эксперимента, может быть со временем он выровняется. А остальные в лоб буду считать, как на первом посте.

[Griboed0ff]

у меня в график прогноз стал попадать в таком варианте: forecast(//element,3h,30m). А вот на счет смещения не получается, какая у вас формула смещения была?