2. SNMP агент

Обзор

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

Zabbix кэширует сопоставления SNMPv3 EngineID → IP и повторно использует кэшированные EngineID для последующих проверок вместо отправки probe каждый раз, уменьшая сетевой трафик. Если EngineID не может быть использован повторно, будет выполнена повторная попытка с probe для обнаружения нового EngineID.

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

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

Шаг 1

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

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

snmpwalk -v 2c -c public <host IP> .

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

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

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

IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

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

snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

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

Это должно дать вам что-то вроде следующего:

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

И снова, последнее число в OID — это номер порта.

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

В последнем примере выше тип значения — "Counter64", что внутренне соответствует типу 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. Эти типы приблизительно соответствуют "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" в выводе snmpget, но также могут отображаться как "STRING", "Hex-STRING", "OID" и другие, в зависимости от наличия display hint.

Шаг 2

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

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

  • Введите IP-адрес/DNS-имя и номер порта.
  • Выберите версию SNMP из выпадающего списка.
  • Добавьте учетные данные интерфейса в зависимости от выбранной версии SNMP:
    • Для SNMPv1, v2 требуется только community (обычно 'public').
    • Для SNMPv3 требуются более специфические параметры (см. ниже).
  • Укажите значение максимального повторения (по умолчанию: 10) для собственных SNMP bulk-запросов (GetBulkRequest-PDUs); только для элементов данных discovery[] и walk[] в SNMPv2 и v3. Обратите внимание, что установка слишком высокого значения может привести к тайм-ауту проверки SNMP-агента.
  • Установите флажок Использовать комбинированные запросы, чтобы разрешить комбинированную обработку SNMP-запросов (не относится к собственным SNMP bulk-запросам "walk" и "get").
Параметр SNMPv3 Описание
Имя контекста Введите имя контекста для идентификации элемента данных в подсети SNMP.
Пользовательские макросы разрешаются в этом поле.
Имя безопасности Введите имя безопасности.
Пользовательские макросы разрешаются в этом поле.
Уровень безопасности Выберите уровень безопасности:
noAuthNoPriv - не используются ни протоколы аутентификации, ни протоколы приватности
AuthNoPriv - используется протокол аутентификации, протокол приватности не используется
AuthPriv - используются и протоколы аутентификации, и протоколы приватности
Протокол аутентификации Выберите протокол аутентификации - MD5, SHA1; с net-snmp 5.8 и новее также SHA224, SHA256, SHA384 или SHA512.
Парольная фраза аутентификации Введите парольную фразу аутентификации.
Пользовательские макросы разрешаются в этом поле.
Протокол приватности Выберите протокол приватности - DES, AES128, AES192, AES256, AES192C (Cisco) или AES256C (Cisco).
См. примечания о поддержке протокола приватности
Парольная фраза приватности Введите парольную фразу приватности.
Пользовательские макросы разрешаются в этом поле.

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

  • Zabbix получает ERROR от net-snmp, за исключением неверной парольной фразы приватности, в этом случае Zabbix получает ошибку TIMEOUT от net-snmp.
  • Доступность SNMP-интерфейса переключится на красный цвет (недоступен).

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

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

  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 и нажмите Items для SNMP-узла сети, который вы создали ранее. В зависимости от того, использовали ли вы шаблон при создании узла сети, у вас будет либо список SNMP-элементов данных, связанных с вашим узлом сети, либо просто пустой список. Мы будем исходить из того, что вы собираетесь создать элемент данных самостоятельно, используя информацию, которую вы только что получили с помощью snmpwalk и snmpget, поэтому нажмите Create item.

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

Параметр Описание
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-PDUs) асинхронно.
Настройки тайм-аута для этого элемента данных можно задать в форме конфигурации элемента данных. Рекомендуется установить небольшое значение тайм-аута, чтобы избежать длительных задержек, если устройство недоступно, так как будет выполнено до 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-запросов настраивается на уровне интерфейса.
Параметр максимального числа повторений влияет на bulk-запросы, определяя максимальное количество OID, возвращаемых в одном bulk-ответе.
Более высокое значение приводит к более крупным bulk-ответам, уменьшая количество необходимых передач. Однако не все устройства могут поддерживать очень высокие значения, что может вызвать проблемы.
Этот элемент данных возвращает вывод утилиты snmpwalk с параметрами -Oe -Ot -On.
Вы можете использовать этот элемент данных как мастер-элемент данных в SNMP-обнаружении.

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 poller задается параметром StartSNMPPollers.

Обратите внимание, что для статистики сетевого трафика, возвращаемой любым из методов, на вкладке Preprocessing необходимо добавить шаг Change per second; в противном случае вы получите накопительное значение с SNMP-устройства вместо последнего изменения.

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

Теперь сохраните элемент данных и перейдите в Monitoring > Latest data для ваших 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-PDUs), доступную в 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 элементов данных, тогда как правила низкоуровневого обнаружения, как и раньше, обрабатываются по отдельности.

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

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

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

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

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

Чтобы найти оптимальное количество объектов для запроса у конкретного устройства, Zabbix использует следующую стратегию. Сначала он действует осторожно и запрашивает 1 значение в одном запросе. Если это успешно, он запрашивает 2 значения в одном запросе. Если это снова успешно, он запрашивает 3 значения в одном запросе и продолжает аналогичным образом, умножая количество запрашиваемых объектов на 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", который позволяет отключить комбинированные запросы для этого устройства.

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

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