Проект мониторинга сетевых фабрик (условный Huawei) в дата-центрах был инициирован в связи с началом использования оборудования нового вендора. Опыт мониторинга оборудования другого вендора (условные Cisco) уже имелся, но в нем были моменты, которые нас не устраивали. И раз уж шаблон нужно переписывать с нуля под нового вендора, то почему бы не попробовать его улучшить. Сказано сделано. Сначала определим, что именно нам не нравиться в существующем подходе.

**Проблемы существующего подхода ** Мониторинг организован путем периодического опроса оборудования по протоколу SNMP А это значит: 1.     Высокая нагрузка на систему: Для проверки состояния всех интерфейсов, сессий BGP, BFD и т.д. генерируется большое количество запросов, что нагружает как систему мониторинга, так и само оборудование.           2.     Промежутки опроса: Хоть запросов и много, но все равно существует промежуток времени, когда оборудование не опрашивается, а значит есть вероятность упустить плавающую проблему или потратить много времени на её выявление. 3.     Задержка в обнаружении неисправностей: Если какой-нибудь элемент данных опрашивается раз в 5 минут и проблема происходит через несколько секунд после последнего опроса, то ближайшие 5 минут мы будем уверены, что все хорошо, хотя на деле может быть иначе. 4.     Проблемы с потерей данных: Если отвалится какая-то часть оборудования (модуль, плата расширения и т.д.), то вместе с ней пропадет и часть ветки MIB, данные перестанут поступать и для выявления таких аварий потребуется составление более сложных проверок.

Что делать? Решение: комбинированный подход Пусть оборудование само сообщает, когда с ним что-то происходит не так. Полностью уйти от модели опроса оборудования не получится, и, например, если оборудование перестанет быть доступно совсем оно нам уже ничего не сообщит. Но вполне можно комбинировать эти 2 подхода, а именно часть метрик мы продолжим собирать периодически опрашивая оборудование, а часть метрик оборудование будет отправлять нам самостоятельно.

**Преимущества комбинированного подхода **1.     Снижение нагрузки: Уменьшение количества запросов к оборудованию и системе мониторинга. 2.     Выявление плавающих проблем: Ускоренное обнаружение проблем, которые могут возникать между опросами. 3.     Оперативное реагирование: получать информацию о недоступности части оборудования и реагировать на нее простыми триггерами без использования сложной логики.

**Реализация

**Итак, активная часть, с опросом по SNMP нам уже знакома, что насчет пассивной части и получения информации от оборудования в момент совершения события.

Тут есть варианты:

• собирать по rsyslog логи с оборудования, где-нибудь на удаленном сервере и системой мониторинга парсить логи
• напрямую получать TRAP сообщения от оборудования в системе мониторинга

Решили выбрать вариант номер 2, т.к. он более стандартизирован и описан в документации вендора. Здесь я немного слукавил про то, что сообщения мы будем получать прямо в системе мониторинга, все же из коробки так сделать не получится и нам потребуется прослойка, которая эти самые сообщения будет ловить и складывать в файлик, а мы уже будем парсить этот файлик и выдергивать нужные сообщения для узлов в нашей системе мониторинга. Так что второй способ технологически не сильно отличается от первого, но все же более стандартизирован.

В качестве ловца сообщений будем использовать SNMPTrapd.

Документации в сети по настройке TRAP достаточно, настраиваем… Но в процессе настройки и тестирования понимаем следующее, во всех манах и документациях сказано - _прописываем в настройках snmptrapd уникальный идентификатор оборудования (engine ID) и получаем от него сообщения.

_Вот здорово, для 1 железки прописать этот ID не сложно, а если железок 100+ и будут добавляться новые или меняться? Встает вопрос об актуальности списка engine ID и своевременного его обновления.

Эх.. ладно пишем костыли чтобы раз в день опрашивать все оборудование и получать актуальные engine ID и править их список. Но параллельно ищем более простое в масштабировании решение и ... находим!