Zabbix + SNMP v2c: восемь коммутаторов Cisco под наблюдением и один подозрительный порт

Когда мы переводили первого клиента на Zabbix в апреле, основной мотив был простой: один инструмент вместо двух. Серверы подхватились нормально. Но коммутаторы тогда добавили по минимуму - ping и доступность по SNMP, не более. Дошли руки до нормальной настройки мониторинга сетевого оборудования только сейчас.

Что было до этого

Несколько лет назад мы настраивали Cacti для графиков трафика на интерфейсах. Работало, но только трафик - сколько мегабит входит/выходит. Это полезно, но это верхушка. Коммутатор - не просто трубопровод: у него есть температура, ошибки на портах, состояние питания, загрузка CPU. Ничего из этого мы не видели.

Объект - офисная сеть среднего размера, восемь коммутаторов Cisco Catalyst. Часть стоит в серверной, часть распределена по этажам. Сеть под сопровождением, то есть за её состояние отвечаем мы.

SNMP v2c на Cisco: что включили

На каждом коммутаторе включили SNMP community только на чтение, прописали ACL чтобы опрашивать мог только наш сервер мониторинга. Использовали v2c - он поддерживается всеми Catalyst из этого парка, v3 с аутентификацией и шифрованием на части оборудования требует дополнительной возни с конфигом, а для внутреннего мониторинга закрытой сети v2c с нормальным ACL - приемлемый компромисс.

Стандартные MIB которые используем:

• IF-MIB - состояние интерфейсов, скорость, дуплекс, счётчики октетов
• IF-MIB ifInErrors / ifOutErrors - ошибки на входе и выходе портов
• CISCO-ENVMON-MIB - температура, состояние блока питания, вентиляторов
• RFC1213-MIB (sysDescr, sysUpTime) - базовая информация об устройстве

На Zabbix-стороне - шаблон для Cisco Catalyst, который мы собрали на основе существующих community-шаблонов плюс несколько кастомных OID для температуры и ошибок. Авто-обнаружение (Low Level Discovery) в Zabbix 1.4 позволяет не прописывать каждый порт вручную: шаблон сам опрашивает IF-MIB, находит все интерфейсы и создаёт для них items и триггеры.

Что мониторим по каждому коммутатору

На каждый коммутатор теперь вешается несколько групп проверок:

По устройству в целом. Доступность (ping + SNMP), uptime, температура CPU и корпуса, состояние блока питания. Триггер на температуру настроили с двумя уровнями: WARNING и CRITICAL. На Catalyst в серверной температура стабильная, на этажных - чуть выше из-за менее аккуратного размещения, пороги выставили с учётом этого.

По каждому порту. Состояние up/down, скорость, дуплекс, счётчики трафика, счётчики ошибок - CRC, input errors, output drops. Триггер на смену состояния uplink-портов настроен с приоритетом HIGH - если умирает аплинк на этажный коммутатор, это проблема сразу для нескольких десятков пользователей.

Ошибки как отдельная история. Ненулевые CRC и input errors на порту - это уже сигнал. Несколько ошибок за сеанс - бывает, норма жизни. Постоянный рост счётчика - другая история.

Как нашли повреждённый кабель

Через несколько дней после включения мониторинга один из триггеров на ошибки начал периодически срабатывать. Не alarm, а именно периодически: счётчик CRC на одном из портов третьего этажа рос, не быстро, но стабильно. Порт был в состоянии up, трафик шёл, пользователь за этим ПК работал и ни на что не жаловался.

Пошли смотреть физику. Патч-корд от розетки до ПК на вид нормальный. Позвали кабельщика, прозвонили - пара в кабеле оказалась с дефектом. Видимо, кто-то неудачно придавил или перегнул. Сигнал проходил, но с потерями, которые коммутатор фиксировал как CRC-ошибки.

Кабель заменили. Счётчик ошибок на порту перестал расти.

Без мониторинга этот сценарий выглядит иначе: пользователь начинает замечать что что-то «медленно», «лагает», «страница долго грузится». Жалоба доходит до нас через несколько дней или не доходит вообще - люди привыкают и не жалуются. Или жалуются не на сеть, а на «тупой компьютер». Потом приходит техник, смотрит ПК, не находит причину, уходит. Кто-то в итоге замечает что виснет именно при работе с сетью. И так далее - классическая история поиска иголки в стоге сена.

Здесь мы пришли с конкретным портом и конкретной проблемой.

Что ещё всплыло при настройке

Два коммутатора на этажах оказались с неправильно выставленным дуплексом на аплинк-порту - half вместо full. С трафика это никак особо не читалось, зато в счётчиках output drops иногда мелькали. Поправили.

Один коммутатор показывал температуру на несколько градусов выше нормы - оказалось, вентиляционные отверстия частично закрыты наклеенными бумажками (кто-то лепил инвентарные метки). Мелочь, но без мониторинга температуры мы бы про это не узнали до первого перегрева.

Итого

Полноценный SNMP-мониторинг коммутаторов - это не экзотика и не избыточность. Это другой уровень информации о состоянии сети: не «доступен/недоступен», а что именно происходит внутри. CRC-ошибки, температура, дуплекс-мисматч - всё это читается из SNMP без агентов, без доп. доступа на устройство, просто регулярным опросом по стандартному протоколу.

Шаблон для Catalyst допиливаем - часть OID под конкретные версии IOS ведут себя чуть иначе, но базовые проверки уже работают стабильно. Следующий шаг - добавить мониторинг маршрутизаторов и посмотреть что интересного можно вытащить оттуда через BGP MIB.