Documentation
Table of Contents
2. SNMP агент
Обзор
Возможно, Вы захотите использовать SNMP для мониторинга таких устройств как принтеры, сетевые коммутаторы, маршрутизаторы или ИБП, которые, как правило, поддерживают SNMP и на которых было бы непрактично пытаться устанавливать полноценные операционные системы и Zabbix агенты.
Чтобы была возможность получать данные, переданные SNMP агентами с этих устройств, Zabbix сервер должен быть изначально сконфигурирован с поддержкой SNMP путём указания флага --with-net-snmp. Также рекомендуется установить файлы MIB, чтобы гарантировать, что значения элементов данных отображаются в правильном формате. Без файлов MIB могут возникнуть проблемы с форматированием, такие как отображение значений в HEX вместо UTF-8 либо наоборот.
SNMP проверки выполняются только по протоколу UDP.
В случае получения неправильного/искажённого SNMP ответа демоны Zabbix сервера и прокси записывают в журнал строки наподобие следующих :
Хотя они не покрывают все возможные проблемные случаи, но они полезны для идентификации отдельных SNMP устройств, на которых массовую обработку запросов нужно отключить.
Zabbix сервер/прокси всегда повторит запрос минимум один раз после неуспешной попытки: либо через механизм библиотеки SNMP, либо через внутренний механизм сбора множества значений за один запрос (combined processing).
При мониторинге устройств по SNMPv3 убедитесь,http://www.ietf.org/rfc/rfc2571.txt) что 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 [en], которое вы должны были установить как часть инсталляции Zabbix) или эквивалентную утилиту:
«2c» здесь означает версию SNMP, вы также можете заменить его на «1», чтобы использовать на устройстве SNMP версии 1.
Эта команда должна показать вам список SNMP строк и их последние значения. Если это не произойдёт, то возможно, что SNMP «community» отличается от стандартного «public», в этом случае вам необходимо узнать это имя.
Вы можете пройтись по списку, пока не найдёте строку, которую вы хотите отслеживать; например, если вы хотите мониторить количество входящих байт на 3 порту вашего коммутатора, вы могли бы использовать IF-MIB::ifInOctets.3 из этой строки:
Теперь вы можете воспользоваться командой snmpget, чтобы определить цифровой OID для «IF-MIB::ifInOctets.3»:
Обратите внимание, что последнее число в строке — это номер порта, который вы хотите отслеживать. Смотрите также: Динамические индексы.
Вывод команды покажет вам что-то наподобие этого:
Опять же, последнее число в 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+, используйте один из следующих способов:
net-snmp-config:
Если вывод содержит --enable-blumenthal-aes, то AES192+ поддерживается.
Обратите внимание, что net-snmp-config является частью пакета разработки для SNMP (libsnmp-dev для Debian/Ubuntu, net-snmp-devel для CentOS/RHEL/OL/SUSE) и может быть не установлен по умолчанию.
snmpget:
Если вывод содержит «Invalid privacy protocol specified after -3x flag: AES-256» («Недопустимый протокол безопасности, указанный после флага -3x: AES-256»), то AES192+ не поддерживается. Если вывод содержит «No hostname specified.» («Не указано имя хоста.»), то AES192+ не поддерживается.
Если ваша библиотека net-snmp не поддерживает протоколы AES192 и выше, перекомпилируйте net-snmp с параметром --enable-blumenthal-aes, затем перекомпилируйте сервер Zabbix, указав параметр --with-net-snmp=/home/user/вашсобственныйnetsnmp/bin/net-snmp-config.
Шаг 3
Создайте элемент данных для мониторинга.
Итак, теперь вернитесь в Zabbix и нажмите на Элементы данных (Items) у ранее созданного узла сети SNMP. В зависимости от того, использовали ли вы шаблон при создании узла сети или нет, вы увидите или список элементов данных SNMP, связанных с вашим узлом сети, или попросту пустой список. Мы будем исходить из предположения, что вы собираетесь создать элемент данных самостоятельно, с помощью информации, которую вы только что собрали, используя snmpwalk или snmpget, так что нажмите на Создать элемент данных (Create item).
Заполните требуемые параметры в диалоге нового элемента данных:
| Параметр | Описание |
|---|---|
| Имя (Name) | Введите имя элемента данных. |
| Тип (Type) | Выберите здесь SNMP агент (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 (GetBulkRequest-PDU) асинхронно. Настройки тайм-аута для этого элемента данных можно задать в диалоге настроек элемента данных. Рассмотрите возможность установки небольшого значения тайм-аута, чтобы избежать длительных задержек, если устройство недоступно, поскольку если для предыдущих попыток истечёт время тайм-аута или они завершатся неудачей, то будет предпринято до 5 повторных попыток (начиная с версии Zabbix 7.0.14) (например, 3-секундный тайм-аут может привести к времени ожидания 15 секунд). Вы можете использовать его как основной элемент данных с зависимыми элементами данных, которые извлекают данные из основного с помощью предварительной обработки. В одной операции SNMP walk можно указать несколько 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 и v3, а GetNext — для интерфейсов SNMPv1; максимальное количество повторений для массовых запросов настраивается на уровне интерфейса. Параметр максимального количества повторений влияет на массовые запросы, определяя максимальное количество OID, возвращаемых в одном массовом ответе. Более высокое значение приводит к более крупным массовым ответам, что сокращает количество требуемых передач. Однако, не все устройства могут поддерживать очень высокие значения, что может вызывать проблемы. Этот элемент данных возвращает вывод утилиты snmpwalk с параметрами -Oe -Ot -On. Вы можете использовать этот элемент данных в качестве основного элемента данных в SNMP обнаружении. get[OID] — извлечение одного значения асинхронно. Например: get[1.3.6.1.2.1.31.1.1.1.6.3]Настройки времени ожидания для этого элемента данных можно задать в диалоге настроек элемента данных. Рассмотрите возможность установки небольшого значения тайм-аута, чтобы избежать длительных задержек, если устройство недоступно, поскольку если для предыдущих попыток истечёт время тайм-аута или они завершатся неудачей, то будет предпринято до 5 повторных попыток (начиная с версии Zabbix 7.0.14) (например, 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, перейдите в Мониторинг → Последние данные (Monitoring → Latest data).
Пример 1
Общий пример:
| Параметр | Описание |
|---|---|
| OID | 1.2.3.45.6.7.8.0 (или .1.2.3.45.6.7.8.0) |
| Ключ | <Уникальная строка, которая используется как ссылка в триггерах> Например, «my_param». |
Обратите внимание, что OID можно задать в числовом или строковом представлении. Тем не менее, в некоторых случаях строковый OID должен быть сконвертирован в числовое представление. Для этого можно использовать утилиту snmpget:
Пример 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 (задаваемый в диалоге настроек элемента данных) устанавливается для всей сессии. Если тайм-аут достигнут, то будет предпринята ещё одна попытка, тайм-аут будет сброшен, и последний запрос будет отправлен повторно, что позволит продолжить сессию с последнего запроса, если один пакет потерян или прибыл слишком поздно. Рассмотрите возможность установки небольшого значения тайм-аута, чтобы избежать длительных задержек, если устройство недоступно, поскольку если для предыдущих попыток истечёт время тайм-аута или они завершатся неудачей, то будет предпринято до 5 повторных попыток (начиная с версии Zabbix 7.0.14) (например, 3-секундный тайм-аут может привести к времени ожидания 15 секунд).
Внутреннее устройство комбинированной обработки
Zabbix-сервер и прокси-сервер могут запрашивать у SNMP-устройств несколько значений в одном запросе. Это влияет на несколько типов элементов данных SNMP:
- обычные элементы данных SNMP
- элементы данных 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 использует следующую стратегию. Он начинает с осторожного запроса одного значения. Если запрос успешен, 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-пакетов, а не с ограничением устройства.
Если же устройство не может корректно обрабатывать комбинированные запросы по другим причинам и описанная выше эвристика не работает, для каждого интерфейса предусмотрена настройка «Использовать комбинированные запросы», которая позволяет отключить комбинированные запросы для этого устройства.
Кроме того, если интерфейс часто становится недоступным, может потребоваться увеличить параметр UnavailableDelay в файлах конфигурации Zabbix-сервера или Zabbix-прокси, чтобы уменьшить частоту запросов. Элементы могут перестать поддерживаться, если во время обнаружения или проверки OID получены частичные данные.