Использование результатов обнаружения разным способом

[bercut-vermut]

Всем добрый день
Направьте в нужную сторону, уже голову сломал.
Итак, получаем через vfs.dev.discovery список блочных устройств:
zabbix_agentd -t vfs.dev.discovery
vfs.dev.discovery [s|[{"{#DEVNAME}":"dm-1","{#DEVTYPE}":"disk"},{"{#DEVNAME}":"dm-0","{#DEVTYPE}":"disk"},{"{#DEVNAME}":"md0","{# DEV TYPE}":"disk"},{"{#DEVNAME}":"md1","{#DEVTYPE}":"d isk"},{"{#DEVNAME}":"sdb1","{#DEVTYPE}":"partitio n "},{"{#DEVNAME}":"sda1","{#DEVTYPE}":"partitio n"}, {"{#DEVNAME}":"sdb","{#DEVTYPE}":"disk"},{"{#DE VNA ME}":"sda","{#DEVTYPE}":"disk"},{"{#DEVNAME}":"sd d 1","{#DEVTYPE}":"partition"},{"{#DEVNAME}":"sdc 1", "{#DEVTYPE}":"partition"},{"{#DEVNAME}":"sdc", "{#D EVTYPE}":"disk"},{"{#DEVNAME}":"sdd","{#DEVTYPE}": "disk"}]]

При этом хочется использовать sd.$ и ^md* разными способами (у sda/b/c.. смарт, а у md0/1.. состояние массива). Добавить второе правило с еще одним фильтром {#DEVNAME} пишет нельзя. Как результат разделить что-то типа {#DEVNAME_SD} и {#DEVNAME_MD} или есть другой "правильный путь" ?

[Kos]

При этом хочется использовать sd.$ и ^md* разными способами (у sda/b/c.. смарт, а у md0/1.. состояние массива). Добавить второе правило с еще одним фильтром {#DEVNAME} пишет нельзя. Как результат разделить что-то типа {#DEVNAME_SD} и {#DEVNAME_MD} или есть другой "правильный путь" ?

1) Нельзя добавить второе правило не из-за того, что у них совпадает фильтр, а из-за того, что у них совпадают ключи (одинаковый key, в данном случае - vfs.dev.discovery). Но это можно обойти; самый простой способ - используя фактически тот же ключ, но чтобы он формально отличался: как правило, добавляя в параметры ключа лишние пробелы либо заключая какие-то из параметров в необязательные кавычки. Однако, в данном случае этот способ не работает (параметров вообще нет, на ключ "vfs.dev.discovery[]" агент Zabbix будет ругаться); но и это можно обойти с помощью директивы "Alias=" в конфиге Zabbix-агента.

2) В любом случае, более правильный вариант - использовать LLD Overrides. Это очень удобный механизм, доступный, начиная с версии 5.0; в данном случае можно сделать, например, так:

• в правиле LLD описать прототипы как для SMART-параметров (которые нужны для устройств sd*), так и для состояния зеркала (для устройств md*), но в именах этих прототипов использовать какой-то термин, по которому можно опознать тип устройства (например: для устройств "sd*" использовать слово "disk", а для устройств "md*" - "mirror drive");
• при этом в прототипах элементах данных (items prototypes), предназначенных для устройств sd*, галочку "Discover" отмечать, а для устройств md* - не отмечать;
• в правиле LLD указать фильтр, чтобы обрабатывать только устройства с именами, начинающимися на "md" либо "sd", после чего идёт цифра - например:

{#DEVNAME} matches "^(md|sd)\d"

• пойти на соседнюю вкладку "Overrides" и добавить там новое правило:
  • имя: например, "Mirror devices (md*) override";
  • условие (фильтр): {#DEVNAME} matches "^md";
  • две операции, у которых Object = "Item prototype":
    • Condition: contains "disk", действие: Discover: No;
    • Condition: contains "mirror drive", действие: Discover: Yes;

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

[Kos]

При этом хочется использовать sd.$ и ^md* разными способами (у sda/b/c.. смарт, а у md0/1.. состояние массива). Добавить второе правило с еще одним фильтром {#DEVNAME} пишет нельзя. Как результат разделить что-то типа {#DEVNAME_SD} и {#DEVNAME_MD} или есть другой "правильный путь" ?

1) Нельзя добавить второе правило не из-за того, что у них совпадает фильтр, а из-за того, что у них совпадают ключи (одинаковый key, в данном случае - vfs.dev.discovery). Но это можно обойти; самый простой способ - используя фактически тот же ключ, но чтобы он формально отличался: как правило, добавляя в параметры ключа лишние пробелы либо заключая какие-то из параметров в необязательные кавычки. Однако, в данном случае этот способ не работает (параметров вообще нет, на ключ "vfs.dev.discovery[]" агент Zabbix будет ругаться); но и это можно обойти с помощью директивы "Alias=" в конфиге Zabbix-агента.

2) В любом случае, более правильный вариант - использовать LLD Overrides. Это очень удобный механизм, доступный, начиная с версии 5.0; в данном случае можно сделать, например, так:

• в правиле LLD описать прототипы как для SMART-параметров (которые нужны для устройств sd*), так и для состояния зеркала (для устройств md*), но в именах этих прототипов использовать какой-то термин, по которому можно опознать тип устройства (например: для устройств "sd*" использовать слово "disk", а для устройств "md*" - "mirror drive");
• при этом в прототипах элементах данных (items prototypes), предназначенных для устройств sd*, галочку "Discover" отмечать, а для устройств md* - не отмечать;
• в правиле LLD указать фильтр, чтобы обрабатывать только устройства с именами, начинающимися на "md" либо "sd", после чего идёт цифра - например:

{#DEVNAME} matches "^(md|sd)\d"

• пойти на соседнюю вкладку "Overrides" и добавить там новое правило:
  • имя: например, "Mirror devices (md*) override";
  • условие (фильтр): {#DEVNAME} matches "^md";
  • две операции, у которых Object = "Item prototype":
    • Condition: contains "disk", действие: Discover: No;
    • Condition: contains "mirror drive", действие: Discover: Yes;

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

[bercut-vermut]

Ты просто мега крутой чел !
Спасибо за направление, вот что получилось:
md raid discovery: raid Active devices md0
md raid discovery: raid Active devices md1
md raid discovery: raid State degraded md0
md raid discovery: raid State degraded md1
md raid discovery: raid State recovery md0
md raid discovery: raid State recovery md1
md raid discovery: smart HW Current Pending Sector sda
md raid discovery: smart HW Current Pending Sector sdb
md raid discovery: smart HW Current Pending Sector sdc
md raid discovery: smart HW Current Pending Sector sdd
Все правильно разобрал в правилах !