Восстановление триггера

[Kos]

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

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

У меня fuzzytime() не работает - ощущение что он берёт метку времени последнего полученного элемента данных, а не того на котором сработал триггер.

- именно так: триггерная функция fuzzytime() обрабатывает только последнее значение. Причём обрабатывает не его метку времени (как nodata()), а само значение.

• Дополнительно к предыдущему пункту: триггерные выражения, которые включают в себя временнЫе функции (nodata(), date(), time(), now(), dayofmonth() или dayofweek()), дополнительно к этому пересчитываются (независимо от того, поступали новые значения или нет) каждые 30 секунд. То есть. если триггерное выражение записать таким образом:

  {Host:item.fuzzytime(3600)}=1 and {Host:item.time()}>0

  (где второе условие - фиктивное, поскольку выполняется всегда), то пересчёт последнего значения будет выполняться и при получении нового значения, и каждые 30 секунд.
• Использование перечисленных временнЫх функций вместе с опцией "Множественные проблемы" официально не поддерживается, т.к. приводит к неожиданным результатам (как правило - генерации проблем каждые полминуты). Я об этом писал ещё хрен знает когда, но, видимо, разработчики не считают эту ситуацию достаточно важной :-(

Да, и ещё маленькое замечание: версия 4.4.х является неподдерживаемой, а через пару дней прекратится и официальная поддержка LTS-ной версии 4.0.

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

[EugeneSemyonov]

Kos, большое спасибо за ответ! Легче пока не стало ввиду:

EugeneSemyonov

• Использование перечисленных временнЫх функций вместе с опцией "Множественные проблемы" официально не поддерживается, т.к. приводит к неожиданным результатам (как правило - генерации проблем каждые полминуты). Я об этом писал ещё хрен знает когда, но, видимо, разработчики не считают эту ситуацию достаточно важной :-(

Да, и ещё маленькое замечание: версия 4.4.х является неподдерживаемой, а через пару дней прекратится и официальная поддержка LTS-ной версии 4.0.

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

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

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

В основном выражении триггера используется несколько функций, в том числе временнЫх: time() - для ограничения времени срабатывания рабочим, dayofweek() - для ограничения срабатывания только в рабочие дни, diff() на основном целочисленном элементе возвращающем количество процессов: proc.num[rphost.exe]

proc.num[rphost.exe] - запрашивается ежеминутно.

Попытка восстанавливать триггер c помощью выражения {proc.num[rphost.exe].fuzzytime(3600)}=0 - закрывать через час, не приводит к успеху - триггер закрывается в течение минуты (иногда даже в секунду срабатывания).
Соответственно, вопрос: как настроить необходимое выражение восстановления?

[Kos]

Начнём с того, что метрика proc.num возвращает количество процессов, а не Unix-time (в отличие от, скажем, system.localtime или vfs.file.time), поэтому применять к ней функцию fuzzytime() бесполезно: при сравнении количества процессов с текущим временем ничего хорошего всё равно не получится.

Если метрика имеет вид proc.num[конкретный_процесс], то для меня неочевидно, зачем для триггера выставлять опцию "multiple problems": скорее всего, для разных процессов будут разные метрики и, соответственно, разные триггеры. "Множественная генерация" может иметь смысл, например, при обработке логов: запись в лог добавилась - триггер сработал (проблема сгенерирована), добавилась ещё одна запись - сгенерировали ещё одно событие "проблема" (хотя триггер и так уже в состоянии "проблема", т.е. не закрыт после предыдущего срабатывания).

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

[EugeneSemyonov]

Начнём с того, что метрика proc.num возвращает количество процессов, а не Unix-time (в отличие от, скажем, system.localtime или vfs.file.time), поэтому применять к ней функцию fuzzytime() бесполезно: при сравнении количества процессов с текущим временем ничего хорошего всё равно не получится.

В документации не очень понятно описана fuzzytime(): "Проверка, на сколько отличается значение элемента данных (как штамп времени) от времени Zabbix сервера. Поддерживаемые типы значений: float, int Возвращает: 1 - если разница между штампом времени значения элемента данных и штампом времени Zabbix сервера меньше или равна сек секунд 0 - в противном случае."
Вот это "(как штамп времени)" указывает на то, что для работы данной функции типами float или int должно быть возвращено значение даты и времени?

Если метрика имеет вид proc.num[конкретный_процесс], то для меня неочевидно, зачем для триггера выставлять опцию "multiple problems": скорее всего, для разных процессов будут разные метрики и, соответственно, разные триггеры. "Множественная генерация" может иметь смысл, например, при обработке логов: запись в лог добавилась - триггер сработал (проблема сгенерирована), добавилась ещё одна запись - сгенерировали ещё одно событие "проблема" (хотя триггер и так уже в состоянии "проблема", т.е. не закрыт после предыдущего срабатывания).

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

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

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

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

Будем думать как отслеживать перезапуск через лог и закрытие c помощью nodata() или изменять статус события напрямую в БД Zabbix.

[Kos]

Да, к сожалению, действительно, в документации порой встречаются корявые формулировки. В случае сомнений можно смотреть английскую версию (это оригинал, с которого потом идут переводы на остальные языки, включая русский): во-первых, она актуальнее переводов, во-вторых - зачастую понятнее, что имелось в виду.
В данном случае: fuzzytime() ожидает, что значением является число, содержащее timestamp в формате Unixtime, т.е. число секунд, прошедшее с "начала эры" - 1 января 1970 года по Гринвичу (тот самый "штамп времени" в русском переводе). И это значение сравнивается с текущим временем на сервере, выраженным в тех же единицах (на самом деле немного сложнее).

Если у вас такой хитрый триггер, что он должен оставаться открытым даже когда реально ситуация нормализовалась (количество процессов скакнуло, а затем пришло в норму), то я, честно говоря, даже не знаю, как тут быть. Разве что пытаться как-то извращаться с тегами и корреляциями, но я не готов предложить готового решения. У нас в подобной ситуации применяется интеграция с системой Jira: при возникновении проблемы в Zabbix-е генерируется тикет в джире (либо обновляется существующий, если есть открытый), при закрытии проблемы в Zabbix-е - тикет в Джире обновляется со сменой статуса, но остаётся открытым (закрывается вручную после разбирательств).

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

[EugeneSemyonov]

Да, к сожалению, действительно, в документации порой встречаются корявые формулировки. В случае сомнений можно смотреть английскую версию (это оригинал, с которого потом идут переводы на остальные языки, включая русский): во-первых, она актуальнее переводов, во-вторых - зачастую понятнее, что имелось в виду.
В данном случае: fuzzytime() ожидает, что значением является число, содержащее timestamp в формате Unixtime, т.е. число секунд, прошедшее с "начала эры" - 1 января 1970 года по Гринвичу (тот самый "штамп времени" в русском переводе). И это значение сравнивается с текущим временем на сервере, выраженным в тех же единицах (на самом деле немного сложнее).
...

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

Большое спасибо за пояснение чего ждёт fuzzytime().

К сожалению, согласно документации: "События создаются Zabbix сервером и их нельзя менять через API.", аналогично "Проблемы создаются Zabbix сервером и их нельзя менять через API."

[Kos]

К сожалению, согласно документации: "События создаются Zabbix сервером и их нельзя менять через API.", аналогично "Проблемы создаются Zabbix сервером и их нельзя менять через API."

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

[EugeneSemyonov]

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

Вот как! Спасибо! Я когда увидел только 2 метода: get (получить) и acknowledge (подтвердить), то поверил надписи что события менять нельзя, кроме как подтверждать и даже не посмотрел что можно делать одновременно с подтверждением.

Это будет лучше чем лезть в БД.

[EugeneSemyonov]

Доброго дня, всем!

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

[Kos]

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

Главное - чья метка времени интересует. Например, просто текущее время в нужном формате возвращает system.localtime (она же - system.localtime[utc]), а время последней модификации файла (в том же формате) вернёт vfs.file.time[/имя/файла].

[EugeneSemyonov]

Главное - чья метка времени интересует. Например, просто текущее время в нужном формате возвращает system.localtime (она же - system.localtime[utc]), а время последней модификации файла (в том же формате) вернёт vfs.file.time[/имя/файла].

Добрый день, KOS. Я про system.localtime нашёл в документации, но для триггера сравнивать одну и ту же дату бесполезно. Нужно придумать как зафиксировать метку на момент срабатывания триггера.

[Kos]

Вы спрашивали про элемент данных, в который можно было бы загонять отметку времени. Я и переспросил, чья отметка времени интересует.
Теоретически, можно настроить на срабатывание триггера дополнительное действие (Action), которое будет засылать в соответствующий элемент данных текущее время (хотя бы запуская скрипт на сервере, который будет возвращать результат команды "date '+%s'"). На практике же это выльется в то, что вам нужно будет на каждый триггер делать ещё дополнительный элемент данных для этого таймстэмпа, и как-то регулировать в Action-е, в какой именно элемент данных этот текущий таймстэмп засылать (либо придётся делать ещё и по Action-у на каждый триггер).

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

[Kos]

Кстати, на тему использования API для закрытия проблем: в разделе блогов появилась статья как раз об этом. Это не решит вашу задачу?

[EugeneSemyonov]

Кстати, на тему использования API для закрытия проблем: в разделе блогов появилась статья как раз об этом. Это не решит вашу задачу?

Kos, большое спасибо! Решение из статьи работает. Нам помогло. Поправили только url, который сохраняется в глобальных макросах, на актуальный адрес публикации веб-интерфейса zabbix-сервера.