Это перевод страницы документации с английского языка. Помогите нам сделать его лучше.

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).

При мониторинге устройств по SNMPv3, убедитесь что msgAuthoritativeEngineID (также известное как snmpEngineID или "Engine ID") никогда не будет общим для двух и более устройств. Согласно RFC 2571 [en] (раздел 3.1.1.1), оно должно быть уникальным для каждого устройства.

RFC3414 требует, чтобы SNMPv3 устройства сохраняли свои значения engineBoots. Некоторые устройства не выполняют этого требования, что приводит к тому, что после перезагрузки их SNMP сообщения отбрасываются как устаревшие. В этой ситуации необходимо вручную очистить кэш SNMP на сервере / прокси (используя -R snmp_cache_reload), или же придётся перезапустить сервер / прокси.

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

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

Шаг 1

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

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

shell> 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':

shell> 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 является номером порта.

Некоторые из наиболее часто используемых SNMP OID'ов автоматически конвертируются Zabbix'ом в числовое представление.

В последнем примере выше тип значение "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 Описание
Имя контекста Введите контекстное имя для определения элемента данных в SNMP подсети.
Имя контекста поддерживается для SNMPv3 элементов данных с версии Zabbix 2.2.

В данном поле раскрываются пользовательские макросы.
Имя безопасности Введите имя безопасности.
В данном поле раскрываются пользовательские макросы.
Уровень безопасности Выберете уровень безопасности:
noAuthNoPriv - ни аутентификация, ни протокол безопасности не используются
AuthNoPriv - используется протокол аутентификации, протокол безопасности нет
AuthPriv - используются и протокол аутентификации, и протокол безопасности
Протокол аутентификации Выберете протокол аутентификации - MD5, SHA1, SHA224, SHA256, SHA384 или SHA512.
Фраза-пароль аутентификации Введите фразу-пароль для аутентификации
В данном поле раскрываются пользовательские макросы.
Протокол безопасности Введите протокол безопасности - DES, AES128, AES192, AES256, AES192C (Cisco) или AES256C (Cisco).
Фраза-пароль безопасности Введите фразу-пароль безопасности.
В данном поле раскрываются пользовательские макросы.

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

Изменения в Протокол аутентификации, Фраза-пароль аутентификации, Протокол безопасности или Фраза-пароль безопасности без изменения Имя безопасности вступят в силу только после ручной очистки кэша на сервере / прокси (используя -R snmp_cache_reload) или при перезапуске сервера/прокси. В случаях, когда Имя безопасности также меняется, все параметры будут обновлены немедленно.

Вы можете использовать один из поставляемых шаблонов 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 1.2.3.45.6.7.8.0 (или .1.2.3.45.6.7.8.0)
Ключ <Уникальная строка, которая используется как ссылка в триггерах>
Например, "my_param".

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

shell> snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0
Пример 2

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

Параметр Описание
OID MIB::sysUpTime.0
Ключ router.uptime
Тип информации Числовой (с плавающей точкой)
Единица измерения uptime
Множитель 0.01

Native SNMP bulk requests

The walk[OID1,OID2,...] item allows to use native SNMP functionality for bulk requests (GetBulkRequest-PDUs), available in SNMP versions 2/3.

A GetBulk request in SNMP executes multiple GetNext requests and returns the result in a single response. This may be used for regular SNMP items as well as for SNMP discovery to minimize network roundtrips.

The SNMP walk[OID1,OID2,...] item may be used as the master item that collects data in one request with dependent ityems that parse the response as needed using preprocessing.

Note that using native SNMP bulk requests is not related to the option of combining SNMP requests, which is Zabbix own way of combining multiple SNMP requests (see next section).

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

Начиная с версии 2.2.3, Zabbix сервер и прокси одним запросом опрашивают множество 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, у каждого интерфейса имеется настройка "Использовать массовые запросы", позволяющая отключить массовые запросы у этого устройства.