не могу разобраться с низкоуровневым обн

[Gerain]

Добрый день. помогите разобраться с низкоуровневым обнаружением. Прочитал инструкцию с сайта zabbix и еще не сколько мануалов. Преследую цель мониторить raid контроллер из под windows на серверах Hp, имеется скрипт который из вывода hp ssa выбирает информацию о физических дисках и конвертирует в json.
Примерный вывод такой:

{
"Rotational Speed": "7200",
"SATA NCQ Capable": "True",
"Interface Type": "SATA",
"Current Temperature (C)": "31",
"Model": "ATA WDC ",
"Native Block Size": "512",
"Maximum Temperature (C)": "49",
"Serial Number": "WD",
"Size": "",
"Carrier Bootloader Version": "6",
"Box": "1",
"PHY Count": "1",
"Drive Type": "Data Drive",
"Drive Authentication Status": "OK",
"SATA NCQ Enabled": "True",
"Status": "OK",
"PHY Transfer Rate": "6.0Gbps",
"Bay": "4",
"Firmware Revision": "01.01K02",
"Port": "1I",
"Carrier Application Version": "11"
}

Не могу понять как zabbix обнаруживает доступные параметры и какие запросы нужны составлять.

[glebs.ivanovskis]

А как Вы хотите применить здесь низкоуровневое обнаружение? По-моему, логичнее немного преобразовать вывод скрипта и скармливать эти данные серверу zabbix_sender'ом. Или у набор данных, который может получить скрипт изменяется со временем или от девайса к девайсу?

[Gerain]

Количество параметров меняется от одного контролера к другому.

[Gerain]

Примерно так: zabbix сервер делает запрос к агенту > агент запускает скрипт который выдает данные > сервер создает нужные итемы с полученными значениями. Да и в целом хочется понять как использовать lld. Версия сервера 3.0

[Semiadmin]

Lld работает несколько не так. Оно не определяет параметры, оно обнаруживает физические диски (в вашем случае). А дальше к каждому диску автоматически применяется заранее вами определенный набор параметров (т.е. прототипы айтемов).

[sadman]

Иными словами - у вас будет две задачи (сценария), подключаемых через UserParameter, например:
1) Тот, что находит уникальные идентификаторы и возвращает их, как вот в этой теме - JSON'ом. На основе этих идентификаторов из прототипов элементов данных создаются настоящие элементы данных, которые будут дергать второй скрипт -
2) Тот, что принимает на вход уникальный идентификатор и имя метрики, а затем возвращает её значение.

Это классический вариант. Ему нужно много ресурсов, если мониторится много метрик.

Второй вариант - насильно накормить discovery rule Zabbix-а через траппер JSON'ом из п.1 и продолжать насильно впихивать в созданные элементы данных значения тем же траппером. Тут проблема в точках администрирования и прочей гибкости - их будет не одна, как в классическом варианте, а по количеству наблюдаемых серверов.

[Semiadmin]

Вообще говоря, возможны и смешанные варианты - LLD через траппер, мониторинг через UserParameter, или наоборот. Это уж как вам удобнее.

[Gerain]

Спасибо. Попробую сделать как в выше описанных примерах

[Gerain]

Переделал вывод скрипта по образцу из приведенной ссылки:

{
"data":[

{ "{#fsname}":"/", "{#fstype}":"rootfs" },
{ "{#fsname}":"/sys", "{#fstype}":"sysfs" },

]
}

Получилось следующие:

{
"data":[

{ "{#Name}":"SATA NCQ Enabled", "{#Value}":"True"},
{ "{#Name}":"Serial Number", "{#Value}":"WD-"},
{ "{#Name}":"Size", "{#Value}":"1"},
{ "{#Name}":"Maximum Temperature (C)", "{#Value}":"49"},
{ "{#Name}":"Drive Authentication Status", "{#Value}":"OK"},
{ "{#Name}":"Box", "{#Value}":"1"},
{ "{#Name}":"Rotational Speed", "{#Value}":"11"},
{ "{#Name}":"Carrier Application Version", "{#Value}":"11"},
{ "{#Name}":"Drive Type", "{#Value}":"Data Drive"},
{ "{#Name}":"Port", "{#Value}":"1I"},
{ "{#Name}":"Model", "{#Value}":"ATA WDC "},
{ "{#Name}":"Firmware Revision", "{#Value}":"01.01K02"},
{ "{#Name}":"Bay", "{#Value}":"4"},
{ "{#Name}":"Status", "{#Value}":"OK"},
{ "{#Name}":"PHY Transfer Rate", "{#Value}":"6.0Gbps"},
{ "{#Name}":"Interface Type", "{#Value}":"SATA"},
{ "{#Name}":"Current Temperature (C)", "{#Value}":"31"},
{ "{#Name}":"Native Block Size", "{#Value}":"512"},
{ "{#Name}":"PHY Count", "{#Value}":"1"},
{ "{#Name}":"Carrier Bootloader Version", "{#Value}":"6"},
{ "{#Name}":"SATA NCQ Capable", "{#Value}":"True"},


]
}

Создал правило обнаружения c ключом Test, и два прототипа элементов данных:
Name param(Тип: zabbix agent ; Key: Test[{#Name}] ; Тип информации: текст) и Value param(Тип: zabbix agent ; Key: Test[{#Value}] ; Тип информации: текст)

Элементы данных не создаются, в логах ошибок нет. Выше приведенный листинг ответ zabbix_get на запрос Test. Должен ли скрипт понимать запросы указанных параметров {#Name} и {#Value} или ошибка в чем то другом?

[glebs.ivanovskis]

Должен ли скрипт понимать запросы указанных параметров {#name} и {#value} или ошибка в чем то другом?

Имена макросов должны быть большими буквами.

[Kos]

...и запятой после последнего объекта (в списке элементов массива) быть не должно.

[Semiadmin]

Прототип айтема Value param вам не нужен, value -это не айтем, это значение айтема Name param. И, кстати, надо думать, как вам привязать это lld к конкретному диску, он ведь у вас не один на хосте? Вы ведь это для физических дисков пишете, а не для рэйд-контроллера.

[Gerain]

Спасибо за указания на ошибки. После их исправления все заработало.
Хотел сделать по следующей схеме:
1. Определяем адреса дисков
2. Для каждого диска запрашиваем доступные параметры
3. Опрашиваем по одному диски, задавая в качестве запроса адрес диска и нужный параметр

Для этого создал правило обнаружения которое получает массив вида:

{
"data":[
{"{#drive}":"logical drive","{#address}":"1"},
....
{"{#drive}":"physicaldrive","{#address}":"1i:1: 4"}
]}

В правиле обнаружения создал Элемент с именем "{#drive} {#address}" и ключом {#address} который на запрос получает ответ вида:

{
"data":[
{"{#param}":"unique identifier"},
....
{"{#param}":"full stripe size"}
]}

А дальше я хотел создать второй элемент с именем {#param} и ключом "{#address} {#param}" который получал не посредственное значение и привязывался к "{#drive} {#address}". Скрипты все отдают, как нужно. Но видимо похоже задумка не получилась, пока не знаю как сделать

[Gerain]

Имена макросов большими буквами, что-то в нижний регистр переводится

[sadman]

В правиле обнаружения создал Элемент с именем "{#drive} {#address}" и ключом {#address} который на запрос получает ответ вида:

А дальше я хотел создать второй элемент с именем {#param} и ключом "{#address} {#param}" который получал не посредственное значение и привязывался к "{#drive} {#address}". Скрипты все отдают, как нужно. Но видимо похоже задумка не получилась, пока не знаю как сделать

Ничего не понял. В правиле создали правило? Зачем второй json нужен? Скрипт, читающий метрики, должен принимать на входе уникальный идентификатор, имя метрики и отдавать одно значение - число или строку.

Покажите скриншоты правила и элемента данных.

Например:

Name: "{#drive} {#address} ops" 
Key:  raid.metric[{#drive},{#address}, ops]

Userparameter=raid.metric[*], raidRipper.ps1 -drive "$1" -address "$2" -metric "$3"  [I] ===> raidRipper.ps1 -drive "physicaldrive" -address "1i:1:4" -metric "ops"[/I]

raidRipper.ps1 должен вернуть число OPS-ов.