ipmi sensor data is not available

[maclin]

Здравствуйте! Имеется Zabbix 5.0.1 и супермикро сервер с X8DTU-LN4+
Пилю шаблон под ipmi, данные по вольтажу, температуре и тд собираются, а вот по блоками питания никак.
В логах заббикс сервера имеется такое

29943:20210811:115606.071 Added sensor: host:'xxx:623' id_type:0 id_sz:11 id:'PS2 Status' reading_type:0x6f ('sensor specific') type:0x8 ('power_supply') domain:'0' name:'(10.2).PS2 Status'
29943:20210811:115606.072 Added sensor: host:'xxx:623' id_type:0 id_sz:11 id:'PS1 Status' reading_type:0x6f ('sensor specific') type:0x8 ('power_supply') domain:'0' name:'(10.1).PS1 Status'
29943:20210811:115606.072 Added sensor: host:'xxx:623' id_type:0 id_sz:10 id:'PS Status' reading_type:0x6f ('sensor specific') type:0x8 ('power_supply') domain:'0' name:'(10.1).PS Status'

То есть аж 3 IPMI sensor ключа: PS Status, PS1 Status и PS2 Status.
Завел их (прикладываю шаблон)
Но данные отдаются только по ключу PS Status (причем 0, будто бы и нет блока питания), а PS1 Status и PS2 Status (на сервере 2 БП) пишут ошибку

Not supported: sensor data is not available

Не совсем понимаю почему так, он ведь видит все эти ключи.

[maclin]

Открыл тикет, надеюсь его решат

https://support.zabbix.com/browse/ZBX-19799

[Hamardaban]

Могу только заменить что это "битовые" регистры (Sensor Type (Discrete)). С ними были какие-то засады - точно не помню

Вот что в документации забикса

There are few sensors with “reading_type:0x6f” in our example. For these sensors the “Table 42-1, Event/Reading Type Code Ranges” advises to use “Table 42-3, Sensor Type Codes” for decoding meanings of bits. For example, sensor 'Power Unit Stat' has type “type:0x9” which means “Power Unit”. Offset 00h means “PowerOff/Power Down”. In other words if the least significant bit is 1, then server is powered off.

[maclin]

Есть еще серваки с SuperMicro X9DRG-HF и там в тэмплейте настроен аналогичный айтем, единственное в логах сервера обозначены были как PS1 Status0 и PS2 Status0, и эти ключики работают, собираются данные.

[Hamardaban]

так яж и говорю - были проблемы именно с дискретными сенсорами ... не везде они читались.

[maclin]

Ну вот как выглядят ключи с X9DRG-HF

7509:20210810:135528.120 Added sensor: host:'yyy:623' id_type:0 id_sz:12 id:'PS1 Status0' reading_type:0x6f ('sensor specific') type:0x8 ('power_supply') full_name:'(10.1).PS1 Status0'
7555:20210810:135529.913 Added sensor: host:'yyy:623' id_type:0 id_sz:12 id:'PS2 Status0' reading_type:0x6f ('sensor specific') type:0x8 ('power_supply') full_name:'(10.2).PS2 Status0'

Если сравнивать их

29943:20210811:115606.072 Added sensor: host:'xxx:623' id_type:0 id_sz:11 id:'PS1 Status' reading_type:0x6f ('sensor specific') type:0x8 ('power_supply') domain:'0' name:'(10.1).PS1 Status'
7509:20210810:135528.120 Added sensor: host:'yyy:623' id_type:0 id_sz:12 id:'PS1 Status0' reading_type:0x6f ('sensor specific') type:0x8 ('power_supply') full_name:'(10.1).PS1 Status0'

То у первого проблемного какой-то domain:'0' и name, а у второго просто full_name

[Hamardaban]

еще посмотрите на сенсоры через ipmitools - возможно станет более понятно различие

[maclin]

Вот на проблемном

ipmitool sensor | grep "PS. Status"
PS1 Status | na | discrete | na | na | na | na | na | na | na
PS2 Status | na | discrete | na | na | na | na | na | na | na

Вот на нормальном

ipmitool sensor | grep "PS. Status"
PS1 Status | 0x1 | discrete | 0x0100| na | na | na | na | na | na
PS2 Status | 0x1 | discrete | 0x0100| na | na | na | na | na | na

Получается оба дискретные, но вот данные по проблемному все "na"
Интересно

[maclin]

ipmiutil соответственно говорит такие штуки

0b02 SDR Full 01 6f 20 a 08 snum 80 PS1 Status = 00 Unknown 0.00 Requested sensor, data, or record
0b45 SDR Full 01 6f 20 a 08 snum 91 PS2 Status = 00 Unknown 0.00 Requested sensor, data, or record

0de3 SDR Comp 02 6f 20 a 08 snum c8 PS1 Status = 0001 Present
0ffb SDR Comp 02 6f 20 a 08 snum c9 PS2 Status = 0001 Present

Значит проблема на стороне сервера блин. А я как раз уже думал сделать обработку на уровне скрипта и ipmiutil...

[maclin]

Похоже у него реально один счетчик
PS Status | 0x0 | discrete | 0x00ff| na | na | na | na | na | na

И 0 = это хорошо типа. Ну штош. Спасибо за помощь!

[Andrew Grekhov]

1. Убедись что в IPMIVIEW БП оттображаются все корректно.
2. Не надо считывать бинарные значения с supermicro. Выдача 0 может означать, как значение реально равно 0,
так и ошибку чтения.
3. В русскоязычном инете есть две статьи как читать БП от супермикры по i2c: моя, и ссылающаяся на меня.
В гугле: ipmi supermicro тринити PMBUS
PS. Может оказаться что в БП стоит два вентилятора.

[maclin]

Гляну обязательно.
Но вот сейчас добрался до проверки триггера, выдернули шнур из сервера, в ipmi web версии видно статус

PS Status         Power Supply Failure detected.

а заббикс получает все тот же 0, если глянуть на сервере через ipmiutil, то выдает типа ОК

ipmiutil sensor | grep -i "ps status"
0abf SDR Full 01 6f 20 a 08 snum 55 PS Status        = 00 OK   0.00 na

Не сработало как хотелось...

[maclin]

В общем удалось нащупать через ipmitool, что отдают разные данные (если вытащить питание из БП)

regular PS1 0x06 0x52 0x07 0x70 0x01 0x0c - 01 - ок и 00 - не ок
PM Bus PS1 0x06 0x52 0x07 0x78 0x01 0x78 - 01 - ок и 48 - не ок

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

[Andrew Grekhov]

У Вас ошибочный алгоритм решения задачи.
У БП бывает три состояния:
всё работает - всё читается,
пропало входное питание - всё читается, но ряд параметров нули,
вытащили БП - по этому адресу выдаётся ошибка.
Сгорание БП не расматриваю, т.к. у меня таких случаев не было.
Выложите картинку параметров БП с IPMIVIEW от supermicro.
(Если боитесь серийники можно замарать).
Верный алгоритм такой,IMHO: мониторинг параметров(Uin,Fan1,Fan2,temp1) по крону, при прилетании snmptrap принудительный опрос БП.
Помните, что на разъём предназначеный для БП от supermicro можно подцепить любое i2c устройство, и читать его через ipmitool.
Вам для самостоятельного решения задачи достаточно прочитать ровно одну таблицу в официальной документации PMBUS ver1.2.
PS. Вам очень повезло, что у вас по 0x07 читается, значит железка современная малопроблемная. Вот будь у вас 0х05...
PPS. Если будете декодировать Snmptrap от supermicro, не ругайтесь, пожалуйста сильно громко. Я не знаю за сколько километров я от Вас нахожусь, но я услышу.

[maclin]

Да не ошибочный...
Мне нужно было решение из коробки с помощью Ipmi-агента от заббикс сервера , с него не получилось вытянуть нужные данные по БП (по fan/cpu/dimm все вытащилось), так как что Ipmitool, что ipmiutil дают неверные данные.
Поэтому придется делать обработку через userparameter и ipmitool с raw
"Сгорание БП не расматриваю, т.к. у меня таких случаев не было." - вот у меня было как раз.
А когда БП вытащен - то это считается норм ситуацией, он просто не видит второй ПБ и считает, что это ок, что один блок питания только.

[Andrew Grekhov]

Решение на базе snmptrapd и будет полностью из коробки.
При проблемах с питанием там есть биты set и reset.
Вам нужны сообщения оканчивающиеся на: 08 50 6F 77 65 72 20 53 75 70 70 6C 79 C1
Как отличать БП я уже писал.
Кстати, раскажите по подробнее почему БП сдох. Какие были результаты диагностики?

[maclin]

У нас нет таких компетенций по БП, чтобы диагностировать их, вышел из строя проработав лет 8...