2 SNMP агент

Обзор

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

Чтобы была возможность получать данные переданные SNMP агентами с этих устройств, Zabbix сервер должен быть изначально сконфигурирован с поддержкой SNMP.

SNMP проверки выполняются только через UDP протокол.

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

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

Шаг 1

Создайте узел сети для устройства с SNMP интерфейсом.

Введите IP адрес. Укажите состояние узла сети в БЕЗ НАБЛЮДЕНИЯ. Вы можете использовать один из поставляемых шаблонов SNMP (Template SNMP Device и другие), которые автоматически добавят некоторый набор элементов данных. Тем не менее, шаблон может быть не совместим с узлом сети.

Шаг 2

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

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

shell> snmpwalk -v 2c -c public <IP хоста> .

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

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

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

IF-MIB::ifInOctets.3 = Counter32: 3409739121

Сейчас вы можете воспользоваться командой snmpget для того чтобы определить цифровой OID для 'IF-MIB::ifInOctets.3':

shell> snmpget -v 2c -c public -On 10.62.1.22 IF-MIB::ifInOctets.3

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

Вывод команды покажет вам что-то наподобие этого:

.1.3.6.1.2.1.2.2.1.10.3 = Counter32: 3472126941

Опять же, последнее число в OID является номером порта.

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

Шаг 3

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

Итак, вернитесь назад в Zabbix и нажмите на Элементы данных, выберите созданный ранее узел сети SNMP. В зависимости от того использовали ли вы шаблон при создании узла сети или нет, вы должны будете увидеть список элементов данных SNMP, связанных с вашим узлом сети или попросту окно нового элемента данных. Мы будем исходить из предположения, что вы собираетесь создать элемент данных самостоятельно, с помощью информации, которую вы только что собрали используя snmpwalk или snmpget, так что введите простое описание на русском языке (или английском) в поле 'Описание' в диалоге нового элемента данных. Убедитесь, что в поле 'Узел сети' находится ваш коммутатор/роутер и измените поле 'Тип' в значение "SNMPv* агент". Введите community (обычно public) и укажите текстовый или числовой OID, который вы получили ранее, в поле 'SNMP OID', например: .1.3.6.1.2.1.2.2.1.10.3

Введите 'Порт SNMP' - 161 и 'Ключ' - что-то осмысленное, например, SNMP-InOctets-Bps. Выберите Множитель, если желаете, и укажите 'интервал обновления', и 'хранение истории', если вы хотите чтобы значения параметров отличались от умолчаний. Установите 'Состояние' в Наблюдается, 'Тип информации' в значение равное Числовой (с плавающей точкой) и 'Хранение значения' как Дельта (скорость в секунду) (важно, в противном случае вы будете получать накопленные значения с SNMP устройства вместо последнего изменения).

Теперь сохраните элемент данных и вернитесь в область узлов сети Zabbix. От сюда измените состояние SNMP устройства в 'Наблюдается' и проверьте в Последних данных ваши данные SNMP!

Обратите внимание на специфичные опции доступные только для SNMPv3 элементов данных:

Пример 1

Общий пример:

Обратите внимание, что OID можно задать в числовом или строковом представлении. Тем не менее, в некоторых случаях, строковый OID должен быть сконвертирован в числовое представление. Для этого можно использовать утилиту snmpget:

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

Мониторинг SNMP параметров возможен, если указан флаг --with-net-snmp при конфигурировании исходных кодов Zabbix.

Пример 2

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

Обработка массовых SNMP запросов

Начиная с 2.2.3 Zabbix сервер и прокси одним опросом запрашивают множество SNMP элементов данных. Такое поведение затрагивает следующие типы SNMP элементов данных:

• обычные SNMP элементы данных;
• SNMP элементы данных с динамическими индексами;
• правила низкоуровневого SNMP обнаружения.

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

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

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

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

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

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

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

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

Первое, для текущей серии элементов данных Zabbix делит пополам количество элементов данных за один запрос и запрашивает 21 переменных. Если устройство доступно, далее запросы должны работать в большинстве случаев, потому что известно что 28 переменных забиралось, а 21 значительно меньше. Тем не менее если проблема с запросами продолжается, Zabbix уменьшает количество запросов последовательно согласно этому алгоритму. Если и далее проблемы с запросами все еще актуальны, значит устройство определенно не отвечает и количество запросов это не корень проблемы.

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

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

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