No snmp data collection zabbix что это

Обновлено: 26.01.2025

Начнем с назначения протокола SNMPv3, и особенностей его использования. Задачи SNMP – мониторинг сетевых устройств, и элементарное управление, с помощью отправки на них простых команд (например, включение и отключение сетевых интерфейсов, или перезагрузка устройства).

Главное отличие протокола SNMPv3 от его предыдущих версий, это классические функции безопасности 2, а именно:

аутентификация (Authentication), определяющая, что запрос получен от доверенного источника;
шифрование (Encryption), для предотвращения раскрытия передаваемых данных при их перехвате третьими лицами;
целостность (Integrity), то есть гарантия того, что пакет не был подделан при передаче.

SNMPv3 вводит понятие уровней безопасности — допустимых уровней безопасности, определяющих настройку оборудования и поведение SNMP-агента объекта мониторинга. Сочетание модели безопасности и уровня безопасности определяет, какой механизм безопасности используется при обработке пакета SNMP [4].

В таблице описаны комбинации моделей и уровней безопасности SNMPv3 (первые три столбца я решил оставить как в оригинале):

Соответственно, мы будем использовать SNMPv3 в режиме аутентификации с применением шифрования.

Настройка SNMPv3

Мониторинг сетевого оборудования предполагает одинаковую настройку протокола SNMPv3 и на сервере мониторинга, и на наблюдаемом объекте.

Начнем с настройки сетевого устройства Cisco, его минимально необходимая конфигурация выглядит следующим образом (для конфигурирования используем CLI, имена и пароли я упростил во избежание путаницы):

Первая строка snmp-server group – определяет группу SNMPv3-пользователей (snmpv3group), режим чтения (read), и право доступа группы snmpv3group на просмотр определенных веток MIB-дерева объекта мониторинга (snmpv3name далее в конфигурации задает, к каким веткам MIB-дерева группа snmpv3group сможет получить доступ).

Вторая строка snmp-server user – определяет пользователя snmpv3user, его принадлежность к группе snmpv3group, а так же применение аутентификации md5 (пароль для md5 — md5v3v3v3) и шифрования des (пароль для des — des56v3v3v3). Разумеется, вместо des лучше использовать aes, здесь я его привожу просто для примера. Так же при определении пользователя можно добавить список доступа (ACL), регламентирующий IP-адреса серверов мониторинга, имеющих право осуществлять мониторинг данного устройства – это так же best practice, но я не буду усложнять наш пример.

Третья строка snmp-server view определяет кодовое имя, которое задает ветки MIB-дерева snmpv3name, чтобы их могла запрашивать группа пользователей snmpv3group. ISO, вместо строгого определения какой-то одной ветки, позволяет группе пользователей snmpv3group получать доступ ко всем объектам MIB-дерева объекта мониторинга.

Аналогичная настройка оборудования Huawei (так же в CLI) выглядит следующим образом:

После настройки сетевых устройств, необходимо проверить наличие доступа с сервера мониторинга по протоколу SNMPv3, я воспользуюсь snmpwalk:

Более наглядный инструмент для запроса конкретных OID-объектов, с использованием MIB-фалов – snmpget:

Теперь перейдем к настройке типового элемента данных для SNMPv3, в рамках Zabbix-шаблона. Для простоты и независимости от MIB, я использую цифровые OID:

Я использую в ключевых полях пользовательские макросы, поскольку они будут одинаковы для всех элементов данных в шаблоне. Задавать их можно в рамках шаблона, если в Вашей сети у всех сетевых устройств параметры SNMPv3 одинаковы, или в рамках узла сети, если параметры SNMPv3 для разных объектов мониторинга отличаются:

Обратите внимание, система мониторинга располагает только именем пользователя, и паролями для аутентификации и шифрования. Группа пользователей и область MIB-объектов, к которым разрешен доступ, задается на объекте мониторинга.
Теперь перейдем к наполнению шаблона.

Шаблон опроса в Zabbix

Простое правило при создании любых шаблонов опроса – делать их максимально подробными:

Я уделяю большое внимание инвентаризации, чтобы с большой сетью было удобнее работать. Об этом немного позднее, а пока – триггеры:

Для удобства визуализации триггеров в их названия заложены системные макросы , чтобы на дашборде в разделе алёртинга выводились не только имена устройств, но и IP-адреса, хотя это больше вопрос удобства, чем необходимости. Для определения недоступности устройства, помимо обычного echo-запроса, я использую проверку на недоступность узла по протоколу SNMP, когда объект доступен по ICMP, но не отвечает на SNMP-запросы – такая ситуация возможна, например, при дублировании IP-адресов на разных устройствах, из-за некорректно настроенных межсетевых экранов, или неверных настроек SNMP на объектах мониторинга. Если использовать проверку доступности узлов только по ICMP, в момент расследования инцидентов в сети, данных мониторинга может не оказаться, поэтому их поступление нужно контролировать.

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

Я использую стандартную функцию обнаружения для SNMP, с большим количеством обнаруживаемых параметров, для более гибкой фильтрации:

При таком обнаружении, можно фильтровать сетевые интерфейсы по их типам, пользовательским описаниям «description», и административным статусам портов. Фильтры и регулярные выражения для фильтрации в моем случае выглядят следующим образом:

При обнаружении будут исключены следующие интерфейсы:

выключенные вручную (adminstatus<>1), благодаря IFADMINSTATUS;
не имеющие текстового описания, благодаря IFALIAS;
имеющие в текстовом описании символ *, благодаря IFALIAS;
являющиеся служебными или техническими, благодаря IFDESCR (в моем случае, в регулярных выражениях IFALIAS и IFDESCR проверяются одним регулярным выражением alias).

Итоги мониторинга

Для начала – инвентаризация небольшой сети:

Если подготовить шаблоны для каждой серии сетевых устройств – можно добиться удобной для анализа компоновки сводных данных по актуальному ПО, серийным номерам, и оповещении о приходе в серверную уборщицы (по причине малого Uptime). Выдержка моего списка шаблонов ниже:

А теперь – главная панель мониторинга, с распределенными по уровням важности триггерами:

Благодаря комплексному подходу к шаблонам для каждой модели устройств в сети, можно добиться того, что в рамках одной системы мониторинга будет организован инструмент для прогнозирования неисправностей и аварий (при наличии соответствующих датчиков и метрик). Zabbix хорошо подходит для мониторинга сетевых, серверных, сервисных инфраструктур, и задача обслуживания сетевого оборудования наглядно демонстрирует её возможности.

Zabbix Documentation 4.2

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

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

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

Начиная с версии 2.2.3 демоны Zabbix сервера и прокси опрашивают устройства SNMP множественными значениями за один запрос. Это поведение повлияет на все виды SNMP элементов данных (простые SNMP элементы данных, элементы данных с динамическими индексами и также низкоуровневые SNMP обнаружения) и обработка SNMP элементов данных сейчас должна быть более эффективной. Пожалуйста обратите внимание на раздел с техническими подробностями ниже, описывающий как работает изнутри этот функционал. Начиная с Zabbix 2.4 у каждого интерфейса также имеется настройка “Использовать массовые запросы”, которая позволяет отключать массовые запросы у устройств, которые не способны обработать их должным образом.

Начиная с Zabbix 2.2.7 и Zabbix 2.4.2 процессы сервера и прокси будут журналировать строки похожие на следующие в случае получения неправильного/искаженного SNMP ответа: Пока они не покрывают все возможные проблемные случаи, но они являются удобным удобным идентификатором отдельных SNMP устройств на которых необходимо отключить массовые запросы.

Начиная с версии Zabbix 2.2 демоны сервера и прокси корректно обрабатывают параметр конфигурации Timeout при выполнении SNMP проверок. Дополнительно демоны не выполняют повторных запросов после одного неуспешного (по превышении времени ожидания/неверные настройки учетных данных) SNMP запроса. Ранее на самом деле использовались стандартные для библиотеки SNMP значения времени ожидания и количества повторов (1 секунда и 5 повторов соответственно).

Начиная с версии Zabbix 2.2.8 и Zabbix 2.4.2 демоны сервера и прокси всегда выполняют один повторный запрос: либо через механизм библиотеки SNMP, либо через внутренний механизм сбора множества значений за один запрос (bulk).

Если выполняется мониторинг устройств по SNMPv3, убедитесь что msgAuthoritativeEngineID (также известное как snmpEngineID или “Engine ID”) никогда не будет общим для двух и более устройств. Согласно RFC 2571 (раздел 3.1.1.1) оно должно быть уникальным для каждого устройства.

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

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

Шаг 1

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

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

SNMP проверки не используют Порт агента, он игнорируется.

Шаг 2

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

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

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

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

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

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

3COM кажется использует номера портов сотнями, например 1 порт = 101 порт, 3 порт = 103 порт, но в Cisco используются обычные номера, например, 3 порт = 3.

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

Шаг 3

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

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

Теперь сохраните элемент данных и перейдите в Мониторинг → Последние данные, чтобы увидеть ваши данные SNMP!

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

Параметр	Описание
Имя контекста	Введите контекстное имя для определения элемента данных в SNMP подсети. Имя контекста поддерживается для SNMPv3 элементов данных с Zabbix 2.2.

В случае некорректных учётных данных SNMPv3 (имя безопасности, протокол/фраза-пароль аутентификации, протокол безопасности) Zabbix получит ERROR от net-snmp, за исключением ошибочного Фразы-пароль безопасности, в этом случае Zabbix получит ошибку ВРЕМЕНИОЖИДАНИЯ от net-snmp.

При изменениях в Протокол аутентификации, Фраза-пароль аутентификации, Протокол безопасности или Фраза-пароль безопасности, чтобы эти изменения применились, необходимо перезапустить сервер/прокси.

Пример 1

Параметр	Описание
Community	public
OID	1.2.3.45.6.7.8.0 (или .1.2.3.45.6.7.8.0)
Ключ	<Уникальная строка, которая используется как ссылка в триггерах> Например, “my_param”.

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

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

Пример 2

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

Параметр	Описание
Community	public
Oid	MIB::sysUpTime.0
Ключ	router.uptime
Тип информации	Числовой (с плавающей точкой)
Единица измерения	uptime
Множитель	0.01

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

Начиная с 2.2.3 Zabbix сервер и прокси одним опросом запрашивают множество 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 пакетов, чем скорее ограничение устройства.

Если, однако, устройство не может обрабатывать массовые запросы корректно и по другим причинам, начиная с Zabbix 2.4 имеется настройка “Использовать массовые запросы” у каждого интерфейса, которая позволяет отключить массовые запросы у этого устройства.

Zabbix Documentation 2.4

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

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

Если выполняется мониторинг устройств по SNMPv3, убедитесь что msgAuthoritativeEngineID (также известное как snmpEngineID или “Engine ID”) никогда не будет общим для двух и более устройств. Согласно RFC 2571 (раздел 3.1.1.1), но должно быть уникальным для каждого устройства.

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

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

Шаг 1

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

SNMP проверки не используют Порт агента, он игнорируется.

Шаг 2

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

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

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

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

Шаг 3

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

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

Параметр	Описание
Имя контекста	Введите контекстное имя для определения элемента данных в SNMP подсети. Имя контекста поддерживается для SNMPv3 элементов данных с Zabbix 2.2.

Начиная с Zabbix 2.2, протоколы SHA and AES поддерживаются для аутентификации и шифрования SNMPv3, в дополнении к поддерживаемым MD5 и DES протоколам ранее.

Пример 1

Параметр	Описание
Community	public
OID	1.2.3.45.6.7.8.0 (или .1.2.3.45.6.7.8.0)
Ключ	<Уникальная строка, которая используется как ссылка в триггерах> Например, “my_param”.

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

Пример 2

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

Параметр	Описание
Community	public
Oid	MIB::sysUpTime.0
Ключ	router.uptime
Тип информации	Числовой (с плавающей точкой)
Единица измерения	uptime
Множитель	0.01

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

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

Автоматизируем мониторинг: низкоуровневое обнаружение для SNMP

Мы уже писали о том, какой замечательный инструмент как LLD есть в Zabbix.

Тогда же мы посетовали, что составные индексы в SNMP-таблицах в системе не поддерживаются, что несколько ограничивает возможности по применению. Например, если вам нужно сделать Discovery двух RAID-контроллеров на одном сервере и всех физических и логических дисков за ними, то, увы, мы этого сделать не могли без костылей. Работало только для первого RAID-контролера в списке. Но, как говорится, все течет, все меняется! И вот долгожданный релиз 2.2 убрал это связывающее нас по рукам ограничение.

Рассказать о нововведении я бы хотел на примере шаблона для HP серверов. Но сначала немножко вспомним про SNMP.

Итак, что такое LLD для SNMP?

Это добавление элементов данных на основе строк в таблице SNMP. Каждая строка это один новый элемент данных на основе прототипа. А что такое вообще таблица SNMP, как ее найти среди других объектов SNMP в MIB?

Это объект (OBJECT-TYPE), чей атрибут SYNTAX определен как SEQUENCE OF X, где X -последовательность объектов, описывающая столбцы таблицы. Сами строки таблицы хранятся этажом ниже в другой объекте, и от таблицы отличаются наличием АТРИБУТА INDEX, уникального ключа, использующегося для идентификации строк. Что это я сказал? Лучше пример.

Возьмем всем известную таблицу ifTable с интерфейсами из IF-MIB, ее MIB в дереве SNMP будет выглядеть вот так:

А результат запроса к такой таблице на каком-нибудь коммутаторе будет выглядеть вот так:

Причем, index является составной частью OID, и как раз служит, чтобы отличить столбцы одной строчки таблицы от другой:

$ snmpwalk -c public -v 2c -On 10.2.0.108 IF-MIB:ifDescr
.1.3.6.1.2.1.2.2.1.2.1 = STRING: D-Link DES-3200-18 R1.28 Port 1
.1.3.6.1.2.1.2.2.1.2.2 = STRING: D-Link DES-3200-18 R1.28 Port 2
.1.3.6.1.2.1.2.2.1.2.3 = STRING: D-Link DES-3200-18 R1.28 Port 3
.1.3.6.1.2.1.2.2.1.2.4 = STRING: D-Link DES-3200-18 R1.28 Port 4
.1.3.6.1.2.1.2.2.1.2.5 = STRING: D-Link DES-3200-18 R1.28 Port 5
.1.3.6.1.2.1.2.2.1.2.6 = STRING: D-Link DES-3200-18 R1.28 Port 6
.1.3.6.1.2.1.2.2.1.2.7 = STRING: D-Link DES-3200-18 R1.28 Port 7
.1.3.6.1.2.1.2.2.1.2.8 = STRING: D-Link DES-3200-18 R1.28 Port 8
.1.3.6.1.2.1.2.2.1.2.9 = STRING: D-Link DES-3200-18 R1.28 Port 9
.1.3.6.1.2.1.2.2.1.2.10 = STRING: D-Link DES-3200-18 R1.28 Port 10
.1.3.6.1.2.1.2.2.1.2.11 = STRING: D-Link DES-3200-18 R1.28 Port 11
.1.3.6.1.2.1.2.2.1.2.12 = STRING: D-Link DES-3200-18 R1.28 Port 12
.1.3.6.1.2.1.2.2.1.2.13 = STRING: D-Link DES-3200-18 R1.28 Port 13
.1.3.6.1.2.1.2.2.1.2.14 = STRING: D-Link DES-3200-18 R1.28 Port 14
.1.3.6.1.2.1.2.2.1.2.15 = STRING: D-Link DES-3200-18 R1.28 Port 15
.1.3.6.1.2.1.2.2.1.2.16 = STRING: D-Link DES-3200-18 R1.28 Port 16
.1.3.6.1.2.1.2.2.1.2.17 = STRING: D-Link DES-3200-18 R1.28 Port 17
.1.3.6.1.2.1.2.2.1.2.18 = STRING: D-Link DES-3200-18 R1.28 Port 18
.1.3.6.1.2.1.2.2.1.2.1024 = STRING: D-Link DES-3200-18 R1.28 802.1Q Encapsulation Tag 0001
.1.3.6.1.2.1.2.2.1.2.1063 = STRING: D-Link DES-3200-18 R1.28 802.1Q Encapsulation Tag 0040
.1.3.6.1.2.1.2.2.1.2.1064 = STRING: D-Link DES-3200-18 R1.28 802.1Q Encapsulation Tag 0041
.1.3.6.1.2.1.2.2.1.2.5121 = STRING: D-Link DES-3200-18 R1.28 rif0(10.2.0.108)

В IF-MIB:ifTable index простой и равен одному столбцу в таблице: ifIndex. Zabbix мог находить элементы данных в таких таблицах еще в момент появления LLD, с версии 2.0, а обнаружение всех доступных интерфейсов из таблицы ifTable есть в стандартном шаблоне. О том же, как настроить LLD с простыми индексами мы как раз писали на хабре в прошлый раз.

Но в SNMP бывают таблицы, где индекс составной и выглядит посложнее, чем просто одинокая цифра. Вот например таблица TCP-MIB:tcpConnTable, в которой хранятся все текущие соединения. В этой таблице индекс составной и состоит из четырех объектов:

Local IP Address.Local Port.Remote IP Address.Remote Port

Вот они в MIB-файле:

А вот эти индексы при опросе оборудования:

$ snmptable -c public -v 2c -Os -Ciw 150 10.2.0.108 TCP-MIB:tcpConnTable
SNMP table: tcpConnTable

index tcpConnState tcpConnLocalAddress tcpConnLocalPort tcpConnRemAddress tcpConnRemPort
0.0.0.0.22.0.0.0.0.0 listen 0.0.0.0 22 0.0.0.0 0
0.0.0.0.80.0.0.0.0.0 listen 0.0.0.0 80 0.0.0.0 0

или если опрашивать snmpwalk:

$ snmpwalk -c virton -v 2c -Os 10.2.0.108 TCP-MIB:tcpConnTable
tcpConnState.0.0.0.0.22.0.0.0.0.0 = INTEGER: listen(2)
tcpConnState.0.0.0.0.80.0.0.0.0.0 = INTEGER: listen(2)
tcpConnLocalAddress.0.0.0.0.22.0.0.0.0.0 = IpAddress: 0.0.0.0
tcpConnLocalAddress.0.0.0.0.80.0.0.0.0.0 = IpAddress: 0.0.0.0
tcpConnLocalPort.0.0.0.0.22.0.0.0.0.0 = INTEGER: 22
tcpConnLocalPort.0.0.0.0.80.0.0.0.0.0 = INTEGER: 80
tcpConnRemAddress.0.0.0.0.22.0.0.0.0.0 = IpAddress: 0.0.0.0
tcpConnRemAddress.0.0.0.0.80.0.0.0.0.0 = IpAddress: 0.0.0.0
tcpConnRemPort.0.0.0.0.22.0.0.0.0.0 = INTEGER: 0
tcpConnRemPort.0.0.0.0.80.0.0.0.0.0 = INTEGER: 0

Раньше такие индексы вводили Zabbix в ступор. В 2.2 теперь мы можем мониторить и такие таблицы. Давайте рассмотрим на практическом примере.

HP Insight Manager

Итак, у нас есть сервер HP Proliant, а в нем стоят два RAID-контроллера. Кроме всего прочего про систему нас интересует состояние всех жестких дисков, подключенных к RAID-контроллеру.

Чтобы получить доступ к этим данным, если у нас ОС Windows или Linux, нам необходимо установить HP Insight Management Agent, который и выложит эти информацию для доступа по snmp. Останется ее только забрать.

Чтобы понять, что нам забирать, обратимся к MIB-файлу. Для RAID это CPQIDA-MIB, а для физических дисков это таблица CPQIDA-MIB:cpqDaPhyDrvTable. Как мы видим, индекс здесь состоит из двух частей:

Первая часть индекса — индекс контроллера
Вторая часть — индекс диска

Опросим таблицу, ее столбец со статусом дисков:

$ snmpwalk -c public -v 2c 192.168.0.22 1.3.6.1.4.1.232.3.2.5.1.1.5
iso.3.6.1.4.1.232.3.2.5.1.1.5.1.0 = INTEGER: 1
iso.3.6.1.4.1.232.3.2.5.1.1.5.1.1 = INTEGER: 2
iso.3.6.1.4.1.232.3.2.5.1.1.5.1.2 = INTEGER: 3
iso.3.6.1.4.1.232.3.2.5.1.1.5.1.3 = INTEGER: 4
iso.3.6.1.4.1.232.3.2.5.1.1.5.4.1 = INTEGER: 5
iso.3.6.1.4.1.232.3.2.5.1.1.5.4.2 = INTEGER: 6
iso.3.6.1.4.1.232.3.2.5.1.1.5.4.3 = INTEGER: 7
iso.3.6.1.4.1.232.3.2.5.1.1.5.4.4 = INTEGER: 8

Видим, что у нас восемь дисков (cpqDaPhyDrvIndex) расположенных на контроллерах под индексами 1 и 4 (cpqDaPhyCntlrIndex). В 2.0 через LLD нашлось бы только первые четыре диска.

Как настраивать обнаружение? Да точно также, как и LLD с обычными индексами:

Шаг 1: Сначала создаем обнаружение в шаблоне для HP:

Раз мы заговорили про макросы, то напомню, что в LLD по SNMP их два: , . И для каждой найденной строчки в таблице они будут принимать значения:

Шаг 2: Создадим прототип элемента данных

Шаг 3: Создадим прототип триггера

Повторим шаги 2,3 для других интересных столбцов таблицы физических дисков.

Элементы данных:

Повторим шаги 1-3 для других интересных таблиц в MIBах от HP, получим:

SNMP-Таблица	Что интересного	Индекс таблицы
CMPQIDA-MIB:cpqDaCntlrTable	Статус RAID-контроллеров	Простой
CMPQIDA-MIB:cpqDaAccelTable	Статус Array Accelerator, контроль батарейки	Простой
CMPQIDA-MIB:cpqDaCntlrPerfTable	Производительность RAID, загрузка процессора RAID	Составной
CMPQIDA-MIB:cpqDaLogDrvTable	Статус логических дисков	Составной
CMPQIDA-MIB:cpqDaLogDrvPerfTable	Производительность логических дисков	Составной
CMPQHLTH-MIB:cpqHeTemperatureTable	Температура ЦПУ, памяти и других компонент	Составной
CMPQHLTH-MIB:cpqHeThermalFanTable	Статус вентиляторов	Простой
CMPQHLTH-MIB:cpqHeFltTolPowerSupplyTable	Статус блоков питания	Составной

Что в системе будет выглядеть вот так:

Шаг 4: Добавляем наш шаблон к узлам сети HP

Указываем для них значение макроса , если оно отличное от public, ждем окончания работы LLD. Итог увидим в разделе Последние данные:

Итого

Теперь, когда Заббикс поддерживает составные индексы SNMP, существенно расширился список таблиц до которых может дотянуться рука LLD. А чем больше вы задействуете Low-level Discovery — тем меньше вы настраиваете в Заббиксе руками. Ручная работа с LLD — настройка прототипов в шаблоне. Но это нужно сделать только один раз.

Читайте также: