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, которое должно быть установлено вместе с Zabbix) или аналогичный инструмент:

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

Поскольку 2c здесь обозначает версию SNMP, вы также можете заменить его на 1, чтобы указать на устройстве SNMP Version 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

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

Это должно дать вам примерно следующее:

.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-интерфейс для узла сети:

  1. Введите IP-адрес/DNS-имя и номер порта.
  2. Выберите версию SNMP в раскрывающемся списке.
  3. Добавьте учетные данные интерфейса в зависимости от выбранной версии SNMP:
    • SNMPv1, v2 требуют только community (обычно 'public').
    • SNMPv3 требует более специфичных параметров; см. SNMPv3.
  4. Укажите максимальное значение повторений (по умолчанию: 10) для нативных SNMP bulk-запросов (GetBulkRequest-PDU); только для элементов данных discovery[] и walk[] в SNMPv2 и v3. Обратите внимание, что слишком большое значение может привести к тайм-ауту проверки SNMP-агента.
  5. Отметьте флажок Use combined requests, чтобы разрешить совместную обработку SNMP-запросов (не относится к нативным SNMP bulk-запросам "walk" и "get").

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

Нажмите Add, чтобы сохранить узел сети.

SNMPv3

Для 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 (security name, authentication protocol/passphrase, privacy protocol):

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

Изменения в Authentication protocol, Authentication passphrase, Privacy protocol или Privacy passphrase, внесенные без изменения Security name, обычно применяются автоматически при обновлении соответствующего SNMPv3-интерфейса в Zabbix. Если также изменяется Security name, все параметры будут обновлены немедленно.

Вы можете использовать один из предоставленных шаблонов 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. Для этого нажмите Создать элемент данных.

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

Параметр Описание
Имя Введите имя элемента данных.
Тип Выберите здесь SNMP-агент.
Ключ Введите содержательный ключ.
Интерфейс узла сети Убедитесь, что выбран 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 (GetBulkRequest-PDU) в асинхронном режиме.
Параметры времени ожидания для этого элемента данных можно задать в форме настройки элемента данных. Рекомендуется задать небольшое значение времени ожидания, чтобы избежать длительных задержек, если устройство недоступно, поскольку при истечении времени ожидания или сбое предыдущих попыток будет выполнено до 5 повторных попыток (например, время ожидания 3 секунды может привести к ожиданию в течение 15 секунд).
Этот элемент данных можно использовать как главный элемент данных, а зависимые элементы данных могут извлекать из него данные с помощью предварительной обработки.
В одном обходе SNMP можно указать несколько OID, например walk[OID1,OID2,...], чтобы обрабатывать по одному OID за раз в асинхронном режиме.
Если массовый запрос не возвращает результатов, предпринимается попытка получить одну запись без массового запроса.
В качестве параметров поддерживаются имена MIB, поэтому walk[1.3.6.1.2.1.2.2.1.2] и walk[ifDescr] вернут одинаковый результат.
Если указано несколько OID/MIB, например walk[ifDescr,ifType,ifPhysAddress], результатом будет объединенный список.
Запросы GetBulk используются с интерфейсами SNMPv2 и SNMPv3, а для интерфейсов SNMPv1 используется GetNext; максимальное количество повторений для массовых запросов настраивается на уровне интерфейса.
Параметр максимального количества повторений определяет максимальное число OID, возвращаемых в одном массовом ответе.
Большее значение приводит к увеличению размера массовых ответов и уменьшает количество необходимых передач. Однако не все устройства поддерживают очень большие значения, что может привести к проблемам.
Этот элемент данных возвращает результат работы утилиты 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 определяется параметром 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

Элемент данных 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 (задается в форме настройки элемента данных) устанавливается для всего сеанса. Тайм-аут применяется независимо от того, получены ли данные полностью; если данные получены частично (например, данные успешно собраны только для одного из нескольких OID), элемент данных становится неподдерживаемым с сообщением «Получены только частичные данные». Если тайм-аут истек, будет выполнена повторная попытка, тайм-аут сбросится, а последний запрос будет отправлен повторно. Это позволит сеансу продолжиться с последнего запроса, если один пакет потерян или поступил слишком поздно. Рекомендуется установить небольшое значение тайм-аута, чтобы избежать длительных задержек, если устройство недоступно, поскольку при истечении тайм-аута или сбое предыдущих попыток будет выполнено до 5 повторных попыток (например, тайм-аут в 3 секунды может привести к ожиданию в течение 15 секунд).

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

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

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

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

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

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

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

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

Чтобы определить оптимальное количество объектов для запроса у конкретного устройства, 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-пакетов, а не ограничением устройства.

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

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

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