3 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 будет повторять попытку до 5 раз для элементов данных SNMP walk и get. Механизм повторных попыток не применяется к сбоям разрешения DNS.

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

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

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

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

Чтобы начать мониторинг устройства через SNMP, необходимо выполнить следующие шаги:

Шаг 1

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

Для получения списка строк SNMP используйте команду snmpwalk (часть программного обеспечения net-snmp [en], которое вы должны были установить как часть инсталляции 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 является номером порта.

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

В последнем примере выше тип значения — «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 Описание
Имя контекста
(Context name)		 Введите имя контекста для идентификации элемента данных в SNMP подсети.
В данном поле раскрываются пользовательские макросы.
Имя безопасности
(Security name)		 Введите имя безопасности.
В данном поле раскрываются пользовательские макросы.
Уровень безопасности
(Security level)		 Выберете уровень безопасности:
noAuthNoPriv — ни аутентификация, ни протокол безопасности не используются
AuthNoPriv — используется протокол аутентификации, протокол безопасности — нет
AuthPriv — используются и протокол аутентификации, и протокол безопасности
Протокол аутентификации
(Authentication protocol)		 Выберете протокол аутентификации — MD5, SHA1; при использовании net-snmp 5.8 и более нового — SHA224, SHA256, SHA384 или SHA512.
Фраза-пароль аутентификации
(Authentication passphrase)		 Введите фразу-пароль для аутентификации
В данном поле раскрываются пользовательские макросы.
Протокол безопасности
(Privacy protocol)		 Введите протокол безопасности — DES, AES128, AES192, AES256, AES192C (Cisco) или AES256C (Cisco).
Смотрите примечания о поддержке протокола безопасности
Фраза-пароль безопасности
(Privacy passphrase)		 Введите фразу-пароль безопасности.
В данном поле раскрываются пользовательские макросы.

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

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

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

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

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

Поддержка протоколов конфиденциальности

В зависимости от вашей операционной системы и конфигурации 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) и может не быть установлен по умолчанию.

  1. snmpget:
snmpget -v 3 -x AES-256

Если вывод содержит Invalid privacy protocol specified after -3x flag: AES-256, поддержка AES192+ отсутствует. Если вывод содержит No hostname specified., поддержка AES192+ отсутствует.

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

Шаг 3

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

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

Заполните обязательные параметры в новой форме элемента данных:

Parameter Description
Name Введите имя элемента данных.
Type Выберите здесь SNMP agent.
Key Введите ключ, чтобы он был понятным.
Host interface Обязательно выберите SNMP-интерфейс, например вашего коммутатора/маршрутизатора.
SNMP OID Используйте один из поддерживаемых форматов для ввода значения(й) OID:

walk[OID1,OID2,...] - получить поддерево значений.
Например: walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3].
Этот вариант использует нативные SNMP bulk-запросы (GetBulkRequest-PDU) асинхронно.
Параметры тайм-аута для этого элемента данных можно задать в форме настройки элемента данных. Рекомендуется установить небольшое значение тайм-аута, чтобы избежать длительных задержек, если устройство недоступно, поскольку при истечении тайм-аута или сбое предыдущих попыток будет выполнено до 5 повторов (например, тайм-аут 3 секунды может привести к ожиданию в 15 секунд).
Вы можете использовать его как мастер-элемент данных, а зависимые элементы данных будут извлекать данные из мастер-элемента с помощью предварительной обработки.
Можно указать несколько OID в одном SNMP walk, например walk[OID1,OID2,...], чтобы асинхронно обрабатывать по одному OID за раз.
Если bulk-запрос не возвращает результатов, выполняется попытка получить одну запись без bulk-запроса.
В качестве параметров поддерживаются имена MIB; таким образом, walk[1.3.6.1.2.1.2.2.1.2] и walk[ifDescr] вернут одинаковый результат.
Если указано несколько OID/MIB, например walk[ifDescr,ifType,ifPhysAddress], то результатом будет объединенный список.
Запросы GetBulk используются с интерфейсами SNMPv2 и v3, а GetNext - с интерфейсами SNMPv1; максимальное число повторений для bulk-запросов настраивается на уровне интерфейса.
Параметр max repetitions влияет на bulk-запросы, определяя максимальное число OID, возвращаемых в одном bulk-ответе.
Большее значение приводит к более крупным bulk-ответам, уменьшая число необходимых передач. Однако не все устройства могут поддерживать очень высокие значения, что может вызвать проблемы.
Этот элемент данных возвращает вывод утилиты snmpwalk с параметрами -Oe -Ot -On.
Вы можете использовать этот элемент данных как мастер-элемент в SNMP discovery.

get[OID] - асинхронно получить одно значение.
Например: get[1.3.6.1.2.1.31.1.1.1.6.3]
Параметры тайм-аута для этого элемента данных можно задать в форме настройки элемента данных. Рекомендуется установить небольшое значение тайм-аута, чтобы избежать длительных задержек, если устройство недоступно, поскольку при истечении тайм-аута или сбое предыдущих попыток будет выполнено до 5 повторов (например, тайм-аут 3 секунды может привести к ожиданию в 15 секунд).

OID - (устаревший вариант) введите один текстовый или числовой OID для синхронного получения одного значения, при необходимости в сочетании с другими значениями.
Например: 1.3.6.1.2.1.31.1.1.1.6.3.
Для этого варианта время ожидания проверки элемента данных будет равно значению, заданному в файле конфигурации сервера.

Рекомендуется использовать элементы данных walk[OID] и get[OID] для лучшей производительности. Все элементы данных walk[OID] и get[OID] выполняются асинхронно - не требуется получать ответ на один запрос до начала других проверок. Разрешение DNS также выполняется асинхронно.
Максимальная параллельность асинхронных проверок составляет 1000 (определяется параметром MaxConcurrentChecksPerPoller). Количество асинхронных SNMP-опросчиков определяется параметром StartSNMPPollers.

Обратите внимание, что для статистики сетевого трафика, возвращаемой любым из методов, на вкладке Предварительная обработка необходимо добавить шаг Изменение в секунду; в противном случае вы получите накопительное значение от 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:

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

Пример 2

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

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

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

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

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

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

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

Для SNMP bulk-элементов данных будет выполнено до пяти повторных попыток, чтобы избежать сбоя, если один из пакетов будет потерян. Таймаут для SNMP-элементов данных с get и walk (задается в форме настройки элемента данных) устанавливается на всю сессию. Таймаут применяется независимо от того, были ли данные получены полностью; если данные получены частично (например, успешно собраны данные только для одного из нескольких OID), то элемент данных становится неподдерживаемым с сообщением "Only partial data received". Если таймаут истекает, будет выполнена повторная попытка, таймаут будет сброшен, и последний запрос будет отправлен снова, что позволит продолжить сессию с последнего запроса, если один пакет был потерян или пришел слишком поздно. Рекомендуется установить небольшое значение таймаута, чтобы избежать длительных задержек, если устройство недоступно, поскольку при истечении таймаута или сбое предыдущих попыток будет выполнено до 5 повторных попыток (например, таймаут 3 секунды может привести к ожиданию до 15 секунд).

Внутреннее устройство комбинированной обработки

Zabbix-сервер и прокси-сервер могут запрашивать у SNMP-устройств несколько значений в одном запросе. Это влияет на несколько типов элементов данных SNMP:

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

На нижнем уровне для запроса значений выполняются два вида операций: получение нескольких указанных объектов («получение данных», getting) и обход дерева OID («обход данных», walking).

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

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

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

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

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

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

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

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

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

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

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

Если объединённые запросы вызывают частичные или некорректные ответы, приводящие к некорректным посекундным (дельта) расчётам (например, к заметным скачкам показаний счётчиков интерфейсов), отключите функцию Использование объединённых запросов (Use combined requests) для затронутого интерфейса, чтобы принудительно выполнять отдельные запросы по элементам данных; это часто предотвращает ложные скачки. В качестве альтернативы рассмотрите возможность использования асинхронных элементов данных get[] или walk[], которые выполняются асинхронно и не подлежат комбинированию в соответствии с настройками интерфейса Использование объединённых запросов (Use combined requests) — их можно использовать вместо устаревших синхронных проверок OID, чтобы избежать проблем, связанных с объединёнными запросами. Найдите в журнале сервера/прокси записи, похожие на ту, что показана в разделе Обзор, чтобы помочь идентифицировать затронутые устройства.

Кроме того, если интерфейс часто становится недоступным, может потребоваться увеличить параметр UnavailableDelay в файлах конфигурации Zabbix-сервера или Zabbix-прокси, чтобы уменьшить частоту запросов. Элементы могут перестать поддерживаться, если во время обнаружения или проверки OID получены частичные данные.