2. SNMP агент

Обзор

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

Чтобы была возможность получать данные, переданные SNMP агентами с этих устройств, Zabbix сервер должен быть изначально сконфигурирован с поддержкой SNMP путём указания флага --with-net-snmp. Также рекомендуется установить файлы MIB, чтобы гарантировать, что значения элементов данных отображаются в правильном формате. Без файлов MIB могут возникнуть проблемы с форматированием, такие как отображение значений в HEX вместо UTF-8.

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

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

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

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

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

Настройка мониторинга по 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::ifHCInOctets.3 = Counter64: 3409739121

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

snmpget -v 2c -c public -On <IP хоста> IF-MIB::ifHCInOctets.3

Обратите внимание, что последнее число в строке — это номер порта, который вы хотите отслеживать. Смотрите также: Динамические индексы.

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

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

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

В последнем примере выше тип значения — «Counter64» (64-битный счетчик), что внутренне соответствует типу ASN_COUNTER64. Полный список поддерживаемых типов: 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 требует более специфичные опции (смотрите ниже)
• Укажите значение максимального количества повторений (по умолчанию: 10) для собственных массовых запросов SNMP (bulk requests) (GetBulkRequest-PDUs); только для элементов данных discovery[] и walk[] в SNMPv2 и v3. Обратите внимание, что установка слишком большого значения может привести к тайм-ауту проверки агента SNMP.
• Оставьте выбранным Использование объединённых запросов, чтобы разрешить объединённую обработку SNMP запросов (не относится к собственным массовым запросам (bulk requests) SNMP «walk» и «get»)

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

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

Нажмите на Добавить для сохранения узла сети.

Поддержка протокола безопасности

В зависимости от вашей операционной системы и конфигурации net-snmp некоторые протоколы безопасности могут быть недоступны:

• В некоторых новых операционных системах (например, RHEL9) поддержка DES для пакета net-snmp прекращена.

• Протоколы шифрования AES192 и более сильные не поддерживаются из коробки в операционных системах более старых, чем RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.

Чтобы проверить, поддерживает ли библиотека net-snmp AES192+, используйте один из следующих способов:

1. net-snmp-config:

   net-snmp-config --configure-options

Если вывод содержит --enable-blumenthal-aes, AES192+ поддерживается.

Обратите внимание, что net-snmp-config является частью пакета разработки для SNMP (libsnmp-dev для Debian/Ubuntu, net-snmp-devel для CentOS/RHEL/OL/SUSE) и может быть не установлен по умолчанию.

2. snmpget:

   snmpget -v 3 -x AES-256

Если вывод содержит «Invalid privacy protocol specified after -3x flag: AES-256» («Недопустимый протокол безопасности, указанный после флага -3x: AES-256»), AES192+ не поддерживается. Если вывод содержит «No hostname specified.» («Не указано имя хоста.»), AES192+ не поддерживается.

Если ваша библиотека net-snmp не поддерживает протоколы AES192 и выше, перекомпилируйте net-snmp с параметром --enable-blumenthal-aes, затем перекомпилируйте сервер Zabbix, указав параметр --with-net-snmp=/home/user/вашсобственныйnetsnmp/bin/net-snmp-config.

Шаг 3

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

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

Заполните требуемые параметры в диалоге нового элемента данных:

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

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

Пример 1

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

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

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

Пример 2

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

Собственные массовые запросы SNMP

Элемент данных walk[OID1,OID2,...] позволяет использовать собственные функции SNMP для массовых запросов (GetBulkRequest-PDU), доступные в версиях SNMP 2/3.

Запрос GetBulk в SNMP выполняет несколько запросов GetNext и возвращает результат в одном ответе. Это может использоваться для обычных элементов данных SNMP, а также для обнаружения SNMP, чтобы свести к минимуму использование сети.

Элемент данных SNMP walk[OID1,OID2,...] может использоваться как основной элемент данных, который собирает данные за один запрос, с зависимыми элементами данных, которые с помощью предобработки разбирают ответ как нужно.

Обратите внимание, что использование собственных массовых запросов SNMP не связано с возможностью объединения запросов SNMP, которая является собственным способом Zabbix объединения нескольких запросов SNMP (смотрите следующий раздел).

Для массовых данных элементов SNMP будет выполнена повторная попытка, чтобы избежать сбоя, если один из пакетов будет потерян. Тайм-аут для элементов данных SNMP с get и walk устанавливается для всей сессии. Если тайм-аут достигнут, то будет предпринята ещё одна попытка, тайм-аут будет сброшен, и последний запрос будет отправлен повторно, что позволит продолжить сессию с последнего запроса, если один пакет потерян или прибыл слишком поздно.

Внутренняя обработка объединённых запросов

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 раз.

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

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