Продолжается моя эпопея по сбору данных с "умных" панелей розеток для серверных шкафов.
Здесь мне подсказали что можно использовать имя клиета как тег и потом производить суммирование значений kWh на основе этого тега.
https://www.zabbix.com/forum/in-russian/486950-%D1%81%D0%B1%D0%BE%D1%80-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D1%81-%D1%83%D0%BC%D0%BD%D1%8B%D1%85-%D0%BF%D0%B0%D0%BD%D0%B5%D0%BB%D0%B5%D0%B9-%D1%80%D0%BE%D0%B7%D0%B5%D1%82%D0%BE%D0%BA-%D0%B4%D0%BB%D1%8F-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BD%D1%8B%D 1%85-%D1%88%D0%BA%D0%B0%D1%84%D0%BE%D0%B2-vertiv-geist-rack-pdus
Теперь я дошёл до менее "умных" панелей розеток от Rittal.
Идея та же: использовать имя клиета как тег и потом производить суммирование значений kWh на основе этого тега, так как оборудование одного клиета может находиться в разных серверных шкафах, а одни шкафы оборудованы Vertiv Geist Rack PDUs, другие - Rittal PDUs.
Rittal PDUs не позволяют получить данные для каждой розетки и не позволяют пометить каждую розетку, поэтому применяются в тех шкафах, которые полностью отданы одному клиенту. В шкафу стоят обычно два Rittal PDUs и работают как Master и Slave. То есть эта "пара" имеет один IP адрес. Но есть возможность подключить несколько Slave-PDUs.
Каждому устройству в этой паре (Master и Slave) можно присвоить имя. Я прописал им имя клиента "Test_Customer_1" чтобы потом использовать это имя как тег.
То есть что имеем:
snmpwalk -v 2c -c public 10.34.150.103:161 1.3.6.1.4.1.2606 | grep Test_Customer_1
SNMPv2-SMI::enterprises.2606.7.4.2.2.1.10.2.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.2.1.10.4.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.3.1.4.1.2.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.3.1.4.1.4.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.6.1.4.2.2.34561271 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.6.1.4.4.2.34561285 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.3.2.1.3.2.1 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.3.2.1.3.4.1 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.3.2.1.16.2.1 = STRING: "Device 2 (PDU-MET-Master) @1.02, Test_Customer_1: OK (1.87 A)"
SNMPv2-SMI::enterprises.2606.7.4.3.2.1.16.4.1 = STRING: "Device 4 (PDU-MET-Slave 1) @1.04, Test_Customer_1: OK (0.30 A)"
Я создал LLD для создания Item-ов по сбору данных на основе следующей последовательности (данные собственно собираются):
SNMPv2-SMI::enterprises.2606.7.4.1.2.1.3.1 = STRING: "PDU-Controller-Master"
SNMPv2-SMI::enterprises.2606.7.4.1.2.1.3.2 = STRING: "PDU-MET-Master"
SNMPv2-SMI::enterprises.2606.7.4.1.2.1.3.3 = STRING: "PDU-Controller-Slave 1"
SNMPv2-SMI::enterprises.2606.7.4.1.2.1.3.4 = STRING: "PDU-MET-Slave 1"
Из неё мне нужно выбрать данные относящиеся к 2 и 4 элементу
Правило LLD:
discovery[{#PDU_MET_NAME},1.3.6.1.4.1.2606.7.4.1.2.1.3] c фильтром: {#PDU_MET_NAME} ^PDU-MET.*
Теперь в {#PDU_MET_NAME} у меня есть имена: PDU-MET-Master и PDU-MET-Slave 1
А в {#SNMPINDEX} соответственно индексы 2 и 4
PDU-MET-Master
2606.7.4.2.2.1.3.2.20 = STRING: "Total.Energy.Active.Value"
2606.7.4.2.2.1.11.2.20 = INTEGER: 170785
2606.7.4.2.2.1.10.2.20 = STRING: "17078.5 kWh"
...
PDU-MET-Slave 1
2606.7.4.2.2.1.3.4.20 = STRING: "Total.Energy.Active.Value"
2606.7.4.2.2.1.11.4.20 = INTEGER: 177545
2606.7.4.2.2.1.10.4.20 = STRING: "17754.5 kWh"
...
Теперь в правило LLD хочу добавить опрос имени клиента (имени PDU) чтобы использовать имя клиента в прототипах Item-ов как тег.
В вышеприведенных последовательностях с именем клиента "Test_Customer_1", {#SNMPINDEX} в oid стоит всегда на предпоследнем месте. То есть:
SNMPv2-SMI::enterprises.2606.7.4.2.2.1.10.2.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.2.1.10.4.2 = STRING: "Test_Customer_1"
Добавляю в правило LLD ещё один макрос {#PDU_NAME}:
discovery[{#PDU_MET_NAME},1.3.6.1.4.1.2606.7.4.1.2.1.3, {#PDU_NAME},1.3.6.1.4.1.2606.7.4.2.2.1.10.{#SNMPINDEX}.2]
Zabbix позволяет сохранить это правило. Но оно не работает. При попытке теста выдает ошибку:

Можно ли использовать {#SNMPINDEX} как часть oid-a LLD? Или эта задача решается как-то подругому?
Zabbix 7.0
Здесь мне подсказали что можно использовать имя клиета как тег и потом производить суммирование значений kWh на основе этого тега.
https://www.zabbix.com/forum/in-russian/486950-%D1%81%D0%B1%D0%BE%D1%80-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D1%81-%D1%83%D0%BC%D0%BD%D1%8B%D1%85-%D0%BF%D0%B0%D0%BD%D0%B5%D0%BB%D0%B5%D0%B9-%D1%80%D0%BE%D0%B7%D0%B5%D1%82%D0%BE%D0%BA-%D0%B4%D0%BB%D1%8F-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BD%D1%8B%D 1%85-%D1%88%D0%BA%D0%B0%D1%84%D0%BE%D0%B2-vertiv-geist-rack-pdus
Теперь я дошёл до менее "умных" панелей розеток от Rittal.
Идея та же: использовать имя клиета как тег и потом производить суммирование значений kWh на основе этого тега, так как оборудование одного клиета может находиться в разных серверных шкафах, а одни шкафы оборудованы Vertiv Geist Rack PDUs, другие - Rittal PDUs.
Rittal PDUs не позволяют получить данные для каждой розетки и не позволяют пометить каждую розетку, поэтому применяются в тех шкафах, которые полностью отданы одному клиенту. В шкафу стоят обычно два Rittal PDUs и работают как Master и Slave. То есть эта "пара" имеет один IP адрес. Но есть возможность подключить несколько Slave-PDUs.
Каждому устройству в этой паре (Master и Slave) можно присвоить имя. Я прописал им имя клиента "Test_Customer_1" чтобы потом использовать это имя как тег.
То есть что имеем:
snmpwalk -v 2c -c public 10.34.150.103:161 1.3.6.1.4.1.2606 | grep Test_Customer_1
SNMPv2-SMI::enterprises.2606.7.4.2.2.1.10.2.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.2.1.10.4.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.3.1.4.1.2.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.3.1.4.1.4.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.6.1.4.2.2.34561271 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.6.1.4.4.2.34561285 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.3.2.1.3.2.1 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.3.2.1.3.4.1 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.3.2.1.16.2.1 = STRING: "Device 2 (PDU-MET-Master) @1.02, Test_Customer_1: OK (1.87 A)"
SNMPv2-SMI::enterprises.2606.7.4.3.2.1.16.4.1 = STRING: "Device 4 (PDU-MET-Slave 1) @1.04, Test_Customer_1: OK (0.30 A)"
Я создал LLD для создания Item-ов по сбору данных на основе следующей последовательности (данные собственно собираются):
SNMPv2-SMI::enterprises.2606.7.4.1.2.1.3.1 = STRING: "PDU-Controller-Master"
SNMPv2-SMI::enterprises.2606.7.4.1.2.1.3.2 = STRING: "PDU-MET-Master"
SNMPv2-SMI::enterprises.2606.7.4.1.2.1.3.3 = STRING: "PDU-Controller-Slave 1"
SNMPv2-SMI::enterprises.2606.7.4.1.2.1.3.4 = STRING: "PDU-MET-Slave 1"
Из неё мне нужно выбрать данные относящиеся к 2 и 4 элементу
Правило LLD:
discovery[{#PDU_MET_NAME},1.3.6.1.4.1.2606.7.4.1.2.1.3] c фильтром: {#PDU_MET_NAME} ^PDU-MET.*
Теперь в {#PDU_MET_NAME} у меня есть имена: PDU-MET-Master и PDU-MET-Slave 1
А в {#SNMPINDEX} соответственно индексы 2 и 4
PDU-MET-Master
2606.7.4.2.2.1.3.2.20 = STRING: "Total.Energy.Active.Value"
2606.7.4.2.2.1.11.2.20 = INTEGER: 170785
2606.7.4.2.2.1.10.2.20 = STRING: "17078.5 kWh"
...
PDU-MET-Slave 1
2606.7.4.2.2.1.3.4.20 = STRING: "Total.Energy.Active.Value"
2606.7.4.2.2.1.11.4.20 = INTEGER: 177545
2606.7.4.2.2.1.10.4.20 = STRING: "17754.5 kWh"
...
Теперь в правило LLD хочу добавить опрос имени клиента (имени PDU) чтобы использовать имя клиента в прототипах Item-ов как тег.
В вышеприведенных последовательностях с именем клиента "Test_Customer_1", {#SNMPINDEX} в oid стоит всегда на предпоследнем месте. То есть:
SNMPv2-SMI::enterprises.2606.7.4.2.2.1.10.2.2 = STRING: "Test_Customer_1"
SNMPv2-SMI::enterprises.2606.7.4.2.2.1.10.4.2 = STRING: "Test_Customer_1"
Добавляю в правило LLD ещё один макрос {#PDU_NAME}:
discovery[{#PDU_MET_NAME},1.3.6.1.4.1.2606.7.4.1.2.1.3, {#PDU_NAME},1.3.6.1.4.1.2606.7.4.2.2.1.10.{#SNMPINDEX}.2]
Zabbix позволяет сохранить это правило. Но оно не работает. При попытке теста выдает ошибку:
Можно ли использовать {#SNMPINDEX} как часть oid-a LLD? Или эта задача решается как-то подругому?
Zabbix 7.0
Comment