Есть служба, надо отслеживать состоние и сделать тригер, как граммотней это сделать?

[D.Frolov]

1. Есть Windows, там установлен агент в активном режиме, все работает, все корректно
2. Надо мониторить ОДНУ службу, на состояние RUNNING или нет.
3. Естественно агент использует автообаружение и находит службы и выводит их состояние, использую протип - service.info["{#SERVICE.NAME}",state]
4. Так как это автообнаружение, то под одну службу, изменить не получится...., если менять триггер в прототипе, то под ВСЕ службы, а мне надо только ОДНУ.
5. Конечно в голову приходит мысль, скрипт, UserParam и отдать значение в Zabbix, но мне кажется это должно делать как-то более грамотно.
6. Просто скопировал ключ с автообнаружения, создал шаблон, нужные триггер, хотел применить к узлу, НО получил

Не удалось унаследовать элемент данных с ключом "service.info["ZeroTierOneService",state]" шаблона "0.034 ZeroTier" к узлу сети "0.110 - Dynamic IP - TerminalServer", так как обнаруженный элемент данных с таким же ключом уже существует.

Как можно решить данную задачу - "Отслеживание состояния ОДНОЙ конкретной службы"

[Kos]

А есть пример как это сделать? (скриншот или описание)

В этом отношении в седьмой версии ничего существенно не менялось, можно спокойно пользоваться русским переводом документации по версии 6.0:

• описание формата ключа элемента данных (ссылка)
• низкоуровневое обнаружение (LLD) (ссылка) - здесь обратить внимание на скриншот с примером в разделе "Фильтр правила обнаружения" (где сами регулярные выражения вынесены в пользовательские макросы), а также на раздел "Замещения".

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

[Kos]

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

[D.Frolov]

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

1. Зачем вам автообнаружение, если надо мониторить только одну конекретную службу? - Я применил шаблон, которые был от Zabbix для Windows и там это история есть по умолчанию (можно конечно скопировать шаблон и грохнуть автообнаружение служб...ну пока не хочется)
2. Проблема в том, что предположим я поставлю сообщение в ТГ, когда служба упала, НО такое сообщение я буду получать НА ЛЮБУЮ службу, а я хочу на одну.

[Alex_UUU]

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

[Kos]

2. Проблема в том, что предположим я поставлю сообщение в ТГ, когда служба упала, НО такое сообщение я буду получать НА ЛЮБУЮ службу, а я хочу на одну.

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

[D.Frolov]

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

"Чтобы избавиться от ошибки по дублю, можно в свонм элементе данных изменить ключ, например, добавить пробел в параметрах, либо дописать незначащий новый параметр." - пробел действительно работает, а вот если добавить доп. параметр, то скажет что error "many parametrs"

[D.Frolov]

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

Чтобы автообнаружением сделать спец ЭД или триггер для конкретного значения можно использовать или макросы или (спасибо kos, мне понравилось) "замещения". Я замещением меняю и ЭД и триггеры. Например дискаверинг обнаруживает или ntp или chrony для каждого ролцесса свой набор ЭД и триггеров. Вот замещениями и выставляю нужное.

А есть пример как это сделать? (скриншот или описание)

[Kos]

А есть пример как это сделать? (скриншот или описание)

В этом отношении в седьмой версии ничего существенно не менялось, можно спокойно пользоваться русским переводом документации по версии 6.0:

• описание формата ключа элемента данных (ссылка)
• низкоуровневое обнаружение (LLD) (ссылка) - здесь обратить внимание на скриншот с примером в разделе "Фильтр правила обнаружения" (где сами регулярные выражения вынесены в пользовательские макросы), а также на раздел "Замещения".

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