Lld, несколько полей в одном скрипте или как л

[iltmpz]

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

Я придумал сделать perl-скрипт, который выдает нужные мне данные в json-формате, поскольку заббикс вроде бы должен их в этом формате поддерживать. Позже как настрою заббикс - допишу реальный скрипт, а пока тестовый перл-скрипт это заглушка, которая выдает нужные мне данные. Вот он:

print '
{
    "data": [
        {
            "{#DIRNAME}": "e:/dir_1",
            "{#DIRTIME}": "501"
        },
        {
            "{#DIRNAME}": "e:/dir_2",
            "{#DIRTIME}": "502"
        },
        {
            "{#DIRNAME}": "e:/dir_3",
            "{#DIRTIME}": "503"
        },
        {
            "{#DIRNAME}": "e:/dir_4",
            "{#DIRTIME}": "504"
        },
        {
            "{#DIRNAME}": "e:/dir_5",
            "{#DIRTIME}": "505"
        }
    ]
}  
';

DIRNAME - имена папок, которые будут создаваться, надо чтобы скрипт добавлял их к мониторингу по мере необходимости.
DIRTIME - число секунд, прошедшее с момента последнего изменения файлов в этой папке. Надо чтобы триггер срабатывал, например если это число превысило 3600.

Сначала я добавляю на клиенте в zabbix_agentd.conf:
UserParameter=last_act,C:\scripts\perl.exe C:\scripts\dir_mon.pl
Далее, я создаю шаблон dir_monitor и правило обнаружения.
Прототип элементов данных выглядит так:
Имя: {#DIRNAME} последнее обновление {#DIRTIME}
Тип: zabbix agent (активный)
Ключ: (вот тут не понял, какой мне нужно прописато ключ), прописал туда last_act.[{#DIRTIME}].
Вообще-то по моим представлениям ключ у меня вроде {#DIRTIME}, поскольку именно он у меня содержит нужное поле, но заббикс ругается на синтаксис.
Тип данных какой выбрать? Строка, число, разницы нет...

Далее, открываю узлы сети, свой узел, и там вижу свои данные: 5 строк:
dir_monitor: e:/dir1 последнее обновление 501
...
Т.е. данные в общем-то видны, скрипт выполняется, но вот если открыть мониторинг - обзор, то 5 элементов данных "последнее обновление" есть, а вот значений у них нет. Соответственно, и триггер не могу назначить.

Как тут решить задачу? Я смотрел примеры из других шаблонов - там в качестве ключа выступают всякие "vfs.fs.size[{#FSNAME},free]", net.if.in[{#IFNAME}] и т.п, т.е. функции от передаваемого параметра, а мне надо именно сам параметр {#DIRTIME} передавать. Заббикс выдает ошибку
"Ошибочный ключ "{#DIRTIME}" для прототипа элементов данных"
У меня zabbix 3.0.

[Semiadmin]

Я смотрел примеры из других шаблонов - там в качестве ключа выступают всякие "vfs.fs.size[{#FSNAME},free]", net.if.in[{#IFNAME}] и т.п, т.е. функции от передаваемого параметра, а мне надо именно сам параметр {#DIRTIME} передавать.

А зачем? Уберите вообще из json этот #DIRTIME, оставьте только #DIRNAME.
И создайте прототип айтема с ключем вроде DIRTIME[{#DIRNAME}].
Потом напишите скрипт, который будет получать для айтема время изменения соответствующей папки.

[sadman]

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

Полагаю, что вы ожидаете, что в элементы данных, созданные на основе LLD будут попадать значения из {#DIRTIME}?

Это ошибочная гипотеза. Элементы данных заполняются на основании собственных запросов, а не общего (через LLD rule).

Таким образом ваш скрипт должен уметь:
1) выдавать список идентификаторов контролируемых объектов;
2) по заданному идентификатору объекта возвращать значение метрики.

Т.е.
1) last_act.pl -a discovery выдает JSON с массивом объектов {#DIRNAME};
2) last_act.pl -a get -i "e:/dir_1" выдает 501.
Прототип должен обеспечить создание такого ключа, при котором в UserParameter передается идентификатор, в последствии передающийся скрипту.

Помозгуйте еще, поэкспериментируйте.

[Kos]

К предыдущим замечаниям добавлю, что более эффективно было бы не дёргать скрипт по разу для каждого отдельного элемента данных, а пересылать весь массив значений с помощью утилиты zabbix_sender.
Т.е. нужны либо два скрипта, либо один, который в зависимости от переданных параметров будет вести себя по-разному: в одном случае - отдавать JSON со списком объектов (на основе чего будет отрабатывать LLD и создаваться нужные элементы данных с типом "Zabbix trapper" и триггеры), в другом случае - отсылать конкретные значения для этих элементов данных. Можно формировать сразу весь список и через конвейер передавать его сендеру для отсылки всех значений разом, что-то вроде:

print "..." | /usr/local/bin/zabbix_sender -z $ZABBIX_SERVER -s $HOST -i - >/dev/null

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

[iltmpz]

Большое спасибо, последовал Вашим советам, и все получилось!
Разбил скрипт на два, один выдает список каталогов, другой - значение по каждому их них:
UserParameter=dir_list,C:\scripts\perl.exe C:\scripts\dir_list.pl
UserParameter=dir_last_touch[*],C:\scripts\perl.exe C:\scripts\dir_last_touch.pl $1

Полагаю, что вы ожидаете, что в элементы данных, созданные на основе LLD будут попадать значения из {#DIRTIME}?

Это ошибочная гипотеза. Элементы данных заполняются на основании собственных запросов, а не общего (через LLD rule).

Да, именно этого я и не понимал, думал, что скрипт может цеплять все данные одним запросом из одного json-массива.

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

Вот - именно такую цель первоначально и преследовал: загружать все нужные данные сразу и одним скриптом, вроде бы читал что именно для этого и был включен в заббикс json. Думал, скормлю вывод своего скрипта, а заббикс сам с ним разберется. Оказалось, невнимательно читал, все гораздо сложнее.

Можно формировать сразу весь список и через конвейер передавать его сендеру для отсылки всех значений разом, что-то вроде:
Code:

print "..." | /usr/local/bin/zabbix_sender -z $ZABBIX_SERVER -s $HOST -i - >/dev/null

А print "..." - это именно мой массив в формате из 1-го поста? Или у него какой-то более хитрый формат?

[Kos]

А print "..." - это именно мой массив в формате из 1-го поста? Или у него какой-то более хитрый формат?

Нет, там свой формат, просто текстовый файл по строчке на одно значение, в каждой строке - три поля через пробелы: <имяузласети> <ключ> <значение>. Если <имяузласети> задаётся в команде zabbix_sender (как в моём примере - параметром "-s"), то в строке вместо него можно указывать минус. При желании, можно ещё сопровождать каждое значение своим таймстэмпом (ключик "-T"), тогда в каждой строке будет 4 поля; но для данной задачи этого не надо.