В одноv item (get SNMP) в integer "упакованы" два разных subitem-а.

[DSV12]

Всем привет!

Есть датчик, с которого по SNMP снимается integer value:

# snmpwalk -c public -v 2c -On 192.168.1.10 REMER-PDU-R01-MIB::dinValue.1
.1.3.6.1.4.1.52964.1.1.2.1.4.1 = INTEGER: 7799024

value для этого типа датчика (с индексом .1 в примере) интепретируется так:

- bit0..15 - temperature *10 ᵒC;
- bit16..31 - humidity *10 %RH.

Example: dinValue = 0x00E0 00FD
Temperature = 0x00FD/10 = 253/10 = 25,3 ᵒC
Humidity = 0x00E0/10 = 224/10 = 22,4 %RH

Как правильнее это дело в zabbix-е организовать, как считаете? Два вычисляемых item-а? Или можно обойтись однократным get-ом и пред/постобработкой? Но ведь разная размерность, единицы измерения разные, как минимум.

[Kos]

Как правильнее это дело в zabbix-е организовать, как считаете?

Я бы делал три элемента данных: один мастер, который получает значение по SNMP (и после отладки можно его историю вообще не хранить), и два - зависимых от него, которые через предобработку извлекают из мастера каждый свою часть.

[DSV12]

Я бы делал три элемента данных: один мастер, который получает значение по SNMP (и после отладки можно его историю вообще не хранить), и два - зависимых от него, которые через предобработку извлекают из мастера каждый свою часть.

Константин, категорически приветствую!

Не поверишь - исходный вопрос писал сюда на ночь глядя, и во сне приснилось решение, совпадающее с твоим вариантом - master + два зависимых item-а. В момент, когда ты написал сюда, я уже спал, но твоё сообщение на фитнес-браслет переслалось, и я, не приходя в сознание, видимо его "прочитал" во сне

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

[Kos]

Константин, категорически приветствую!
[...]
Кстати, возможно удобнее будет зависимые элементы не предобработкой делать, а вычисляемыми. Надо попробовать...

Сергей, взаимно!

Да, забавно

В данном конкретном случае я не вижу выгоды от использования вычисляемых элементов данных, если всё можно добыть предобработкой.
Зато у вычисляемых есть и свои неочевидные особенности, которые могут оказаться недостатками:

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

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

У меня получилось так:

Температура	return (parseInt(value) & 0x0FFFF)/10;
Влажность	return (parseInt(value)>>16)/10;

Соответственно, для элементов данных выставляем Units - "ᵒC" и "%RH", а тип - "Numeric (float)" (для обоих).

Засылаем в мастер-айтем значение из твоего примера, на выходе имеем:

Суховато у вас в серверной

[DSV12]

Приветствую!

Проверил, с предобработкой JavaScript прекрасно работает.

Хм, у меня zabbix v4.4, а для этой версии на сайте Забикса нет документации для "Javascript предобработка" (ближайшая версия, для которой документация есть - 5.0). Хотя в меню создания ЭД в "Предобработке" Javascript присутствует. Никогда раньше js не пользовал, проверять надо.

Суховато у вас в серверной

Это не в серверной (там почти порядок, прецизионные кондеи работают), пока разборки в рабочем кабинете - да, сухо, зима, мороз

На самом деле с этими датчиками не всё так просто:

# snmpwalk -c public -v 2c -On 192.168.1.10 REMER-PDU-R01-MIB::dinEntry
REMER-PDU-R01-MIB::dinIndex.1 = INTEGER: 1
REMER-PDU-R01-MIB::dinIndex.2 = INTEGER: 2
REMER-PDU-R01-MIB::dinIndex.3 = INTEGER: 3
REMER-PDU-R01-MIB::dinIndex.4 = INTEGER: 4
REMER-PDU-R01-MIB::dinIndex.5 = INTEGER: 5
REMER-PDU-R01-MIB::dinIndex.6 = INTEGER: 6
REMER-PDU-R01-MIB::dinIndex.7 = INTEGER: 7
REMER-PDU-R01-MIB::dinIndex.8 = INTEGER: 8
REMER-PDU-R01-MIB::dinIndex.9 = INTEGER: 9
REMER-PDU-R01-MIB::dinIndex.10 = INTEGER: 10
REMER-PDU-R01-MIB::dinIndex.11 = INTEGER: 11
REMER-PDU-R01-MIB::dinIndex.12 = INTEGER: 12
REMER-PDU-R01-MIB::dinName.1 = STRING: "DI1"
REMER-PDU-R01-MIB::dinName.2 = STRING: "DI2"
REMER-PDU-R01-MIB::dinName.3 = STRING: "DI3"
REMER-PDU-R01-MIB::dinName.4 = STRING: "DI4"
REMER-PDU-R01-MIB::dinName.5 = STRING: "DI5"
REMER-PDU-R01-MIB::dinName.6 = STRING: "DI6"
REMER-PDU-R01-MIB::dinName.7 = STRING: "DI7"
REMER-PDU-R01-MIB::dinName.8 = STRING: "DI8"
REMER-PDU-R01-MIB::dinName.9 = STRING: "DI9"
REMER-PDU-R01-MIB::dinName.10 = STRING: "DI10"
REMER-PDU-R01-MIB::dinName.11 = STRING: "DI11"
REMER-PDU-R01-MIB::dinName.12 = STRING: "DI12"
REMER-PDU-R01-MIB::dinState.1 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.2 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.3 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.4 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.5 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.6 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.7 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.8 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.9 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.10 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.11 = INTEGER: 0
REMER-PDU-R01-MIB::dinState.12 = INTEGER: 0
REMER-PDU-R01-MIB::dinValue.1 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.2 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.3 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.4 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.5 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.6 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.7 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.8 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.9 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.10 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.11 = INTEGER: 1
REMER-PDU-R01-MIB::dinValue.12 = INTEGER: 1
​

С помощью LLD можно найти все три таблицы по индексам, без проблем: dinName, dinState, dinValue. dinValue всегда отдаёт INTEGER, но интерпретация зависит от выбора т.н. шаблона (свойство этой конкретной железки):



Интерпретация данных устроена так:

Digital input value:
1.For DIN template "Impulse counter": impulse count
2.For DIN template "RS-HT1":
- bit0..15 - temperature *10 ᵒC;
- bit16..31 - humidity *10 %RH.
Example: dinValue = 0x00E0 00FD
Temperature =  0x00FD/10 = 253/10 = 25,3 ᵒC
Humidity =  0x00E0/10 = 224/10 = 22,4 %RH
3.For another templates: state on DIN pin (0/1)​

Т.е., три варианта.

Какой конкретно шаблон для какого конкретного входа выбран, видно глазами только в веб-интерфейсе. В snmp найти это явное соответствие не удалось. Экспериментально удалось выяснить, что если выбран шаблон RS-HT1 (как раз он был в моём первом примере), то появляется индекс rsht1Table.rsht1Entry.rsht1Index Как прототипы ЭД/триггеров создавать на автомате - не соображу никак. Устройств много, датчики будут подключаться необязательно к одним и тем же входам. Руками в шаблоне переопределять, назначив на какой-нибудь макрос? И создавать ЭД/триггер в зависимости от 1/2/3 этого макроса? Хотя ведь dinValue всегда INTEGER, меняется только его интерпретация. Для варианта 2 (RS-HT1) не забыть сделать зависимые элементы и предобработку, по схеме, предложенной kos.

Написал - дошло: LLD по rsht1Table.rsht1Entry.rsht1Index и прототипы по найденым в этой таблице элементам. А вот как отличить шаблон 1 (счётчик) от 3 (0/1)?

[Kos]

Серьёзно, Zabbix v4.4 до сих пор в продакте? Эта версия же не поддерживается уже сто лет в обед... Вон, уже v7.0 на подходе (ну, реально – где-то весной ).

Одна из наиболее ценных для меня лично вещей, которые есть в современных версиях (ну, помимо JavaScript), – это LLD overrides (на русский перевели как «замещения»). Почитай, тебе тоже понравится

(блин, да что же это такое - дважды редактирую, а отправляется только часть сообщения; дописываю ещё раз)

В двух словах - это возможность при низкоуровневом обнаружении создавать не только однотипные объекты, но и немного отличающиеся (либо не создавать их вовсе).
Например, для твоего случая: если бы нашлась такая таблица SNMP, по которой можно было бы определить шаблон датчика, то тогда можно было бы создавать зависимые элементы данных (с соответствующей предобработкой и триггерам к ним) только для нужных линий.

Ну, а если такой таблицы в природе не существует, то единственный вариант, который приходит мне в голову, - это "нарисовать" такую таблицу самостоятельно при помощи пользовательских макросов с контекстом.

[DSV12]

Серьёзно, Zabbix v4.4 до сих пор в продакте? Эта версия же не поддерживается уже сто лет в обед...

Всё, что мне от забикса требовалось до сих пор - в 4.4 есть. А поддержкой не пользовался, ни разу . Сетевое оборудование мониторим (и управляем) средствами HPE IMC - намного удобнее оказалось, хотя сильно небесплатная. Одна только возможность IMC полностью автоматического построения интерактивной карты сети для меня перевешивает все остальное. Недавно вот LanTopology добавили, для поиска MAC <-> порт очень классный инструмент. А заббикс 4.4 у нас мониторит в основном ОС: linux/windows/vmware/hyper-v всякие. Что реально напрягает - смена формата шаблонов при переходе на 5.0, для нового железа бывает проблема найти шаблон в формате 3/4.

Вон, уже v7.0 на подходе (ну, реально – где-то весной).

Да я в курсе. Но, если честно, после действительно революционных переходов версий 3 -> 4 -> 5 (злые языки говорили, что главным новшеством в 5-ой версии был перенос меню с топа в левую колонку ) шестая меня откровенно не впечатлила. И, глядя на грядущую 7-ю версию, есть ощущение потери динамки развития. Хотя бы те же "классические" графики - смотрятся архаично, реальных мощных нововведений не очень много. У нас все (кроме меня) пользователи своих экземпляров заббикса поголовно картинки выводят средствами grafana - смотрится намного симпатичнее, дашборды там вообще фантастика.

Одна из наиболее ценных для меня лично вещей, которые есть в современных версиях (ну, помимо JavaScript), – это LLD overrides (на русский перевели как «замещения»). Почитай, тебе тоже понравится

Читал, в курсе. Но в моих реалиях оказалось невостребованным.

Планы перехода на новую версию заббикса (а может уже окажется, что и не на забикс, а на какой-нибудь Prometheus + Grafana) есть, нет времени/ресурсов.

[Kos]

Всё, что мне от забикса требовалось до сих пор - в 4.4 есть. А поддержкой не пользовался, ни разу

Понятно, что "на вкус и цвет все фломастера разные", но позволю себе не согласиться.

Во-первых, слово "поддержка" я имел в виду в более широком смысле. Это не только возможность купить в компании-разработчике помощь за деньги (что для многих сейчас невозможно по совершенно другим причинам, которые я бы не хотел обсуждать на этом форуме), но и следующие моменты:

• даже если найдёте реальную ошибку и зарегистрируете её в качестве бага, исправлять её никто не будет;
• при обращении на форум с вопросом "Как сделать то-то?" - есть большой шанс получить ответ: "Элементарно, используйте такую-то фичу!", - но воспользоваться этим советом невозможно из-за того, что эта "фича" появилась только в более новых версиях;
• как ты сам отметил, новые шаблоны (для нового оборудования или новых сервисов) появляются только для более новых версий Zabbix. И связано это, не в последнюю очередь, с предыдущим пунктом (т.е. тем, что эти шаблоны используют какие-то новые "фичи");
• какие-то вещи добавляются или исправляются в агентах; но формально - агенты совместимы только в одну сторону (более старые агенты поддерживаются при работе с более новым сервером, но не наоборот; хотя по факту совместимость гораздо шире).*

* Некоторые примеры:

• на Windows Server 2022 агент версии 4.0.18 (успешно работавший у нас на всех предыдущих версиях Windows) почему-то при регистрации его в качестве службы Windows (запуске его с ключиком "--install") делал это криво: даже если его разрегистрировать обратно (запуская с ключиком "--uninstall") и пытаться проставить агент более новой версии (но тот момент - 5.0 или 5.4), то эти агенты падали сразу после запуска. Помогало только ручное удаление сервиса с помощью такой команды:

sc delete "Zabbix Agent"​

(кстати, 4.0.33 работала успешно)

• в какой-то из относительно старых версий агента под Windows ещё и время убегало (при использовании активных проверок, особенно мониторинге логов).

после действительно революционных переходов версий 3 -> 4 -> 5

Что ж такого революционного было именно в этих переходах? Вот меня лично несколько разочаровал переход 5.x -> 6.x, при котором кардинально переделали механизм обсчёта SLA, при этом упустив довольно много вещей, которыми у нас уже привыкло пользоваться "высокое начальство". В остальных переходах, вроде бы, всё происходило достаточно эволюционно.

есть ощущение потери динамки развития. Хотя бы те же "классические" графики - смотрятся архаично

Так ведь как раз в этом направлении развитие совершенно явное!
Классические графики, действительно, практически не изменились, но они уже давно позиционируются лишь как средство совместимости со старыми версиями, а им на замену рекомендуется использовать виджеты панелей (которые, как раз, от версии к версии прогрессируют довольно сильно). Более того, при каком-то из обновлений (кажется, 5.4) вообще отказались от прежней концепции "комплексных экранов (Screens)" - если они были, то они автоматически конвертируются в панели (dashboards).

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

Ну, первое, для чего эту "фичу" использовал я, - это подкорректировал свой стандартный шаблон для OS Linux, чтобы при обнаружении файловых систем с типами btrfs и vfat не создавались элементы данных для контроля количества inodes (которые для них всё равно не имеют смысла и только мозолят глаз своим состоянием "not supported"). Ну, а затем уже взялся за другие места