== Введение == [http://www.zabbix.com/ Zabbix] - популярная система мониторинга параметров сетевого оборудования. Эта статья содержит информацию об использовании агента Zabbix, встроенного в плату SW-01, для мониторинга аппаратуры. '''Агент Zabbix''' - это программа, выполняющаяся на наблюдаемом объекте и выполняющая непосредственно сбор и передачу на сервер наблюдаемых параметров. Zabbix поддерживает два типа агента - пассивный агент и активный агент. '''Пассивный агент''' не отправляет данные по собственной инициативе, вместо этого он ожидает запросов от сервера. Когда Zabbix серверу требуется получить данные с объекта (произвести опрос), на котором работает пассивный агент, сервер устанавливает соединение с агентом и запрашивает у него нужный ему параметр, передавая ключ параметра. Агент выполняет чтение запрошенного параметра из аппаратуры и возвращает серверу прочитанную величину. Опрос данных сервером производится с заданной периодичностью. '''Активный агент''', в отличие от пассивного, не принимает входящих соединений от сервера, вместо этого он сам по своей инициативе соединяется с сервером. Преимуществом такого подхода является то, что активный агент может инициативно передать серверу новое значение наблюдаемого параметра сразу после изменения его значения (например при появлении или пропадании аварийного состояния), не дожидаясь наступления запланированного времени очередного опроса. Это позволяет серверу не пропускать возникающие в наблюдаемом оборудовании события и быстрее на них реагировать. Также активный агент позволяет автоматически регистрировать новые устройства на сервере и начинать их мониторинг без каких-либо действий с сервером. == Принцип работы Zabbix агента == В плате SW-01 реализован активный агент Zabbix. При старте агент соединяется с сервером Zabbix и запрашивает у него список элементов данных (параметров), которые сервер желает наблюдать. В дальнейшем такие запросы агент повторяет периодически (каждые 5 минут) для обновления списка в случае изменения его на сервере. Для каждого из наблюдаемых параметров сервер устанавливает период опроса. Для уменьшения служебного трафика в сети агент группирует параметры, имеющие одинаковый период опроса, и передает их значения на сервер единым списком (в одном TCP соединении). При возникновении события, каковым является получение от установленной в блоке платы спорадического сообщения о возникновении или пропадании аварии или изменение состояния общей аварии платы, агент производит поиск аварии в полученном от сервера списке наблюдаемых параметров. Если соответствующий аварии параметр присутствует в списке, агент немедленно оповещает сервер о возникшем событии (передает ему новое значение параметра) независимо от наступления времени очередного опроса. == Конфигурация сервера == Добавьте сетевой узел в сервер Zabbix в соответствии с руководством Zabbix. Добавьте узлу сети необходимые элементы данных с типом "Zabbix агент (активный)" в соответствии с руководством Zabbix. Ключ элемента данных установить в соответствии с описанием ниже. Также можно воспользоваться готовым [[attachment:zbx_template_mc04-dsl-3u-agent.zip|шаблоном]]. === Ключи элементов данных === Каждый элемент данных (наблюдаемый сервером параметр, матрика) идентифицируется ключом. Агент Zabbix платы SW-01 требует, чтобы запрашиваемые ключи соответствовали конкретному формату. Агент поддерживает два формата ключей: `MCv2.<функция>[<параметры>]` `MC04.<тип объекта>.<функция>.<дополнительные элементы>[<параметры>]` В настоящее время рекомендуется использовать формат, начинающийся с `MCv2`. Формат, начинающийся с `MC04`, использовался в более ранних версиях агента (и с ранними версиями Zabbix, в которых отсутствовала развитая пред-обработка значений и вложенное низкоуровневое обнаружение) и продолжает поддерживаться для совместимости с уже эксплуатируемыми системами мониторинга. Далее следует описание ключей формата `MCv2`, ключи формата `MC04` описаны в конце раздела. Ключи формата `MCv2` после префикса `MCv2.`, служащего для идентификации формата ключа, содержат ключевое слово, обозначающее выполняемую функцию, за которым следуют заключенные в квадратные скобки параметры. Параметры разделяются запятыми и могут быть позиционными или именными. Именной параметр отличается от позиционного тем, что имеет формат `<имя параметра>=<значение>` и опознается агентом по наличию символа `=`. Позиционный параметр не содержит символа `=`, а его семантика определяется позицией параметра в списке. Обратите внимание, что именные параметры не учитываются при анализе позиционных параметров и могут находиться в любом месте. Например следующие ключи эквивалентны: - `MCv2.function[первый, второй, третий, foo=bar, moo=var]`; - `MCv2.function[foo=bar, moo=var, первый, второй, третий]`; - `MCv2.function[первый, foo=bar, второй, moo=var, третий]`. Также обратите внимание, что параметры между собой могут разделяться любым количеством пробелов, однако в именных параметрах пробелы перед и после символа `=` недопустимы. Ключи формата `MCv2` могут иметь следующие функции: - getvar; - substr; - boardlist. ==== Функция `getvar` ==== Функция `getvar` возвращает переменную платы блока MC04-DSL-3U. //__Позиционные параметры__:// Функция требует наличия в ключе следующих позиционных параметров: `[, ]`, где `` - номер слота блока, в котором установлена плата, `` - OID переменной платы. Например ключ `MCv2.getvar[3, .2.0]` вернет значение переменной `.2.0` платы в слоте 3 (текстовое наименование платы). //__Именные параметры__// `name=<наименование платы>`:: Значение переменной возвращается только при условии совпадения имени платы с указанным значением параметра. В процессе эксплуатации аппаратуры состав и расположение установленных в блоке плат может меняться. Возможна ситуация, когда в слот, где ранее была установлена и мониторилась плата одного типа, будет установлена плата другого типа, при этом новая плата может иметь переменную с тем же OID, что и ранее установленная, но значение этой переменной может иметь совершенно иную семантику. Такая ситуация приведет к тому, что система мониторинга будет получать и неверно интерпретировать значение переменных новой платы. Параметр `name` решает эту проблему: в случае, если наименование платы не совпадает с указанным в параметре `name` ключа, агент Zabbix вернет ошибку "not found". `format=`:: Параметр позволяет устранить неоднозначность формата возвращаемого значения. Так как у плат блока MC04-DSL-3U отсутствует специальный тип для двоичных данных, для этих целей используется тип "строка". Как результат, при получении значения типа строка возникает неоднозначность - интерпретировать ли значение как текстовую строку или как двоичные данные (массив байт). По умолчанию (без указания параметра `format`) агент Zabbix принимает решение, анализируя полученное значение (подобно тому как это происходит в распространенных агентах SNMP): если в полученном значении присутствуют "непечатные" символы (байты с кодами меньше 32), то значение передается серверу Zabbix в формате HEX: как последовательность пар шестнадцатеричных цифр разделенных пробелами (например `23 fc 2b 02 00 e3 56`). В противном случае (если "непечатные" символы не обнаружены) значение передается серверу как текстовая строка (string). Указание параметра `format` позволяет однозначно задать формат, в котором агент будет передавать серверу значение переменной. Дополнительно у описанным выше форматам можно указать формат `array` - в этом случае значение переменной будет передано как JSON массив десятичных значений байтов (например `[35, 215, 41, 2, 0, 198, 4]`). Формат "array" удобен для пред-обработки значения сервером Zabbix с помощью JSONPath или !JavaScript. Обратите внимание, что при использовании параметра `format=string` текстовая строка может оказаться невалидной (например если в значении содержатся нулевые байты), в результате чего невалидным может оказаться JSON объект, передаваемый агентом серверу, что приведет к потере значения не только данного элемента, но и других, передаваемых агентом в том же сообщении. ==== Функция `substr` ==== //__Позиционные параметры__:// Функция требует наличия в ключе следующих позиционных параметров: `[, , , ]`. Функция `substr` полностью аналогична функции `getvar` за исключением того, что в случае когда запрошенная переменная имеет тип "строка", агент возвращает подстроку, начинающуюся с позиции `` и содержащую `` байт. Например ключ `MCv2.substr[3, .7.6.5.0, 9, 5, format=array]` вернет значения 5 байт начиная с позиции 9 значения переменной .7.6.5.0 платы в слоте 3 в формате JSON массива (предполагается что переменная имеет тип "строка"). Эта функция полезна в случаях, когда состояние множества элементов платы (например портов или каналов) содержится в одной общей переменной, содержащей один большой массив байт. //__Именные параметры__// Все именные параметры аналогичны функции `getvar`. ==== Функция `boardlist` ==== Функция служит для низкоуровневого обнаружения (LLD) плат в блоке и возвращает список плат блока в формате JSON объекта. Функция не имеет параметров. ==== Описание ключей формата `MC04`==== ||='''Формат'''=||='''Пример'''=||='''Поддерживается начиная с ревизии'''=||='''Описание'''=|| ||MC04..snmp[]||MC04.E1-08.snmp.3.0![5]|| sw-r1327 ||Возвращает значение переменной платы в слоте c OID || ||MC04..nthbyte[,]||MC04.E1-08.nthbyte.9.0![2,3]|| sw-r1367 ||Возвращает значение n-ного байта переменной типа "строка" платы в слоте c OID || ||MC04..hwordat[,]||MC04.MS-01.hwordat.6.0![8,0]|| sw-r1376 ||Возвращает значение 16-битного little-endian слова (half-word), находящегося по смещению в переменной типа "строка" с OID платы в слоте || ||MC04..hwordat-be[,]||MC04.MS-01.hwordat-be.6.0![8,0]|| sw-r1376 ||Возвращает значение 16-битного big-endian слова (half-word), находящегося по смещению в переменной типа "строка" с OID платы в слоте || ||MC04..wordat[,]||MC04.MS-01.wordat.6.0![8,0]|| sw-r1372 ||Возвращает значение 32-битного little-endian слова, находящегося по смещению в переменной типа "строка" с OID платы в слоте || ||MC04..wordat-be[,]||MC04.MS-01.wordat-be.6.0![8,0]|| sw-r1372 ||Возвращает значение 32-битного big-endian слова, находящегося по смещению в переменной типа "строка" с OID платы в слоте || ||MC04.sys.boardlist[]||MC04.sys.boardlist![0]|| sw-r1374 ||Возвращает список плат типа в виде json-объекта. Используется для низкоуровневого обнаружения плат. - код типа запрашиваемой платы. Если равен нулю, возвращается список всех установленных плат.|| ||MC04.sys.ethstat[

,]||MC04.sys.ethstat![8,0]|| sw-r1370 ||Возвращает значение счетчика ^2^ порта

^1^ коммутатора ethernet платы SW-01|| ||MC04.SW-01.readsfp[]||MC04.SW-01.readsfp![10]|| sw-r1845 ||Возвращает данные, прочитанные из внутренней памяти модуля SFP платы SW-01, установленной в слоте . Данные возвращаются в виде JSON-массива, содержащего 512 элементов. Первая половина массива - 256 байт, прочитанные с адреса A0h (идентификация модуля), вторая половина массива - 256 байт, прочитанные с адреса A2h (измерения и диагностика).|| ^1^ Номер порта ethernet может принимать значение от 0 до 10. Порты 0-7 - межплатные соединения в блоке, порты 8 и 9 - внешние интерфейсы "eth1" и "eth2" соответственно, порт 10 - внутренний порт центрального процессора платы. ^2^ Описание доступных счетчиков портов ethernet приведено в следующей таблице. ||='''Номер счетчика'''=||='''Наименование'''=||='''Разрядность'''=||='''Описание'''=|| ||||||||=порты 0-9=|| || 0 ||Good Octets Rx|| 64 ||Сумма длин всех успешно (без ошибок) принятых ethernet фреймов за исключением управляющих фреймов MAC (например pause frame).|| || 2 ||Bad Octets Rx|| 32 ||Сумма длин всех фреймов, принятых с ошибками.|| || 3 ||Tx error|| 32 ||Опустошение буфера при передаче (underrun), фрейм с плохой CRC прочитан из памяти.|| || 4 ||Good Unicast Frames Rx|| 32 ||Число принятых без ошибок уникастовых фреймов.|| || 5 ||Sent Deferred|| 32 ||Фрейм был передан в полудуплексное соединение без коллизии, но передача была отложена из-за занятости среды.|| || 6 ||Good Broadcast Frames Rx|| 32 ||Число принятых без ошибок широковещательных фреймов.|| || 7 ||Good Multicast Frames Rx|| 32 ||Число принятых без ошибок мультикастовых фреймов. Не включает управляющие фреймы.|| || 14 ||Good Octets Sent|| 64 ||Сумма длин всех переданных фреймов.|| || 16 ||Unicast Frames Sent|| 32 ||Число переданных уникастовых фреймов.|| || 17 ||Excessive Collision|| 32 ||Число фреймов, отброшенных при передаче в полудуплексное соединение из-за коллизий.|| || 18 ||Multicast Frames Sent|| 32 ||Число переданных мультикастовых фреймов. Не включает управляющие фреймы.|| || 19 ||Broadcast Frames Sent|| 32 ||Число переданных широковещательных фреймов.|| || 20 ||Sent Multiple|| 32 ||Число фреймов, переданных в полудуплексное соединение, в процессе передачи которых возникло более одной коллизии.|| || 21 ||FC Sent|| 32 ||Число переданных фреймов управления потоком (Flow-Control).|| || 22 ||FC Rx|| 32 ||Число принятых фреймов управления потоком (Flow-Control).|| || 23 ||Receive FIFO Overrun|| 32 ||Ошибки приема фрейма из-за недостаточной пропускной способности внутренних ресурсов коммутатора (например выделения буферов ОЗУ).|| || 24 ||Undersize|| 32 ||Число принятых фреймов короче допустимой длины.|| || 25 ||Fragments|| 32 ||Число принятых фрагментов фреймов.|| || 26 ||Oversize|| 32 ||Число принятых фреймов, превышающих допустимый размер.|| || 27 ||Jabber|| 32 ||Число принятых jabber пакетов.|| || 28 ||!RxError Frame Rx|| 32 ||Число ошибок приема, обнаруженных приемной частью MAC.|| || 29 ||Bad CRC|| 32 ||Число принятых фреймов с неверной CRC.|| || 30 ||Collisions|| 32 ||Число коллизий.|| || 31 ||Late Collisions|| 32 ||Число поздних коллизий.|| ||||||||=порт 10=|| || 0 ||Good Octets Rx|| 32 ||Сумма длин всех успешно (без ошибок) принятых ethernet фреймов за исключением управляющих фреймов MAC (например pause frame).|| || 2 ||Bad Octets Rx|| 16 ||Сумма длин всех фреймов, принятых с ошибками.|| || 3 ||MAC Tx Error|| 16 ||Число фреймов, не преданных в результате внутренней ошибки MAC (например опустошения буфера).|| || 4 ||Good Frames Rx|| 16 ||Число принятых без ошибок фреймов.|| || 14 ||Good Octets Sent|| 32 ||Сумма длин всех успешно (без ошибок) принятых ethernet фреймов за исключением управляющих фреймов MAC (например pause frame).|| || 16 ||Good Frames Sent|| 32 ||Число всех успешно (без ошибок) переданных фреймов за исключением управляющих фреймов MAC (например pause frame).|| || 23 ||Internal Drop Rx|| 16 ||Число принятых без ошибок фреймов, отброшенных в результате внутренних заторов.|| || 29 ||Bad Frames Rx|| 16 ||Число принятых c ошибками фреймов.|| == Конфигурация агента == Конфигурация агента Zabbix производится через веб-интерфейс. Агент может работать с несколькими серверами Zabbix. Список серверов отображается в таблице на вкладке "Мониторинг" в виде записей с типом "Zabbix" (совместно с типами мониторинга ИСУМ и SNMP). Для добавления сервера Zabbix необходимо нажать кнопку "Добавить систему мониторинга" на вкладке "Мониторинг", в появившемся диалоге выбора типа мониторинга выбрать "Zabbix агент (активный)" и нажать "OK". [[Image(wiki:ZabbixAgent:agent-1.jpg)]] В появившемся диалоге конфигурации Zabbix-сервера необходимо ввести имя создаваемой записи (произвольная строка, которая не должна совпадать с уже имеющимися в таблице систем мониторинга), адрес сервера (имя хоста или IP адрес, на котором работает сервер Zabbix), имя блока (имя узла сети, присвоенное данному блоку на сервере Zabbix). Затем в строке "Подключение" выбрать желаемый вариант шифрования и (при необходимости) ввести нужный ключ. После ввода перечисленных параметров нажмите "OK", сервер будет добавлен в таблицу систем мониторинга (в неактивном состоянии). [[Image(wiki:ZabbixAgent:agent-2.jpg)]] Для активации мониторинга необходимо установить чекбокс в колонке "Активен" в строке сервера Zabbix.