2 SNMP агент

Обзор

Возможно, Вы захотите использовать SNMP для мониторинга таких устройств как принтеры, сетевые коммутаторы, маршрутизаторы или ИБП, которые, как правило, поддерживают SNMP и на которых было бы непрактично пытаться устанавливать полноценные операционные системы и Zabbix агенты.

Чтобы была возможность получать данные, переданные SNMP агентами с этих устройств, Zabbix сервер должен быть изначально сконфигурирован с поддержкой SNMP.

SNMP проверки выполняются только через UDP протокол.

Zabbix серверы и прокси опрашивают устройства SNMP по несколько значений за один запрос. Такое поведение влияет на все виды элементов данных SNMP (обычные элементы данных SNMP, элементы данных с динамическими индексами, а также низкоуровневые SNMP обнаружения), и должно сделать работу SNMP более эффективной. Смотрите раздел массовой обработки для получения технической информации о том, как этот функционал работает изнутри. Также массовые запросы можно отключить у устройств, которые не способны обработать их должным образом, используя настройку "Использовать массовые запросы", доступную у каждого интерфейса.

Процессы Zabbix сервера и прокси запишут в журнал строки наподобие следующих в случае получения неправильного/искажённого SNMP ответа:

SNMP response from host "gateway" does not contain all of the requested variable bindings

Пока они не покрывают все возможные проблемные случаи, но они полезны для идентификации отдельных SNMP устройств, на которых массовую обработку нужно отключить.

Zabbix сервер / прокси всегда повторят запрос минимум один раз после неуспешной попытки: либо через механизм библиотеки SNMP, либо через внутренний механизм сбора множества значений за один запрос (bulk).

Настройка мониторинга по SNMP

Для начала мониторинга устройства по SNMP нужно выполнить следующие шаги:

Шаг 1

Узнайте строку SNMP (или OID) элемента данных, который вы хотите мониторить.

Для получения списка строк SNMP используйте команду snmpwalk (часть программного обеспечения net-snmp, которое вы должны были установить как часть инсталляции Zabbix) или эквивалентную утилиту:

snmpwalk -v 2c -c public <IP хоста> .

'2c' здесь означает версию SNMP, вы также можете заменить его на '1', чтобы использовать на устройстве SNMP версии 1.

Эта команда должна показать вам список SNMP строк и их последние значения. Если это не произойдет, то возможно, что SNMP 'community' отличается от стандартного 'public', в этом случае вам необходимо узнать это имя.

Вы можете пройтись по списку, пока не найдёте строку, которую вы хотите мониторить; например, если вы хотите мониторить количество входящих байт на 3 порту вашего коммутатора, вы могли бы использовать IF-MIB::ifInOctets.3 из этой строки:

IF-MIB::ifInOctets.3 = Counter32: 3409739121

Теперь вы можете воспользоваться командой snmpget, чтобы определить цифровой OID для 'IF-MIB::ifInOctets.3':

snmpget -v 2c -c public -On 10.62.1.22 IF-MIB::ifInOctets.3

Обратите внимание, что последнее число в строке - это номер порта, который вы ищите для мониторинга. Смотрите также: Динамические индексы.

Вывод команды покажет вам что-то наподобие этого:

.1.3.6.1.2.1.2.2.1.10.3 = Counter32: 3472126941

Опять же, последнее число в OID является номером порта.

В последнем примере выше тип значение "Counter32" (32-битный счетчик), что внутренне соответствует типу ASN_COUNTER. Полный список поддерживаемых типов ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR и ASN_OBJECT_ID (с версий 2.2.8, 2.4.3). Приведенные типы грубо соответствуют "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" в выводе утилиты snmpget, но могут также отображаться как "STRING", "Hex-STRING", "OID" и другие, в зависимости от наличия подсказки.

Шаг 2

Создайте узел сети, соответствующий устройству.

Добавьте к узлу сети SNMP интерфейс:

• Введите IP адрес/DNS имя и номер порта
• Выберите Версия SNMP из выпадающего списка
• Добавьте учётные данные к интерфейсу, в зависимости от выбранной версии SNMP:
  • SNMPv1, v2 требуют только community (обычно 'public')
  • SNMPv3 требует более специфичные опции (смотрите ниже)
• Оставьте выбранным Использовать массовые запросы, чтобы разрешить массовую обработку SNMP запросов

В случае некорректных учётных данных SNMPv3 (имя безопасности, протокол/фраза-пароль аутентификации, протокол безопасности):

• Zabbix получит ERROR от net-snmp, за исключением ошибочного значения Ключевая фраза безопасности, в этом случае Zabbix получит ошибку превышения ВРЕМЕНИ ОЖИДАНИЯ от net-snmp;
• (начиная с версии Zabbix 6.0.13) доступность интерфейса SNMP переключится на красный цвет (недоступно).

Вы можете использовать один из поставляемых шаблонов SNMP (Template SNMP Device и другие), которые автоматически добавят набор элементов данных. Однако, шаблон может быть несовместим с узлом сети. Нажмите на Добавить для сохранения узла сети.

Шаг 3

Создайте элемент данных для мониторинга.

Итак, вернитесь назад в Zabbix и нажмите на Элементы данных у ранее созданного SNMP узла сети. В зависимости от того, использовали ли вы шаблон при создании узла сети или нет, вы увидите или список элементов данных SNMP, связанных с вашим узлом сети, или попросту пустой список. Мы будем исходить из предположения, что вы собираетесь создать элемент данных самостоятельно, с помощью информации, которую вы только что собрали, используя snmpwalk или snmpget, так что нажмите на Создать элемент данных. В диалоге нового элемента данных:

• Введите имя элемента данных
• Измените поле 'Тип' на 'SNMP агент'
• Введите в поле 'Ключ' - что-то осмысленное, например, SNMP-InOctets-Bps.
• Убедитесь, что в поле 'Интерфейс узла сети' указан ваш коммутатор / роутер
• Введите в поле 'SNMP OID' текстовый или числовой OID, который вы получили ранее, например: .1.3.6.1.2.1.2.2.1.10.3
• Установите 'Тип информации' в значение равное Числовой (с плавающей точкой)
• Введите 'Интервал обновления' и период 'Хранения истории, ' если вы хотите чтобы значения параметров отличались от умолчаний
• На вкладке Предобработка добавьте шаг Изменение в секунду (важно, в противном случае вы будете получать с SNMP устройства накопленные значения вместо последнего изменения). Выберите пользовательский множитель, если желаете.

Все обязательные поля ввода отмечены красной звёздочкой.

Теперь сохраните элемент данных и перейдите в Мониторинг → Последние данные, чтобы увидеть ваши данные SNMP!

Пример 1

Общий пример:

Обратите внимание, что OID можно задать в числовом или строковом представлении. Тем не менее, в некоторых случаях строковый OID должен быть сконвертирован в числовое представление. Для этого можно использовать утилиту snmpget:

snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

Пример 2

Мониторинг времени работы:

Обработка массовых SNMP запросов

Начиная с версии 2.2.3, Zabbix сервер и прокси одним запросом опрашивают множество SNMP элементов данных. Такое поведение затрагивает следующие типы SNMP элементов данных:

• обычные SNMP элементы данных;
• SNMP элементы данных с динамическими индексами;
• правила низкоуровневого SNMP обнаружения.

Все элементы данных SNMP с одного интерфейса планируются на опрос в одно время. Первые два типа элементов данных собираются поллерами порциями не более чем по 128 элементов данных, в то время как правила низкоуровневого обнаружения обрабатываются индивидуально, как и ранее.

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

Для "получения" используется GetRequest-PDU c не более чем 128 привязанных переменных. Для "обхода" используется GetNextRequest-PDU для SNMPv1 и GetBulkRequest с полем "max-repetitions" с наибольшим количеством в 128 полученных значений для SNMPv2 и SNMPv3.

Таким образом, преимущества массовой обработки для каждого типа SNMP элемента данных описаны ниже:

• обычные SNMP элементы данных получают преимущество от улучшенного "получения";
• SNMP элементы данных с динамическими индексами получают преимущество и от улучшенного "получения" и "обхода": "получение" используется для проверки индексов, а "обход" для построения кэша значений;
• правила низкоуровневого SNMP обнаружения получают преимущество от улучшенного "обхода".

Тем не менее, есть техническая проблема: не все устройства способны вернуть 128 значений за один запрос. Некоторые всегда возвращают корректный ответ, но другие либо отвечают с ошибкой "tooBig(1)", либо не отвечают вообще, когда потенциальный запрос превышает определённый лимит.

Для вычисления оптимального количества объектов, запрашиваемых с данного устройства, Zabbix использует следующую стратегию. Начинается с осторожного запроса одного значения. Это запрос выполнен успешно, запрашивается 2 значения за один запрос. Если запрос снова выполнен успешно, запрашивается 3 значения за запрос и продолжается аналогично путём умножения количества запрашиваемых значений на 1.5, в результате получается следующая последовательность размера запросов: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

Однако, как только устройство отказывается давать корректный ответ (к примеру, на 42 переменных), Zabbix делает 2 вещи.

Во-первых, для текущей серии элементов данных Zabbix делит пополам количество объектов на один запрос и запрашивает 21 переменную. Если устройство доступно, то запрос должен работать в большинстве случаев, потому что было известно, что с 28 переменными работало, а 21 значительно меньше. Однако, если проблема продолжается, Zabbix возвращается к опросу значений по одному. Если проблемы есть и в этом случае, значит устройство определенно не отвечает и проблема не в размере запроса.

Вторая вещь, которую делает Zabbix для дальнейших порций элементов данных, - он начинает с последнего удачного количества переменных (28 в нашем случае) и продолжает, увеличивая количество переменных за запрос на 1 до достижения лимита. Например, предположим, что наибольший размер ответа -- это 32 переменных, тогда последующие запросы будут размерами 29, 30, 31, 32 и 33. Последний запрос будет неудачным, и Zabbix никогда более не запросит 33 значения за один запрос. С этого момента, Zabbix всегда будет опрашивать максимум по 32 переменных для этого устройства.

Если большие запросы неудачно завершаются с этим количеством переменных, это может означать одно из двух. Точный критерий, используемый устройством для ограничения размера ответа, неизвестен, но мы пытаемся приблизительно оценить это, используя количество переменных. Поэтому первая возможность - что в общем случае это количество переменных где-то около реального ограничения размера ответа для данного устройства: иногда ответ меньше этого предела, иногда больше. Вторая возможность - что UDP пакет (в любом направлении) просто был потерян. По этим причинам, если Zabbix сталкивается с неудачным запросом, то он уменьшает максимальное количество переменных, чтобы попытаться углубиться в комфортный для устройства диапазон, но (начиная с 2.2.8) только до 2 раз.

В примере выше, если запрос с 32 переменными будет неудачен, Zabbix уменьшит количество до 31. Если неудача случится снова, Zabbix уменьшит количество до 30. Тем не менее, Zabbix не будет уменьшать количество ниже 30, потому что он предположит, что дальнейшие проблемы по причине потерянных UDP пакетов, нежели из-за ограничения устройства.

Если, однако, устройство не умеет обрабатывать массовые запросы корректно и описанная выше эвристика не работает, то, начиная с Zabbix 2.4, у каждого интерфейса имеется настройка "Использовать массовые запросы", позволяющая отключить массовые запросы у этого устройства.