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) либо перезапустить сервер/прокси.

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

Шаг 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. Отметьте флажок Использовать объединенные запросы, чтобы разрешить объединенную обработку SNMP-запросов (не относится к нативным SNMP bulk-запросам "walk" и "get").

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

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

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, все параметры будут обновлены немедленно.

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

В зависимости от вашей операционной системы и конфигурации 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, поэтому нажмите Создать элемент данных.

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

Параметр Описание
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].
Этот вариант использует нативные bulk-запросы SNMP (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-элементы данных на одном интерфейсе с одинаковыми параметрами планируются к опросу одновременно. Первые два типа элементов данных опрашиваются poller'ами пакетами не более чем по 128 элементов, тогда как правила низкоуровневого обнаружения обрабатываются по одному, как и раньше.

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

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

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

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

Однако существует техническая проблема: не все устройства способны возвращать 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 получены неполные данные.