Мониторинг и настройка триггеров для служб Windows

[a3a]

Доброго времени суток!

Необходим мониторинг и настройка триггеров для служб Windows. Серверов очень много, так что нужен шаблон. Выдёргиваю службы через "Description", предварительно указав в фильтрах {#SERVICE.DESCRIPTION} matches Monitoring.
Т.е. в каждой необходимой мне службе в описание есть слово Monitoring. Необходимо:
1. Сработал триггер на State, чтобы если служба не в состоянии Running (значение 0), то сработал триггер и в названии было состояние.
2. Сработал триггер так, чтобы при условии, что в "Описании службы" не будет слова Monitoring сработал триггер и через час триггер ушёл (также нужно, чтобы ушли триггеры из 1 пункта, если такие будут)
3. Сработал триггер, если изменится Startup на Disabled и через час триггер ушёл (также нужно, чтобы ушли триггеры из 1 пункта, если такие будут)
4. Сработал триггер, если службу удалили и через час триггер ушёл (также нужно, чтобы ушли триггеры из 1 пункта, если такие будут)

Какие item, trigger нужно создать? Может что то необходимо добавить в фильтры. Подскажите пожалуйста.

P.S. Мониторю службы через ключ service.info["{#SERVICE.NAME}",state]. Версия заббикс и агента 4.4.5

[Kos]

Problem:{service.info["{#SERVICE.NAME}",state].last()}<>0
Recovery: {service.info["{#SERVICE.NAME}",startup].last()}=3

Так работать и не будет.
Условие в Recovery (если оно есть) проверяется только как дополнительное условие после того как перестаёт выполняться условие в Problem.
В вашем случае формула в Problem содержит проверку только одного параметра (state), а вы ожидаете, что триггер закроется, когда пройдёт сравнение другого параметра (startup).
Решение уже подсказал Alex_UUU : добавить проверку метрики startup прямо в условие срабатывания триггера, убрав условие восстановления вообще (иначе у вас триггеры на службы, которые были временно остановлены, а потом снова запущены, не закроются до тех пор, пока Zabbix не обнаружит, что в свойствах этих служб поменялся их startup type).

[Semiadmin]

Собственно, если посмотреть возможные параметры ключа service.info, то там есть все необходимое - state (default), startup, description.
Единственная сложность - триггеры, которые должны сами гаснуть через час и, очевидно, больше не загораться, пока проблема не решится и не возникнет снова.
Тут нужно основное условие триггера "сначала было хорошо, а теперь стало плохо" и условие восстановления "сейчас хорошо или плохо уже целый час".
На примере 4:
Problem: {service.info["{#SERVICE.NAME}",state].last()} = 255 and {service.info["{#SERVICE.NAME}",state].prev()} <> 255
Recovery: {service.info["{#SERVICE.NAME}",state].last()} <> 255 or {service.info["{#SERVICE.NAME}",state].min(1h)} = 255

[a3a]

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

Если есть идеи по лучше, буду рад.

[a3a]

Попробовал настроить по 3 пункту. Создал 2 item-а: service.info["{#SERVICE.NAME}",state] и service.info["{#SERVICE.NAME}",startup]
Problem:{service.info["{#SERVICE.NAME}",state].last()}<>0
Recovery: {service.info["{#SERVICE.NAME}",startup].last()}=3
Последовательность действий: стопаю службу -> жду пока вылезет триггер {#SERVICE.NAME} is down -> перевожу Startup на Disable, но триггер не уходит.
Также пробовал <>2 поставить в Reсovery. Что не так настроено?

[Alex_UUU]

Покажи, какие значения получает элемент данных. Вернее оба элемента.

[a3a]

State: В состоянии Running = 0, Stopped = 6
Startup: В состоянии Manual = 2, Disabled = 3

[Alex_UUU]

Прямо с временами, в динамике.А не то, какие принимают в теории.

[a3a]

service.info["{#SERVICE.NAME}",state]

11/02/2021 05:57:30 PM	Stopped (6)
11/02/2021 05:56:30 PM	Stopped (6)
11/02/2021 05:55:30 PM	Stopped (6)
11/02/2021 05:54:30 PM	Stopped (6)
11/02/2021 05:53:30 PM	Running (0)
11/02/2021 05:52:30 PM	Running (0)

service.info["{#SERVICE.NAME}",startup]

11/02/2021 05:58:32 PM	disabled (3)
11/02/2021 05:57:32 PM	disabled (3)
11/02/2021 05:56:32 PM	disabled (3)
11/02/2021 05:55:32 PM	disabled (3)
11/02/2021 05:54:32 PM	manual (2)
11/02/2021 05:53:32 PM	manual (2)
11/02/2021 05:52:32 PM	manual (2)

Триггер сработал в 05:54:30 и так и висит

[Alex_UUU]

Problem:{service.info["{#SERVICE.NAME}",state].last()}<>0
Recovery: {service.info["{#SERVICE.NAME}",startup].last()}=3

Надеюсь данные - число, а не "Stopped (6)" - т.к. если данные - этот текст, но он всегда не равен 0

Тогда скрин самого триггера нуже...

[a3a]

Stopped (6) - да, число. Он через маппинг подтягивает расшифровку

[Alex_UUU]

Ьлин,так все правильно. У тебя стейт равно 6, триггер всегда срабатывает.
поставь:


{service.info["{#SERVICE.NAME}",state].last()}<>0
and
service.info["{#SERVICE.NAME}",startup].last()}<>3

[Kos]

Problem:{service.info["{#SERVICE.NAME}",state].last()}<>0
Recovery: {service.info["{#SERVICE.NAME}",startup].last()}=3

Так работать и не будет.
Условие в Recovery (если оно есть) проверяется только как дополнительное условие после того как перестаёт выполняться условие в Problem.
В вашем случае формула в Problem содержит проверку только одного параметра (state), а вы ожидаете, что триггер закроется, когда пройдёт сравнение другого параметра (startup).
Решение уже подсказал Alex_UUU : добавить проверку метрики startup прямо в условие срабатывания триггера, убрав условие восстановления вообще (иначе у вас триггеры на службы, которые были временно остановлены, а потом снова запущены, не закроются до тех пор, пока Zabbix не обнаружит, что в свойствах этих служб поменялся их startup type).

[a3a]

Спасибо, теперь работает