Конвертация HEX to UTF-8 средствами zabbix

[surgeon_2022]

Всем привет,

Имеется следущая строка для discovery:
Code:

discovery[{#ICAM_IP}, 1.3.6.1.4.1.1004849.2.10.2.2.1.2, {#CAM_NAME}, 1.3.6.1.4.1.1004849.2.10.2.2.1.4, {#CAM_STATUS}, 1.3.6.1.4.1.1004849.2.10.2.2.1.3]

Вот вывод функции тест и snmpwalk

[{"{#SNMPINDEX}":"1","{#ICAM_IP}":"10.17.110.65","{#CAM_NAME}":"D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 31 ","{#CAM_STATUS}":"Connected"},{"{#SNMPINDEX}":"2","{#ICAM_IP}":"10.17.110.66","{#CAM_NAME}":"D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 32 ","{#CAM_STATUS}":"Connected"},{"{#SNMPINDEX}":"3","{#ICAM_IP}":"10.17.110.67","{#CAM_NAME}":"D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 33 ","{#CAM_STATUS}":"Connected"},{"{#SNMPINDEX}":"4","{#ICAM_IP}":"10.17.110.68","{#CAM_NAME}":"D0 9A D0 B0 D0 BD D0 B0 D0 BB 34 ","{#CAM_STATUS}":"Unconnect"},{"{#SNMPINDEX}":"5","{#ICAM_IP}":"10.17.110.69","{#CAM_NAME}":"D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 35 ","{#CAM_STATUS}":"Connected"}

iso.3.6.1.4.1.1004849.2.10.2.2.1.4.1 = Hex-STRING: D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 31
iso.3.6.1.4.1.1004849.2.10.2.2.1.4.2 = Hex-STRING: D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 32
iso.3.6.1.4.1.1004849.2.10.2.2.1.4.3 = Hex-STRING: D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 33
iso.3.6.1.4.1.1004849.2.10.2.2.1.4.4 = Hex-STRING: D0 9A D0 B0 D0 BD D0 B0 D0 BB 34
iso.3.6.1.4.1.1004849.2.10.2.2.1.4.5 = Hex-STRING: D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 35

Необходимо преобразовать HEX формат вывода ветки 1.3.6.1.4.1.1004849.2.10.2.2.1.4 в UTF-8.
В заббиксе 7,0,6 обнаружил соотвествующую функцию в предпроцессинге



В поле "Parameters" вводил и 1.3.6.1.4.1.1004849.2.10.2.2.1.4 и 1.3.6.1.4.1.1004849.2.10.2.2.1.4.{#SNMPINDEX}. При любом расскладе выдает ошибку:
unable to extract value for given OID: invalid OID format

Подскажите, пожалуйста, правильный формат для данного поля. Может я что-то не так делаю?

[Kos]

Ну, то есть возвращаемся к тому, что:

• правило обнаружения сейчас работает правильно и в LLD-макросы подставляются верные значения;
• элемент данных для Camera 1 Name создан из прототипа и своё значение получает отдельным запросом, причём для его получения по старинке используется просто OID в поле "SNMP OID" (для которого такого способа предобработки не предусмотрено);
• для чего этот элемент данных вообще нужен - так и осталось неясным (поскольку для остальных прототипов элементов данных и триггеров вполне можно использовать LLD-макрос {#CAM_NAME} в их именах, чтобы подставлять его ещё на этапе отработки правила LLD).

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

1. Проще, но менее эффективно: оставить почти как есть, но в прототипе элемента данных для имени камеры:
а) поменять поле "SNMP OID" с простого <oid>-а на get[<oid>], т.е. текущее содержимое этого поля заключить в квадратные скобки и дописать перед ними "get";
б) добавить в шаг предобработки "SNMP get value" с той же опцией "UTF-8 from Hex-STRING".

2. Чуть сложнее, но более правильно, поскольку не делается ненужных SNMP-запросов:
а) то, о чём я писал чуть раньше, оформляется как обычный элемент данных (не LLD), который даёт на выходе JSON (только тип данных для него нужно указать: "Text");
б) элемент данных для правила LLD делаем зависимым от этого элемента данных, т.е. просто используем его как есть;
в) в прототипе элемента данных для имени камеры не делаем никаких новых обращений по SNMP, а тоже делаем их зависимыми от того же исходного элемента данных (возвращающего JSON); а для извлечения из этого JSON-а нужного фрагмента добавляем шаг предобработки "JSON Path" со значением в поле JSONPath, например, таким:

$[?(@.cam_name == "{#CAM_NAME}")].cam_name.first()

[Kos]

Да, чуть-чуть не так; я попробую подсказать, как это делается в 7.0.

1) вместо ключа discovery[...] используете ключ walk[...]. Например, если для дискаверинга вам нужны только IP и имя камеры, то можно указать:

walk[1.3.6.1.4.1.1004849.2.10.2.2.1.2, 1.3.6.1.4.1.1004849.2.10.2.2.1.4]

При тестировании должна получиться "простыня", идентичная выводу команды snmpwalk с ключом "-On":

.1.3.6.1.4.1.1004849.2.10.2.2.1.4.1 = Hex-STRING: D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 31
.1.3.6.1.4.1.1004849.2.10.2.2.1.4.2 = Hex-STRING: D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 32
.1.3.6.1.4.1.1004849.2.10.2.2.1.4.3 = Hex-STRING: D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 33
.1.3.6.1.4.1.1004849.2.10.2.2.1.4.4 = Hex-STRING: D0 9A D0 B0 D0 BD D0 B0 D0 BB 34
.1.3.6.1.4.1.1004849.2.10.2.2.1.4.5 = Hex-STRING: D0 9A D0 BE D0 BB D1 86 D0 B5 D0 BD D1 82 D1 80 20 2D 35
.1.3.6.1.4.1.1004849.2.10.2.2.1.2.1 = STRING: 10.17.110.65
.1.3.6.1.4.1.1004849.2.10.2.2.1.2.2 = STRING: 10.17.110.66
.1.3.6.1.4.1.1004849.2.10.2.2.1.2.3 = STRING: 10.17.110.67
.1.3.6.1.4.1.1004849.2.10.2.2.1.2.4 = STRING: 10.17.110.68
.1.3.6.1.4.1.1004849.2.10.2.2.1.2.5 = STRING: 10.17.110.69

2) в препроцессинге для этого элемента данных добавляете шаг "SNMP walk to JSON", чтобы в итоге получить вывод, аналогичный тому, который получался при использовании ключа discovery[...]. При этом добавляете параметры в соответствии с Таблицей 1 (см. ниже).
В итоге ваша "простыня" превращается в такой JSON (отформатировано для наглядности):

[
  {"{#SNMPINDEX}":"2","cam_name":"Колцентр -2","cam_ip":"10.17.110.66"},
  {"{#SNMPINDEX}":"5","cam_name":"Колцентр -5","cam_ip":"10.17.110.69"},
  {"{#SNMPINDEX}":"4","cam_name":"Канал4","cam_ip":"10.17.110.68"},
  {"{#SNMPINDEX}":"3","cam_name":"Колцентр -3","cam_ip":"10.17.110.67"},
  {"{#SNMPINDEX}":"1","cam_name":"Колцентр -1","cam_ip":"10.17.110.65"}
]

3) используете этот вывод для работы правила LLD. В свойствах правила на вкладке "LLD macros" указываете:
{#CAM_NAME} ==> $.cam_name
{#CAM_IP} ==> $.cam_ip

Таблица 1:

Field	OID prefix	Format
cam_name	1.3.6.1.4.1.1004849.2.10.2.2.1.4	UTF-8 from hex-STRING
cam_ip	1.3.6.1.4.1.1004849.2.10.2.2.1.2	Unchanged

[surgeon_2022]

Спасибо огромное
Вот я настроил. При тесте выходит кирилицей. В сплывающем триггере кирилицей а в latest data - hex

[Kos]

Спасибо огромное
Вот я настроил. При тесте выходит кирилицей. В сплывающем триггере кирилицей а в latest data - hex

Не понял. Что именно у вас на первом скриншоте, где Latest data? Созданные из прототипов элементы данных? Если да - то каким образом они получают свои значения (а главное - зачем они вообще нужны, они же содержат статическую информацию, нужную только для обнаружения)?

[surgeon_2022]

Первый скрин и есть latest data

[surgeon_2022]

Вот так выходит при тестах

[{"{#SNMPINDEX}":"2","{#ICAM_IP}":"10.17.110.66","{#CAM_STATUS}":"Connected","{#CAM_NAME}":"Колцентр -2"},{"{#SNMPINDEX}":"5","{#ICAM_IP}":"10.17.110.69","{#CAM_STATUS}":"Connected","{#CAM_NAME}":"Колцентр -5"},{"{#SNMPINDEX}":"4","{#ICAM_IP}":"10.17.110.68","{#CAM_STATUS}":"Unconnect","{#CAM_NAME}":"Канал4"},
{"{#SNMPINDEX}":"3","{#ICAM_IP}":"10.17.110.67","{#CAM_STATUS}":"Connected","{#CAM_NAME}":"Колцентр -3"}]

А вот SNMP OID Walk

[Kos]

Первый скрин и есть latest data

Это-то я понял. Хорошо, перефразирую свой вопрос: Что именно у вас на первом скриншоте, который Latest data? (и далее по тексту)
Откуда у вас взялся элемент данных "Camera 1 Name" и каким образом он получает своё значение, а главное - зачем он вообще нужен?

[surgeon_2022]

Это-то я понял. Хорошо, перефразирую свой вопрос: Что именно у вас на первом скриншоте, который Latest data? (и далее по тексту)
Откуда у вас взялся элемент данных "Camera 1 Name" и каким образом он получает своё значение, а главное - зачем он вообще нужен?

Camera 1 Name - это item prototype. Таким образом заббикс получает название камер

[surgeon_2022]

Camera 1 Name - это item prototype. Таким образом заббикс получает название камер
Вот этот прототип

[Kos]

Ну, то есть возвращаемся к тому, что:

• правило обнаружения сейчас работает правильно и в LLD-макросы подставляются верные значения;
• элемент данных для Camera 1 Name создан из прототипа и своё значение получает отдельным запросом, причём для его получения по старинке используется просто OID в поле "SNMP OID" (для которого такого способа предобработки не предусмотрено);
• для чего этот элемент данных вообще нужен - так и осталось неясным (поскольку для остальных прототипов элементов данных и триггеров вполне можно использовать LLD-макрос {#CAM_NAME} в их именах, чтобы подставлять его ещё на этапе отработки правила LLD).

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

1. Проще, но менее эффективно: оставить почти как есть, но в прототипе элемента данных для имени камеры:
а) поменять поле "SNMP OID" с простого <oid>-а на get[<oid>], т.е. текущее содержимое этого поля заключить в квадратные скобки и дописать перед ними "get";
б) добавить в шаг предобработки "SNMP get value" с той же опцией "UTF-8 from Hex-STRING".

2. Чуть сложнее, но более правильно, поскольку не делается ненужных SNMP-запросов:
а) то, о чём я писал чуть раньше, оформляется как обычный элемент данных (не LLD), который даёт на выходе JSON (только тип данных для него нужно указать: "Text");
б) элемент данных для правила LLD делаем зависимым от этого элемента данных, т.е. просто используем его как есть;
в) в прототипе элемента данных для имени камеры не делаем никаких новых обращений по SNMP, а тоже делаем их зависимыми от того же исходного элемента данных (возвращающего JSON); а для извлечения из этого JSON-а нужного фрагмента добавляем шаг предобработки "JSON Path" со значением в поле JSONPath, например, таким:

$[?(@.cam_name == "{#CAM_NAME}")].cam_name.first()

[surgeon_2022]

Ага, я вас кажется понял, тут у нас два раза запрашивается одна и та же информация. Тогда мне надо walk вывести в Item, так как я не вижу как я могу сделать зависисые item protype от discovery.
Сейчас попробую

[surgeon_2022]

Kos огромное спасибо. Все работает и отображается как надо. Сделал через зависимые item prototype от item с walk