Community-templates Goto Github PK

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курcе по администрированию MikroTik. Автор курcа, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Содержание

Цели статьи
Введение
Мониторинг Mikrotik в Zabbix по snmp
Отправка логов Mikrotik в syslog
Мониторинг подключений (авторизаций) в Mikrotik
Заключение
Онлайн курcы по Mikrotik
Помогла статья? Подписывайся на telegram канал автора
Несколько слов об SNMPv3
Настройка SNMPv3
Шаблон опроса в Zabbix
Итоги мониторинга
Техническое задание
Пробуем с наскока
Пробуем со второго наскока
Настраиваем сетевую железку
Настройка SNMPd, SNMPTRAPd, SNMPTT
Настройка Zabbix
Техническое задание
Пробуем с наскока
Пробуем со второго наскока
Настраиваем сетевую железку

Цели статьи

Настроить мониторинг базовых метрик сетевых устройств Mikrotik.
Настроить отправку основных логов на удаленный сервер.
Анализировать логи mikrotik и отправлять уведомления в случае подключения к устройству.

Введение

За основу мониторинга Mikrotik я возьму стандартный шаблон Zabbix от разработчиков. Он очень качественно сделан. Забирает информацию по snmp. Итемы и триггеры настраиваются через автообнаружение. Вот основные метрики, которые в нем реализованы:

Состояние процессоров (загрузка, температура).
Статус и характеристика интерфейсов (трафик, активность, ошибки, тип, скорость).
Хранилища (общий объем и используемый).
Использование оперативной памяти.
Проверка доступности пингом.
Версия прошивки, модель, система, серийный номер, расположение, описание устройства.
Время работы (uptime).

Для всех основных метрик есть графики. На все значимые события настроены триггеры:

Высокая температура процессора.
Изменение серийного номера, прошивки.
Сетевая недоступность по icmp.
Высокая загрузка памяти или процессора.
Окончание свободного места на хранилищах.
Уменьшилась скорость на интерфейсе.
Высокая утилизация интерфейса.
Большое количество ошибок на интерфейсе.
Интерфейс отключился.

Шаблон настолько хорош и полон, что я даже не придумал, чего в нем не хватает. По метрикам есть все. Для полного мониторинга Микротика мне не хватало только оповещений о том, что к нему кто-то подключился. Я реализовал это по своему, о чем расскажу далее подробно. В двух словах мониторинг подключений выглядит так:

Mikrotik отправляет логи подключений на удаленный syslog сервер.
На syslog сервере логи анализирует zabbix-agent.
По определенному шаблону агент определяет имя и ip адрес подключившегося к микротику и отправляет эту информацию в уведомлении.

В целом, никаких сложностей в этой настройке нет. У меня уже есть статьи по сбору логов с микротиков — отправка в elk stack и на удаленный rsyslog сервер. Сегодня я актуализирую эту информацию и опишу еще раз.

Если вы не очень хорошо знакомы с описываемым роутером, рекомендую мою статью по базовой настройке микротика.

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

То же самое на Debian 10, если предпочитаете его:

Мониторинг Mikrotik в Zabbix по snmp

Стандартный шаблон собирает все метрики по snmp. Так что нам надо включить его на микротике. Для этого подключаемся к нему по Winbox и идем в раздел IP -> SNMP. Настраиваем работу snmp.

Мы включили snmp, выставили версию 2, разрешили подключаться только с ip адреса zabbix server — 10.1.3.29. Не забудьте указать адрес своего сервера.

Сходим теперь на zabbix-server и убедимся, что мы через него можем забирать информацию с mikrotik по snmp. Для этого подключимся к нему по ssh и воспользуемся утилитой snmpwalk. Если у вас ее нет, то поставить можно командой:

# yum install net-snmp-utils

Подключаемся к микротику по snmp.

# snmpwalk -v 2c -c public 10.1.3.111

Получите кучу значений в консоли. Если хотите удобно их просмотреть, направьте вывод команды в файл и почитайте его. Если подключение прошло успешно, то переходим в Web интерфейс Zabbix сервера.

template_module_generic_snmp_SNMPv2_EN.xml
template_module_interfaces_SNMPv2_EN.xml
00template_module_icmp_ping__EN.xml

Теперь нам нужно добавить в систему само устройство Mikrotik. Делаем это как обычно, не забывая указать snmp интерфейс.

И не забудьте ему подключить шаблон Template Net Mikrotik SNMPv2. После этого можно идти в Lates Data и проверять поступление информации с устройства в систему мониторинга.

Часть данных увидите сразу, а та, что поступает через правила автообнаружения, появится позже. Надо подождать. После того, как отработают все правила автообнаружения, рекомендую сходить на хост и поотключать то, что вам не нужно. К примеру, если у вас настроен capsman, то в мониторинг с мастера попадут интерфейсы cap, которые отключаются, если к точке нет подключенных клиентов по wifi. В итоге будет ненужный спам от мониторинга с точек.

На этом по мониторингу базовых метрик в микротике все. Теперь займемся уведомлениями о подключениях к устройствам через Winbox.

Отправка логов Mikrotik в syslog

Первым делом настроим сбор логов с микротиков на любой syslog сервер. В моем случае это будет сам сервер мониторинга на базе rsyslog и centos 7, но это не принципиально. Главное, чтобы на нем был zabbix-agent, который будет отправлять логи микротиков на заббикс сервер.

Для этого в rsyslog включим возможность слушать udp port 514. Открываем конфиг /etc/rsyslog.conf и раскомментируем там строки:

$ModLoad imudp
$UDPServerRun 514

Дальше в этом же файле в самом начале перечисления правил, добавляем свое.

$template FILENAME,"/var/log/mikrotik/%fromhost-ip%.log"
if $fromhost-ip != '127.0.0.1' then ?FILENAME
& stop

Данное правило будет автоматически раскладывать все логи с удаленных устройств по файлам в директории /var/log/mikrotik с именами в виде IP адресов. При этом не будет создан лог 127.0.0.1.log, куда бы складывались все локальные лог файлы. В своей предыдущей статье я не учитывал этот нюанс, что приводило к дублированию всех локальных логов. Сейчас я это исправляю.

Сразу же настроим ротацию лог файлов, чтобы они не забили нам весь диск. Для этого создаем конфиг для logrotate в файле /etc/logrotate.d/mikrotik примерно следующего содержания:

/var/log/mikrotik/*.log {	weekly	rotate 12	compress	olddir /var/log/mikrotik/old	missingok	notifempty	create 0640 root zabbix
}

Я ротирую файлы логов раз в неделю, сразу сжимаю и кладу их в директорию /var/log/mikrotik/old, где будут храниться 12 последних версий файла.

Не забудьте создать указанные директории и дать пользователю zabbix права на чтение. Потом проследите, чтобы у самих логов тоже были права на чтение для zabbix. Это важно, так как агент должен их читать.

После завершения настройки, надо перезапустить rsyslog.

# systemctl restart rsyslog

Отправляемся на Mikrotik и настраиваем отправку логов на наш syslog сервер. Для этого переходите в раздел System -> Logging -> Actions и добавляйте новое действие.

Чтобы проверить отправку логов, достаточно тут же в Mikrotik открыть новый терминал. Создастся событие в логе, который улетит на удаленный сервер. На сервере с rsyslog будет создан лог файл с содержимым.

Если у вас так же, можно двигаться дальше. Если же логи не поступают на syslog сервер, разбирайтесь в чем может быть причина. Первым делом проверьте настройки firewall. Убедитесь, что доступ к udp порту 514 есть. Дальше проверьте, что ваш rsyslog сервер реально слушает этот порт.

Мониторинг подключений (авторизаций) в Mikrotik

Логи с устройств мы собрали в одном месте. Теперь будем их анализировать и отправлять уведомления при каждом подключении к Mikrotik через Winbox. Я для этого сделал отдельный шаблон, где созданы элементы данных типа Журнал (лог) для анализа лог файла от каждого устройства.

Для каждого элемента данных есть триггер, который с помощью регулярного выражения анализирует лог файл и срабатывает тогда, когда видит строки с подключением к микротику через winbox. Имя триггера формируется таким образом, чтобы в нем была информация об имени пользователя и ip адрес, с которого он подключился.

Я не стал делать в шаблоне автообнаружение. Настраивал это в системах до 10-ти точек и мне банально было лень это делать, хотя и не сложно. Я просто копировал и исправлял итемы и триггеры, меняя ip адреса устройств. Для автообнаружения надо скрипт на сервер класть, который будет передавать список логов в мониторинг. А если руками делать, то можно все на сервере в шаблоне добавлять.

Итак, создаем простой итем.

К итему делаем триггер.

Mikrotik 10.1.3.110 auth {{ITEM.VALUE}.iregsub("account user (.*)via", "\1")}

{Template Mikrotik Logs:log[/var/log/mikrotik/10.1.3.111.log].str(logged in from,#1)}=1 and {Template Mikrotik Logs:log[/var/log/mikrotik/10.1.3.111.log].str(via winbox,#1)}=1

Вот и все. Прикрепляйте шаблон к хосту, на котором находится сам лог файл и проверяйте. В первую очередь смотрите, чтобы в Latest Data появилось содержимое лога.

Если триггеры настроены правильно, то при каждом подключении по Winbox вы будете получать уведомление на почту.

И еще одно после отключения.

Такой несложный механизм мониторинга за подключениями. Я отслеживаю именно подключения по winbox. Вы можете это изменить, добавив и другие типы подключения. Для этого надо изменить регулярное выражение в триггере.

Пример моего шаблона с двумя микротиками — zabbix-mikrotik-logs.xml. Если у вас много устройств, настройте автообнаружение лог файлов, чтобы автоматически создавать итемы и триггеры. Пример настройки автообнаружения в Zabbix можете посмотреть на примере мониторинга openvpn подключений. Там как раз показан очень похожий пример, когда анализируется список файлов в директории и передается в zabbix server.

На этом по мониторингу микротиков в Zabbix у меня все. По идее, рассмотрел все актуальные задачи по этой теме.

Заключение

Если у вас есть замечания или рекомендации по настройке мониторинга Mikrotik, делитесь в комментариях. Так же интересно узнать, есть ли еще какие-то полезные метрики, которые я упустил. Имея на руках лог файлы, можно настроить мониторинг абсолютно всех действий с микротиками. Но лично я не придумал, какая еще информация может быть полезна.

Мониторинг подключений и авторизаций в микротиках настроен в рамках построения простенькой самодельной системы информационной безопасности. Сюда можно будет добавить мониторинг за подключениями по ssh и openvpn. Затем свести все это в единый dashboard.

Так же может быть полезным настройка оповещений в telegram.

Онлайн курcы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курcы по программе, основанной на информации из официального курcа MikroTik Certified Network Associate. Помимо официальной программы, в курcах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте Курcы по ИТ.

Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курcов:

Знания, ориентированные на практику;
Реальные ситуации и задачи;
Лучшее из международных программ.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Время на прочтение

Эта статья посвящена особенностям мониторинга сетевого оборудования с помощью протокола SNMPv3. Мы поговорим об SNMPv3, я поделюсь своими наработками по созданию полноценных шаблонов в Zabbix, и покажу, чего можно добиться при организации распределенного алертинга в большой сети. Протокол SNMP является основным при мониторинге сетевого оборудования, а Zabbix отлично подходит для мониторинга большого количества объектов и обобщения значительных объемов поступающих метрик.

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

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

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

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

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

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

Настройка SNMPv3

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

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

snmp-server group snmpv3group v3 priv read snmpv3name
snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso included

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

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

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

snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5 md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56 des56v3v3v3

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

snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252

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

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

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

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

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

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

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

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

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

discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7]

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

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

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

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

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

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

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

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

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

Техническое задание

Имеется сеть географически разбросанных дата-центров с вагоном VRF и постоянно изменяющимся списком OSPF соседей. Необходимо отслеживать их:

Состояние, делать alarm если состояние соседа не FULL
Количество, то есть если сосед пропал, нужно также делать alarm

Система мониторинга уже есть — Zabbix 3.4, желательно использовать именно её, ОС Linux Debian 9.x

Пробуем с наскока

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

Вколачиваем в поиск «zabbix ospf» и первая же ссылка ведет на шаблон. Счастье то какое — сейчас я его импортирую, причешу под свои нужды и всё будет оки доки.
Проверяем как работает — вроде все хорошо, состояния отслеживаются, но вот когда сосед уходит в состояние DOWN, мы получаем от Zabbix «очень» информативное сообщение

No Such Instance currently exists at this OID

The item is not discovered anymore and will be deleted in 29d 23h 57m (on 2018-08-19 at 08:52)

Что произошло — проблема старая и известная на форумах — когда пропадает OSPF сосед, то все OID, связанные с ним, просто удаляются на сетевом железе.

Да, решение есть — создать триггер nodata, ок создаем:

{Template - SNMPv3 - OSPF Discovery:ospfNbrState[{#SNMPVALUE}].nodata(120)}=0

Видим в дашборде:

OSPF neighbor 192.168.192.168 missing data

Пробуем со второго наскока

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

С первых строк документация по мониторилке смутила длинным списком:

The workflow of receiving a trap: 1. snmptrapd receives a trap 2. snmptrapd passes the trap to SNMPTT or calls Perl trap receiver 3. SNMPTT or Perl trap receiver parses, formats and writes the trap to a file 4. Zabbix SNMP trapper reads and parses the trap file 5. For each trap Zabbix finds all “SNMP trapper” items with host interfaces matching the received trap address. Note that only the selected “IP” or “DNS” in host interface is used during the matching. 6. For each found item, the trap is compared to regexp in “snmptrap[regexp]”. The trap is set as the value of all matched items. If no matching item is found and there is an “snmptrap.fallback” item, the trap is set as the value of that. 7. If the trap was not set as the value of any item, Zabbix by default logs the unmatched trap. (This is configured by “Log unmatched SNMP traps” in Administration → General → Other.)

То есть один демон принимает TRAP, передает его другому демону, тот его парсит, кладет в лог с нужным форматом и забикс уже читает лог и принимает решение что делать дальше. Как-то уже выглядит ни разу не проще чем даже руками пройтись и везде нарисовать SNMP context, но да ладно, попробуем. Читаем внимательно доку по мониторилке и понимаем что только с её помощью ничего настроить не получится, вообще есть у Zabbix такой прикол — документация настолько минимально описывает возможности и нюансы системы, что скорее больше запутывает чем учат. Хотя их можно понять — софтина бесплатная, а деньги как-то надо зарабатывать, вот на поддержке и зарабатывают. В интернетах встречаются статьи с описанием как это настроить раз два, но ни по одной статье у меня не получилось настроить от и до, пришлось собирать информацию из разных источников по крупицам. Это всё лирика, погнали делать хардкор.

Настраиваем сетевую железку

Перед тем как что-то крутить на хосте с мониторилкой, настоятельно рекомендую первым делом настроить сетевую железку и убедиться что TRAP реально прилетает от железки на сервер — поначалу я этого не проверил, что выпило много нервов, крови и времени. У меня под рукой вагон Cisco Nexus, так что примеры буду приводить для этой серии. У кого Catalyst, ASR, ASA и прочее — извиняйте, я не солнышко, всех не обогрею, читайте доки как это настроить сами, синтаксис будет похож, но со своими нюансами.

snmp-server contact noc@example.com
snmp-server location Room1
snmp-server source-interface traps loopback1

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

snmp-server user Zabbix network-operator auth sha string priv aes-128 string

Используйте 3 версию протокола везде где только можно, в режиме authPriv (шифрование и аутентификация), это не так сложно настроить как кажется. Забудьте про 1 и 2 версии протокола — когда вам прилетит нежданчик по причине отсутствия шифрования и по сути аутентификации в этих версиях протокола — просто вопрос времени (community строка в них передается в открытом виде, более того регулярно вижу что это настроено public/private). Параметр network-operator позволяет дать права юзеру только на чтение.

snmp-server host 192.168.192.168 traps version 3 priv Zabbix
snmp-server host 192.168.192.168 use-vrf default
snmp-server host 192.168.192.168 source-interface loopback1
no snmp-server enable traps ospf lsa
snmp-server enable traps ospf
no snmp-server enable traps entity entity_mib_change
no snmp-server enable traps entity entity_module_status_change
no snmp-server enable traps entity entity_power_status_change
no snmp-server enable traps entity entity_module_inserted
no snmp-server enable traps entity entity_module_removed
no snmp-server enable traps entity entity_unrecognised_module
no snmp-server enable traps entity entity_fan_status_change
no snmp-server enable traps entity entity_power_out_change
no snmp-server enable traps link linkDown
no snmp-server enable traps link linkUp
no snmp-server enable traps link extended-linkDown
no snmp-server enable traps link extended-linkUp
no snmp-server enable traps link cieLinkDown
no snmp-server enable traps link cieLinkUp
no snmp-server enable traps link connUnitPortStatusChange
no snmp-server enable traps bfd session-up
no snmp-server enable traps link delayed-link-state-change
no snmp-server enable traps bfd session-down
no snmp-server enable traps rf redundancy_framework
no snmp-server enable traps license notify-license-expiry
no snmp-server enable traps license notify-no-license-for-feature
no snmp-server enable traps license notify-licensefile-missing
no snmp-server enable traps license notify-license-expiry-warning
no snmp-server enable traps upgrade UpgradeOpNotifyOnCompletion
no snmp-server enable traps upgrade UpgradeJobStatusNotify
no snmp-server enable traps rmon risingAlarm
no snmp-server enable traps rmon fallingAlarm
no snmp-server enable traps rmon hcRisingAlarm
no snmp-server enable traps rmon hcFallingAlarm
no snmp-server enable traps entity entity_sensor
no snmp-server enable traps generic coldStart
no snmp-server enable traps generic warmStart

Я специально отключил все TRAP кроме OSPF, чтобы при диагностике почему что-то не работает, мне не пришлось вычитывать из дебага много лишней информации.

Как проверить работают ли TRAP — очень просто — надо что-нибудь сломать. Стартуем снифер на хосте с мониторингом:

root@dc-zbx:~# tcpdump -i bond0 udp port 162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes

Находим на железке живых соседей:

SW# show ip ospf neighbors vrf all OSPF Process ID 10 VRF default Total number of neighbors: 4 Neighbor ID Pri State Up Time Address Interface 192.168.0.242 1 FULL/ - 01:47:17 172.17.0.10 Vlan1427 192.168.0.222 1 FULL/ - 18w1d 172.17.0.6 Vlan1426 192.168.1.149 1 FULL/ - 5w0d 172.17.0.30 Vlan1473 192.168.1.146 1 FULL/ - 3d00h 172.17.0.58 Vlan1404 OSPF Process ID 100 VRF OSPF100 Total number of neighbors: 4 Neighbor ID Pri State Up Time Address Interface 192.168.1.149 1 FULL/ - 5w0d 172.17.0.34 Vlan1474 192.168.0.220 1 FULL/ - 13w3d 172.17.0.54 Vlan1479 192.168.0.240 1 FULL/ - 13w3d 172.17.0.46 Vlan1477 192.168.1.146 1 FULL/ - 3d00h 172.17.0.62 Vlan1405 OSPF Process ID 200 VRF Dia Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 10.65.0.252 1 FULL/ - 17w2d 172.17.0.18 Vlan1450 172.17.0.26 1 FULL/ - 17w0d 172.17.0.26 Vlan1452 OSPF Process ID 216 VRF Dev Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 10.255.255.94 1 FULL/ - 18:59:59 10.216.0.73 Vlan1641 10.216.0.82 1 FULL/ - 18:59:54 10.216.0.82 Vlan1643

И уроним кого-нибудь

interface vlan 1643 shutdown

Видим в снифере:

11:08:20.001942 IP 192.168.192.169.22095 > dc-zbx.example.com.snmp-trap: F=ap U="Zabbix" [!scoped PDU]39_d1_7c_19_b3_d9_f8_31_32_8e_c9_39_c2_3a_db_d8_28_26_c6_0b_01_55_b6_fa_5e_f5_38_66_f9_6f_3f_c0_98_cb_57_93_5a_50_8e_50_90_79_f3_9b_ec_ec_d7_9f_e8_ac_f6_fd_79_ac_95_ff_71_73_32_70_52_66_a5_7d_b3_c4_39_d0_1c_7f_a6_38_ea_d7_61_c0_2f_12_ee_db_d9_07_40_8c_a8_48_57_e9_e5_56_12_3f_ec_f9_34_65_09_96_86_f6_d2_93_06_45_fa_95_ea_36_5a_82_2f_30_8f_02_03_59_07_5f_d8_a6_1c_f2_5a_be_7d_09_15_ef_05_00_83_fd_ea_ac_2a_3b_86_0f_86_e5_3b_93_3a_68_6d_33_99_e2_46_2b_9d_6a_1e_5d_9e_d9_93_56_51_5e_ff_9e_77_4c_cb

Если вы в снифере ничего не увидели, диагностируйте, потому что иначе смысла продолжать дальше никакого не будет, вы просто не поймете на каком из этапов у вас что-то не работает.
Если под рукой нет железки или нельзя трогать продакшен, то TRAP можно сгенерировать с любой другой тачки, например вот так:

snmptrap -v 1 -c neveruseme 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"
snmptrap -v3 -l authPriv -u Zabbix -a SHA -A abyrvalg -x AES -X pechka -e 0x8000000001020305 192.168.192.168 0 linkUp.0

Настройка SNMPd, SNMPTRAPd, SNMPTT

Нам понадобятся в системе пакеты:

apt install snmp snmp-mibs-downloader snmpd snmptrapd snmptt

Я не стал ориентироваться на Perl trap receiver, а выбрал SNMPTT по личным и субъективным причинам. Итак, в доке написано:

1. snmptrapd receives a trap

Начинать надо именно с его настройки, а не лезть сразу создавать Item в морде Zabbix. Почему так — нужно подниматься по тем же ступенькам, что идёт TRAP. В предыдущем разделе мы убедились что TRAP в принципе прилетает с железки, теперь мы будем добиваться того, чтобы он хотя бы был принят первым демоном — snmptrapd. <лирика> Помнится давно настраивал postfix+dovecot+еще чего-то там. И промудохался я недели две — там тоже один демон принимает коннект, другой парсит письмо, третий кладет его в очередь, четвертый в папку к юзеру и так далее, и у меня ничего не получалось. А всё потому, что настраивал то с середины, то с конца, то с начала, а надо было начать с телнета на 25 порт и просмотра дебага лисенера</лирика>

Лезем в /etc/snmp/snmptrapd.conf и удаляем, а лучше комментируем там всё что нам не понятно и не интересно, оставляем одну строку

disableAuthorization yes

systemctl stop snmptrapd.service

Запускаем в ручном режиме

root@dc-zbx:~# snmptrapd -f -Lo
NET-SNMP version 5.7.3 AgentX subagent connected
NET-SNMP version 5.7.3

Снова пробуем сломать OSPF как в примере выше и видим:

2018-07-20 11:38:38 UNKNOWN [UDP: [192.168.192.169]:22095->[192.168.192.168]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1355817272) 156 days, 22:09:32.72	SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfNbrStateChange	OSPF-MIB::ospfRouterId = IpAddress: 10.216.0.74	OSPF-MIB::ospfNbrIpAddr = IpAddress: 10.216.0.82	OSPF-MIB::ospfNbrAddressLessIndex = INTEGER: 0	OSPF-MIB::ospfNbrRtrId = IpAddress: 10.216.0.82	OSPF-MIB::ospfNbrState = INTEGER: down(1)

Если не видим, то ищем причину почему. Если вы хотите, чтобы у вас были такие же красивые записи, а не набор OID вида 1.3.6.1.2.1.14.10.1.6, то в /etc/snmp/snmp.conf добавьте следующее:

mibs +OSPF-MIB
mibs +OSPF-TRAP-MIB
mibs +OSPFV3-MIB
mibdirs +/usr/share/snmp/mibs/ietf/

И передерните SNMPd

systemctl restart snmpd.service

Теперь прикрутим аутентификацию, лезем снова в /etc/snmp/snmptrapd.conf

traphandle default snmptthandler
#disableAuthorization yes
# 192.168.192.169
createUser -e 0x80000009038d604a6a82a3 Zabbix SHA string AES
authuser log,execute,net Zabbix

-e 0x80000009038d604a6a82a3 — это engineID, его можно посмотреть на сетевой железке:

SW# sh snmp engineID
Local SNMP engineID: [Hex] 80000009038F604D6A82A1 [Dec] 128:040:000:109:003:140:096:079:106:131:160

Снова повторяем эксперимент, но теперь еще ловим дебаг касательно USM:

root@dc-zbx:~# snmptrapd -f -Lo -Dusm
registered debug token usm, 1
usmUser: created a new user Zabbix at 80 00 00 09 03 8F 60 4F 6B 82 A5
NET-SNMP version 5.7.3 AgentX subagent connected
NET-SNMP version 5.7.3
usm: USM processing begun...
usm: match on user Zabbix
usm: no match on engineID (80 00 00 09 03 8F 60 4F 6B 82 A5 )
usm: match on user Zabbix
usm: Verification succeeded.
usm: USM processing completed.
2018-07-20 11:50:07 UNKNOWN [UDP: [192.168.192.169]:22095->[192.168.192.168]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1355886163) 156 days, 22:21:01.63	SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfNbrStateChange	OSPF-MIB::ospfRouterId = IpAddress: 10.216.0.74	OSPF-MIB::ospfNbrIpAddr = IpAddress: 10.216.0.82	OSPF-MIB::ospfNbrAddressLessIndex = INTEGER: 0	OSPF-MIB::ospfNbrRtrId = IpAddress: 10.216.0.82	OSPF-MIB::ospfNbrState = INTEGER: down(1)

Если на этом этапе вы видите ошибки авторизации в дебаге, внимательно проверяйте engineID и что созданные на железке пользователи совпадают с теми, что мы нарисовали в конфиге /etc/snmp/snmptrapd.conf. Кстати да, для каждой железки придется создавать своего пользователя со своим engineID, или руками сделать его одинаковым на всех железках, если железки такое позволят сделать.

У меня в дебаге видно строчку:

usm: no match on engineID (80 00 00 09 03 8F 60 4F 6B 82 A5 )

Теперь беремся за SNMPTT — у него два конфига ini и conf. В первом определяем параметры работы самого демона, во втором определяем параметры получения и обработки каждого определённого трапа.

Лезем в файл /etc/snmp/snmptt.ini и рисуем следующие вещи:

mode = daemon
net_snmp_perl_enable = 1
date_time_format = %Y %m %d %H:%M:%S

Формат даты и времени дело хозяйское, главное используйте везде одинаковый.

log_file = /var/log/snmptt/snmptt.log
log_system_file = /var/log/snmptt/snmpttsystem.log
unknown_trap_log_enable = 1
unknown_trap_log_file = /var/log/snmptt/snmpttunknown.log

Почему лог не такой как во многих статьях в интернетах? Потому что в доке было сказано «If systemd parameter PrivateTmp is used, this file is unlikely to work in /tmp.», не хочу лишний раз вставать на грабли, если об этом заранее предупреждают, так что меняю сразу на нормальный путь до файла.

Далее идем в /etc/snmp/snmptt.conf, убираем всё что нам не нужно и/или не понятно, оставляем только это:

EVENT ospfNbrStateChange .1.3.6.1.2.1.14.16.2.2 "OSPF" Normal
FORMAT ZBXTRAP $aA OSPF neighbor with IP addr $2 changed state to $5

В таком виде потому, что Zabbix будет ожидать в логе именно такой формат. Откуда берутся $2 и $5 можно узнать если посмотреть формат TRAP сообщения, глядим:

Object	ospfNbrStateChange
OID	1.3.6.1.2.1.14.16.2.2
MIB	OSPF-TRAP-MIB ;
Trap Components	ospfRouterId	ospfNbrIpAddr	ospfNbrAddressLessIndex	ospfNbrRtrId	ospfNbrState

В ходе разборок со всем этим добром я заметил что после изменения настроек SNMPTT, как будто изменения не применяются. Оказалось что после их изменения надо рестартовать не snmptt.serivce, а snmpd.service — этот нюанс прилично попил моей крови и попилил нервов во время дебага.

Проверьте что у вас все демоны запущены:

systemctl status snmpd snmptrapd snmptt

Если всё ок, пробуем снова сломать OSPF и идем в лог /var/log/snmptt/snmptt.log, будет подобное:

2018 07 19 15:10:52 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to down
2018 07 19 15:12:28 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart
2018 07 19 15:12:34 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to full
2018 07 19 15:22:41 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to down
2018 07 19 15:25:38 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart

Те TRAP, которые мы не настроили в конфиге /etc/snmp/snmptt.conf попадут в лог /var/log/snmptt/snmpttunknown.log, но только от той железки, для которой настроен правильный юзер и engineID в этом же конфиге. То есть от левых железок TRAP будут просто silently dropped, если хочется матана и разбора полетов, то вам сюда — на редкость вменяемая дока по net-snmp, там еще неплохо описано различие между TRAP и INFORM, забегая вперед, лучше использовать INFORM, т. к. там какой-никакой контроль доставки есть, а SNMP он же по UDP работает.

И только теперь лезем настраивать нашу мониторилку.

Настройка Zabbix

Первым делом убедитесь, что в конфиге /etc/zabbix/zabbix_server.conf мониторилка натравлена на правильны лог SNMPTT и сам Zabbix запускает хотя бы один SNMP Trapper:

Для начала я создавал Item прямо на хосте, чтобы быстрее и проще ловить спецэффекты, сюда же напишу сразу как создать Template, потому что именно шаблонами надо пользоваться всегда когда это возможно. Покажу картинками, халява копи-пастинга закончилась, но покрашу места на которые нужно обратить внимание.

Тут просто даем вменяемое имя

Важно — ключ должен быть таким, то, что указано в квадратных скобках это то, что будет искать Zabbix в логе, формат лога мы настраивали в /etc/snmp/snmptt.conf и писали там:

EVENT ospfNbrStateChange .1.3.6.1.2.1.14.16.2.2 "OSPF" Normal
FORMAT ZBXTRAP $aA OSPF neighbor with IP addr $2 changed state to $5

Собственно в логе это волшебное слово «OSPF» и появляется:

2018 07 19 15:25:38 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart

Формат даты мы определяли в конфиге /etc/snmp/snmptt.ini:

date_time_format = %Y %m %d %H:%M:%S

О чем я и писал выше — используйте любой удобный вам формат, главное чтобы он совпадал в нужных местах.

Состояний у соседа может быть несколько:

1 : down
2 : attempt
3 : init
4 : twoWay
5 : exchangeStart
6 : exchange
7 : loading
8 : full

Вообще не принципиально в каком именно состоянии находится сосед, если это состояние не FULL, т. к. чтобы это продиагностировать, придется всё-равно идти на железку, читать логи, вводить какие-то команды. Так что триггер будет один и будет возбуждаться только когда в TRAP состояние соседа не FULL.

Прежде чем повесить шаблон на конкретный хост, убедитесь, что у хоста настроен корректный SNMP интерфейс с правильным IP адресом, иначе трапы будут в логе /var/log/snmptt/snmptt.log, но Zabbix их «не привяжет» к хосту. В этом случае в логе Zabbix сервера /var/log/zabbix/zabbix_server.log будет сообщение вида:

19972:20180720:091722.896 unmatched trap received from "192.168.192.169": 2018 07 20 09:17:21 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - OSPF neighbor with IP addr 10.64.0.10 changed state to exchangeStart

Идем в Latest data, видим

Триггер тоже сработал

Теперь положим двух соседей

В дашборде видим что случилось две проблемы, это хорошо, и даже два письма прилетит на эту тему при настроенном оповещении.

Всё здорово, всё работает, а вот и вишенка на торте в завершении.

UPD: коллеги по цеху посоветовали таки разобраться и попробовать реализовать задуманное с использованием SNMP contexts. Есть спрос, будет и предложение. Забегая вперед могу сказать — не так страшен черт, поехали.
На сетевой железке рисуем волшебную команду:

Было опасение, что после таких настроек у нас сломаются уже настроенные Item по SNMP с пустым контекстом, однако проверил — настройка затрагивает только отдачу данных по OSPF-MIB, при этом например из раздела IF-MIB всё продолжает отдаваться как и раньше с пустым контекстом. Если у вас не Nexus, рекомендую проверить этот момент лишний раз — вполне вероятно что поведение будет отличаться.

Теперь подкрутим шаблон в Zabbix.
Необходимо создать новое правило Discovery с указанием контекста:

Новый Item prototype тоже с указанием контекста

И два триггера — первый — для алярма в случае если сосед в любом состоянии кроме FULL:

и второй — если сосед пропал: