не удаётся создать шаблон tarpper

[Kos]

только есть один момент, название ключа формируется из имени пользовательского параметра + сам макрос. Получается, элементы есть а значений нет

t1.discovery: t1.discovery.[t1.WRK_workstation.adapter_15.cpu_percent]

Не понял Ваши мысль. Разверните её, пожалуйста, чуть подробнее.

[Elis]

С самого начало, основная идея заключалась, просто автоматически создать метрики (items). Поэтому было применено LLD обнаружение.
Zabbix агент дергает скрипт, который в виде JSON выдаёт ключи

{"data": [
{"{#KEY}": ".WRK_workstation.Server_test.cpu_percent", "{#VALUE}": 0.0},
{"{#KEY}": ".WRK_workstation.Server_test.cpu_percent_total", "{#VALUE}": 0.0}
]}

Прототип элементов данных с типом zabbix траппер, который автоматически формирует все ключи (items).



Обнаружение срабатывает без проблем, но сами метрики, создаются с квадратными скобками.



Это критично. Потому что на стороне zabbix sebder, передаваемые параметры квадратных скобок не имеют



В итоге получается, что параметры есть, но значения по ним прийти не могут

[Kos]

С самого начало, основная идея заключалась, просто автоматически создать метрики (items). Поэтому было применено LLD обнаружение.
Zabbix агент дергает скрипт, который в виде JSON выдаёт ключи

{"data": [
{"{#KEY}": ".WRK_workstation.Server_test.cpu_percent", "{#VALUE}": 0.0},
{"{#KEY}": ".WRK_workstation.Server_test.cpu_percent_total", "{#VALUE}": 0.0}
]}

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

Только скромно замечу, что в данном вашем примере значение макроса {#VALUE} в процессе LLD не используется.

Это критично. Потому что на стороне zabbix sebder, передаваемые параметры квадратных скобок не имеют
[...]
В итоге получается, что параметры есть, но значения по ним прийти не могут

Я не очень понимаю, как вы собираетесь присылаемый JSON разбивать по отдельным значениям для разных айтемов.

Я уже сказал, что проще, раз уж вы все эти значения генерируете скриптом, форматировать их не в JSON (требующий парсинга на стороне сервера), а в такой формат, который непосредственно понимается утилитой zabbix_sender. Скажем, следующий фрагмент можно просто скормить этой утилите в её stdin:

- t1.WRK_workstation.Server_test[cpu_percent] 7.4
- t1.WRK_workstation.Server_test[cpu_percent_total] 2.5
- t1.WRK_workstation.Server_test[memory_percent] 5.9
- t1.WRK_workstation.Server_test[memory_rss] 100

В случае же пересылки JSON-а Вам нужно каким-то образом настраивать парсинг этого JSON-а на серверной стороне.
Я пока что знаю только один способ: принимать этот JSON как значение отдельного айтема с типом "Text", а нужные айтемы оформлять как зависимые от него (dependent) с правилами парсинга, прописанными для каждого айтема в его правилах препроцессинга (что для айтемов, создаваемых с помощью LLD, довольно трудоёмко). При этом совсем не обязательно, чтобы в исходном JSON-е какие-то строки в точности совпадали с ключами айтемов (посмотрите хоть в примерах препроцессинга для JSON-а, что ли).
Если Вы делаете как-то по-другому - расскажите, с удовольствием поучусь.

[Elis]

Как хотите. Можете и без квадратных скобок

Именно так и хочу, у меня почти получилось, метрики (items) создаются в правильном виде, но только со скобками []. Были попытки через предобработку их "срезать", применить регурярное выражение, всё равно они остаются в ключах

Скажем, следующий фрагмент можно просто скормить этой утилите в её stdin:

может у Вас найдётся пример? Для наглядности

[Kos]

может у Вас найдётся пример? Для наглядности

Попробую. Только он будет для моей задачи. Зато скрипт достаточно короткий, и в нём как раз есть как LLD, так и засылка данных. Это не совсем правильная практика, т.к. между этими двумя этапами должно проходить некоторое время; но в моей ситуации конфигурация меняется достаточно редко, и если после изменения конфигурации вновь созданный айтем получит своё значение не сразу, а лишь со второй попытки - то это приемлемо.

Задача
Есть система Identity Manager (сокращённо - IDM), у которой есть некоторое количество драйверов, за состоянием которых надо следить.
Каждый драйвер имеет своё имя (текстовая строка), а также режим запуска (Disabled/Manual/Auto) и состояние (обычно Running или Stopped, плюс несколько промежуточных типа "Starting" или "Stopping").
Нужно проверять, что для каждого драйвера с режимом запуска "Auto" его состояние - "Running".
Была найдена очень полезная утилита idmutil.sh, которая при запуске с ключом "status" выдаёт в stdout нужные данные в виде TAB-separated строк, примерно так (я свой длинный список из 20 драйверов подсократил до пяти и в дальнейших примерах буду показывать только их):

Housekeeper             Running Auto     idm
Active Directory        Running Auto     idm
eDirectory              Running Auto     idm
AD-Computers-ldap       Stopped Disabled idm
Lotus Notes-Domino      Running Auto     idm
[...]

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

Собственно, вывод этой утилиты мы используем в качестве входных данных; задача сводится к тому, чтобы "скормить" всё это Zabbix-у.

Подход
Мы хотим для каждого драйвера иметь два айтема, в один из которых принимать его состояние, а в другой - режим автозапуска. Пусть ключи для этих айтемов называются idm.driver.state[имяДрайвера] и idm.driver.autostart[имяДрайвера] соответственно. Тогда нужный нам триггер мы сможем описать такой формулой:

{idm:idm.driver.state[имяДрайвера].count(#2,Running,eq,0)}=0 and
{idm:idm.driver.autostart[имяДрайвера].count(#2,Auto,eq,0)}=2

Функцию count(#2,...) мы используем, чтобы избежать ненужных срабатываний при рестарте драйвера либо изменении его режима автозапуска: триггер реагирует только в том случае, если обе последних проверки вернули, что режим "Auto", а состояние - не "Running".

Чтобы не заниматься дурной работой и не писать руками для двадцати драйверов по два айтема и одному триггеру, автоматизируем этот процесс с помощью LLD.
Для этого нам нужно будет сгенерировать JSON, содержащий для каждого драйвера его имя, которое для работы LLD будем загонять как макрос {#IDM_DRIVER}.
Сам этот JSON будем засылать как значение метрики idm.driver.discovery, на которую и завязываем автообнаружение.
По сути, наш JSON будет выглядеть так:

{ "data":[
{"{#IDM_DRIVER}":"Housekeeper"},
{"{#IDM_DRIVER}":"Active Directory"},
{"{#IDM_DRIVER}":"eDirectory"},
{"{#IDM_DRIVER}":"AD-Computers-ldap"},
{"{#IDM_DRIVER}":"Lotus Notes-Domino"}
] }

Решение
Вот текст скрипта, который (с помощью awk) делает нужные преобразования и с помощью утилиты zabbix_sender засылает сначала JSON для автообнаружения, а затем и сами значения:

#!/bin/bash

ZABBIX_HOST=zabbix.my.internal.domain
HOST=$(hostname -s)
STAT=$(/usr/local/bin/idmutil.sh status)

DISCOVERY=$(echo "$STAT" | awk -F"\t" '
BEGIN    {printf "{ \"data\":[ "}
    {   if (FIRST!=0) {
        printf ", "
        } else {
        FIRST=1
        }
        printf "\n{\"{#IDM_DRIVER}\":\"" $1 "\"}"
    }
END    {printf "\n] }"}
' )
/usr/local/bin/zabbix_sender -z $ZABBIX_HOST -s $HOST -k idm.driver.discovery -o "$DISCOVERY" >/dev/null

echo "$STAT" | awk -F"\t" '
    {
    printf "- \"idm.driver.autostart[" $1 "]\" " $3 "\n"
    printf "- \"idm.driver.state[" $1 "]\" " $2 "\n"
    }
' | /usr/local/bin/zabbix_sender -z $ZABBIX_HOST -s $HOST -i - >/dev/null

В начальной части скрипта мы определяем некоторые переменные, а также сохраняем (для последующей двукратной обработки) вывод утилиты idmutil.sh.
Затем вызываем awk для преобразования этого вывода (он приведён в постановке задачи) в JSON (который тоже приведён выше), после чего отсылаем этот JSON как одно значение метрики idm.driver.discovery.
Наконец, в заключительной части скрипта ещё раз проходимся по тем же данным (от утилиты idmutil.sh), преобразуя их в такой список значений (по одному на строку), который скармливается утилите zabbix_sender при её втором вызове:

- "idm.driver.autostart[Housekeeper]" Auto
- "idm.driver.state[Housekeeper]" Running
- "idm.driver.autostart[Active Directory]" Auto
- "idm.driver.state[Active Directory]" Running
- "idm.driver.autostart[eDirectory]" Auto
- "idm.driver.state[eDirectory]" Running
- "idm.driver.autostart[AD-Computers-ldap]" Disabled
- "idm.driver.state[AD-Computers-ldap]" Stopped
- "idm.driver.autostart[Lotus Notes-Domino]" Auto
- "idm.driver.state[Lotus Notes-Domino]" Running

[Kos]

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

[Kos]

(скриншот, не влезший в предыдущее сообщение из-за ограничений на 5 аттачментов):