No snmp data collection ошибка
Обновлено: 02.07.2024
Начнем с назначения протокола SNMPv3, и особенностей его использования. Задачи SNMP – мониторинг сетевых устройств, и элементарное управление, с помощью отправки на них простых команд (например, включение и отключение сетевых интерфейсов, или перезагрузка устройства).
Главное отличие протокола SNMPv3 от его предыдущих версий, это классические функции безопасности 3, а именно:
- аутентификация (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 хорошо подходит для мониторинга сетевых, серверных, сервисных инфраструктур, и задача обслуживания сетевого оборудования наглядно демонстрирует её возможности.
Мы уже писали о том, какой замечательный инструмент как 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 — настройка прототипов в шаблоне. Но это нужно сделать только один раз.
The twist: the host is pingable, but non-responsive to snmpwalk. This is one of 20 hosts. The other 19 hosts are being monitored via snmp.
1.SNMPv2 on all hosts
3.Gateway Firewall rules
5.snmpwalk from production zabbix fails
6.snmpwalk from proxy fails
7.ping from production ZBX good
8.ping from proxy ZBX good
9.ZBX conf Timeout parameter set to 4 seconds
10.Unlink and Clear Template. Copy SNMP availablity item from other host. Clear History and Trends.
Sounds like a bad template. But yeah let us know what you find tomorrow.
Woah that video is ancient.
What do you want to monitor?
I have a handful of servers that I want to monitor. server status, CPU, memory, and HDD space are kinda important, but mostly I want to see data in and out on the network interfaces.
try to read data from device with SNMP walk installed on zabbix server
That said, my experience with SNMP monitoring has been limited to PRTG (with a different company) and LibreNMS both of which automate the discovery, so learning about templates is my biggest challenge so far.
Читайте также: