Настройка SNMP Traps в zabbix-server

Имеем сервер Ubuntu 16.04.3 LTS. На нём крутится zabbix server. Задача — настроить SNMP Traps.

Ставим пакеты под рутом:

apt-get install snmp snmpd snmptt snmptrapd

В конфиге /etc/default/snmptrapd изменяем значение параметра TRAPDRUN с no на yes .

В конфиге /etc/snmp/snmptrapd.conf :

authCommunity log,execute,net public
traphandle default /usr/sbin/snmptthandler

В конфиге /etc/snmp/snmptt.ini укажем параметры:

mode = daemon
net_snmp_perl_enable = 1
mibs_environment = ALL
unknown_trap_log_enable = 1
date_time_format = %H:%M:%S %Y/%m/%d
log_enable = 1
log_file = /var/log/snmptt/snmptt.log
unknown_trap_log_enable = 1
unknown_trap_log_file = /var/log/snmptt/snmpttunknown.log

В конфиге /etc/snmp/snmptt.conf дописываем :

EVENT general .* «General event» Normal
FORMAT ZBXTRAP $aA $1 $2 $3

Перезапускаем snmpd, snmptt и snmptrapd:

service snmpd restart
service snmptt restart
service snmptrapd restart

Проверяем, что 162 порт слушается:

Правим конфиг /etc/zabbix/zabbix_server.conf:

service snmpd restart
service snmptt restart
service snmptrapd restart
service zabbix-server restart

Можно сгенерировать тестовый трап:

snmptrap -v 1 -c public 127.0.0.1 ‘.1.3.6.1.6.3.1.1.5.3’ ‘0.0.0.0’ 6 33 ’55’ .1.3.6.1.6.3.1.1.5.3 s «teststring000»

В файле /var/log/snmptt/snmptt.log видим:

Wed Aug 15 15:02:36 2018 .1.3.6.1.6.3.1.1.5.3.0.33 Normal «General event» localhost — ZBXTRAP 127.0.0.1 teststring000 $2 $3

Это означает, что трапы пишутся в файл.

В файле /var/log/zabbix/zabbix-server.log видим:

11843:20180815:150241.105 unmatched trap received from «127.0.0.1»: Wed Aug 15 15:02:36 2018 .1.3.6.1.6.3.1.1.5.3.0.33 Normal «General event» localhost — teststring000 $2 $3

Это означает, что заббикс читает файл.

Если вам понравилась статья, то ставьте 👍🏻 каналу.
Пишите комментарии, задавайте вопросы, подписывайтесь.

Мониторинг сетевого оборудования по SNMPv3 в Zabbix

Несколько слов об SNMPv3

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

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

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

SNMPv3 подразумевает использование модели безопасности, при которой стратегия аутентификации устанавливается для заданного пользователя и группы, к которой он относится (в предыдущих версиях SNMP в запросе от сервера к объекту мониторинга сравнивалось только «community», текстовая строка с «паролем», передаваемая в открытом виде (plain text)).

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).

Шаблон для сбора данных по протоколу SNMPv3 почти готов. Не будем подробнее останавливаться на прототипах элементов данных для сетевых интерфейсов, перейдем к результатам.

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

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

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

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

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

Присматриваем за окнами. Windows + Zabbix

Введение

Практика «Агента»

Если у Вас установлен Zabbix агент, то общаться мы будем с ОС через него.

При просмотра шаблона Template OS Windows обращаем внимание на элемент данных:
Average disk write queue length perf_counter[\234(_Total)\1404].

Что же означают эти цифры \234(_Total)\1404. ?

В ОС Windows эти цифры обозначают внутренние идентификаторы счетчиков производительности. Но если у Вас установленна база Zabbix с кодировкой UTF8, то ничего не мешает нам использовать русские названия в счетчиках

Получаем счетчики следующим образом:
typeperf -q

А если у нас несколько жестких дисков (интерфейсов и т.п.):
typeperf -qx

Слишком много информации? Фильтруем:
typeperf «\Физический диск(_Total)\»

Другой вариант получить счетчики:
lodctr /s:perfcount.txt
Открыв файл мы увидем идентификаторы и их название в начале на английском, а затем на русском языке.

Практика SNMP

Но что делать, когда нельзя (или нет желания) установить агент?
Для этого, мы будем читать счетчики через SNMP:

snmpwalk -Of -c public -v 2c 192.168.0.1

Если выполнять под ОС Windows, то результат будет вида:
.iso.3.6.1.2.1.1.1.0 = STRING: «Hardware: Intel64 Family 6 Model 44 Stepping 2 AT/AT COMPATIBLE — Software: Windows Version 6.1 (Build 7601 Multiprocessor Free)»

Если выполнять под ОС Linux, то результат будет вида:
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = STRING: Hardware: Intel64 Family 6 Model 44 Stepping 2 AT/AT COMPATIBLE — Software: Windows Version 6.1 (Build 7601 Multiprocessor Free)

(Также можно поискать соответствие цифр с названиями на http://support.ipmonitor.com/snmp_center.aspx)

Linux вариант более информативный.

Заключение

Осталось подключить необходмые счетки и можно будет следить за производительностью системы.

Zabbix Documentation 5.2

Sidebar

Table of Contents

2 SNMP агент

Обзор

Вы возможно захотите использовать 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).

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

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

Шаг 1

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

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

Шаг 2

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

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

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

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

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

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

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

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

Опять же, последнее число в 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, 2.4.3). Приведенные типы грубо соответствуют “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 устройства вместо последнего изменения). Выберите множитель, если желаете, и укажите ‘Интервал обновления’, и ‘Хранение истории’, если вы хотите чтобы значения параметров отличались от умолчаний.

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

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

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

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

В данном поле раскрываются пользовательские макросы. Имя безопасности Введите имя безопасности.
В данном поле раскрываются пользовательские макросы. Уровень безопасности Выберете уровень безопасности:
noAuthNoPriv — ни аутентификация, ни протокол безопасности не используются
AuthNoPriv — используется протокол аутентификации, протокол безопасности нет
AuthPriv — используются и протокол аутентификации, и протокол безопасности Протокол аутентификации Выберете протокол аутентификации — MD5 или SHA. Фраза-пароль аутентификации Введите фразу-пароль для аутентификации
В данном поле раскрываются пользовательские макросы. Протокол безопасности Введите протокол безопасности — DES или AES. Фраза-пароль безопасности Введите фразу-пароль безопасности.
В данном поле раскрываются пользовательские макросы.

В случае некорректных учётных данных 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 элемента данных описаны ниже:

Тем не менее, есть техническая проблема что не все устройства способны вернуть 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 имеется настройка “Использовать массовые запросы” у каждого интерфейса, которая позволяет отключить массовые запросы у этого устройства.