| 3 | | Например, у нас имеется несколько типов плат (SM-01, SM-02, SM-03), у которых практически полностью совпадает MIB. Кроме этого, запланирована разработка плат SM-11 и SM-12, у которых, как я подозреваю, MIB будет таким же. Однако невозможно создать в Zbbix один шаблон для всех этих плат сразу, так как существующая схема требует указания наименования платы в основной части ключа (`MC04.SM-01.snmp.7.5.2.0[...]`), а сервер Zabbix не позволяет использовать макросы в основной части (то есть нельзя гаписать так: `MC04.{#BOARDNAME}.snmp.7.5.2.0[...]`). Zabbix может использовать макросы только в параметрах ключа (`MC04.SM-02.snmp.7.5.2.0[{#MACRO}, ....]`). Как результат, для каждой из пяти перечисленных плат приходится создавать свой отдельный шаблон, отличающийся только наименованием платы. |
| | 3 | Например, у нас имеется несколько типов плат (SM-01, SM-02, SM-03), у которых практически полностью совпадает MIB. Кроме этого, запланирована разработка плат SM-11 и SM-12, у которых, как я подозреваю, MIB будет таким же. Однако невозможно создать в Zabbix один шаблон для всех этих плат сразу, так как существующая схема требует указания наименования платы в основной части ключа (`MC04.SM-01.snmp.7.5.2.0[...]`), а сервер Zabbix не позволяет использовать макросы в основной части (то есть нельзя написать так: `MC04.{#BOARDNAME}.snmp.7.5.2.0[...]`). Zabbix может использовать макросы только в параметрах ключа (`MC04.SM-02.snmp.7.5.2.0[{#MACRO}, ....]`). Как результат, для каждой из пяти перечисленных плат приходится создавать свой отдельный шаблон, отличающийся только наименованием платы. |
| 35 | | - `name=<наименование платы>`: дополнительно проверяется, что установленная |
| 36 | | - `type=<код типа платы>`: дополнительно проверяется, что установленная |
| 37 | | - `format=<string|hex|array|auto>`: позволяет устранить неоднозначность формата возвращаемого значения. Так как во внутреннем протоколе обмена с платами отсутствует специальный тип "двоичные данные", для передачи двочиных данных используется тип "строка". Но, во-первых, произвольные двоичные данные не всегда представляют собой валидный код UTF-8, а во-вторых, даже если представляют, работать с таким представлением не очень удобно, т.к. трудно найти среди символов нужный двоичный байт. В запросе API можно было указать параметр `strings2data`, и тогда строки возвращаются в виде массива байт. В агенте Zabbix реализован другой механизм - если в строке есть хотя бы один непечатный символ, байты преобразуются в последовательность 16-ричный кодов, разделенных пробелами (примерно так, как это делает библиотека libsnmp).[[br]][[br]] Проблема в том, что получатель строки не всегда имеет возможность знать, получил ли он преобразованные в hex данные, или данные в таком виде и были отправлены непосредственно платой. Для устранения этой неоднозначности предлагается использовать параметр `format=`, который безусловно преобразует принятую из платы строку в заданный формат (у типам данных, отличным от строки, эти параметры не применяются). Предлагается реализовать следующие значения параметра: |
| | 35 | - `name=<наименование платы>`: дополнительно проверяется, что установленная в слоте <slot> плата имеет указанное наименование. Если это не так, агент возвращает ошибку. |
| | 36 | - `type=<код типа платы>`: дополнительно проверяется, что установленная в слоте <slot> плата имеет указанный код типа. Если это не так, агент возвращает ошибку. |
| | 37 | - `format=<string|hex|array|auto>`: позволяет устранить неоднозначность формата возвращаемого значения. Так как во внутреннем протоколе обмена с платами отсутствует специальный тип "двоичные данные", для передачи двоичных данных используется тип "строка". Но, во-первых, произвольные двоичные данные не всегда представляют собой валидный код UTF-8, а во-вторых, даже если представляют, работать с таким представлением не очень удобно, т.к. трудно найти среди символов нужный двоичный байт. В запросе API можно было указать параметр `strings2data`, и тогда строки возвращаются в виде массива байт. В агенте Zabbix реализован другой механизм - если в строке есть хотя бы один непечатный символ, байты преобразуются в последовательность 16-ричных кодов, разделенных пробелами (примерно так, как это делает библиотека libsnmp).[[br]][[br]] Проблема в том, что получатель строки не всегда имеет возможность знать, получил ли он преобразованные в hex данные, или данные в таком виде и были отправлены непосредственно платой. Для устранения этой неоднозначности предлагается использовать параметр `format=`, который безусловно преобразует принятую из платы строку в заданный формат (к типам данных, отличным от строки, эти параметры не применяются). Предлагается реализовать следующие значения параметра: |
| 39 | | - `array` - полученная от платы строка возвращается в виде массива значений байтов, например имя платы SW-01 будет возвращено как `[83,87,45,48,49]`, такой формат удобен для последующей обработке javascript'ом на стороне сервера; |
| | 39 | - `array` - полученная от платы строка возвращается в виде массива значений байтов, например имя платы SW-01 будет возвращено как `[83,87,45,48,49]`, такой формат удобен для последующей обработки javascript'ом на стороне сервера; |
