Мониторинг коммутаторов по SNMP и ICMP: что снимать
Мониторинг коммутаторов по SNMP часто начинают с графика трафика, а потом выясняется, что порт к серверу неделю сыпал ошибками или работал на 100 Мбит/с вместо гигабита, и график этого не показал. Ниже — минимальный набор объектов, которые стоит снимать с коммутаторов и роутеров, как проверить их через snmpwalk и где к SNMP нужно добавить обычный пинг.
Что снимать с коммутатора по SNMP
Основа почти для любого сетевого устройства — стандартная IF-MIB из RFC 2863. Объекты в ней индексируются номером интерфейса ifIndex, то есть на каждый порт свой набор значений.
— ifOperStatus (1.3.6.1.2.1.2.2.1.8) — фактическое состояние порта: up(1), down(2), testing(3), unknown(4), dormant(5), notPresent(6), lowerLayerDown(7).
— ifAdminStatus (1.3.6.1.2.1.2.2.1.7) — что задумал администратор. Порт выключен в конфигурации — норма; включён, а ifOperStatus равен down — выдернут кабель или умер линк.
— ifHCInOctets и ifHCOutOctets (1.3.6.1.2.1.31.1.1.1.6 и .10) — 64-битные счётчики байт, из них считается трафик.
— ifInErrors, ifInDiscards, ifOutErrors, ifOutDiscards (1.3.6.1.2.1.2.2.1.14, .13, .20, .19) — ошибки и отброшенные пакеты.
— ifHighSpeed (1.3.6.1.2.1.31.1.1.1.15) — скорость порта в Мбит/с; ifName и ifAlias — имя порта и его описание из конфигурации.
— sysUpTime (1.3.6.1.2.1.1.3.0) — время с запуска SNMP-агента устройства в сотых долях секунды.
Проверять лучше с той машины, которая будет опрашивать устройство, а не со своего ноутбука. Команды из net-snmp: snmpget -v2c -c КОМЬЮНИТИ АДРЕС SNMPv2-MIB::sysUpTime.0 вернёт аптайм, snmpwalk -v2c -c КОМЬЮНИТИ АДРЕС IF-MIB::ifOperStatus — состояние всех портов. Таймаут обычно означает неверную community, закрытый UDP/161 на пути или ограничение доступа по адресу на самом устройстве.
Почему ifInOctets врёт на гигабитных портах?
Старые ifInOctets и ifOutOctets 32-битные и переполняются примерно на 4,3 ГБ. На полностью загруженном гигабитном порту это около 34 секунд: при опросе раз в минуту счётчик успевает обернуться больше одного раза, и график показывает заниженную загрузку. Поэтому RFC 2863 требует 64-битные счётчики байт для интерфейсов быстрее 20 Мбит/с, а начиная с 650 Мбит/с — и 64-битные счётчики пакетов.
Трафик считаем только по ifHCInOctets и ifHCOutOctets. Тип Counter64 есть в SNMPv2c и v3, но не в SNMPv1, так что опрос по первой версии 64-битных счётчиков не вернёт. Загрузка канала в процентах — скорость прироста счётчика, умноженная на 8 и делённая на ifHighSpeed, умноженный на миллион.
Ошибки портов, CPU и аптайм
Абсолютное значение ifInErrors ничего не говорит: счётчик копится с последней перезагрузки. Смотреть нужно на скорость прироста. Если ошибки растут на одном порту, почти всегда виновата физика: кабель, патч-корд, трансивер, рассогласование дуплекса. Если на всех портах сразу — смотрите на само устройство.
Discards — пакеты без ошибок, которые устройство всё равно отбросило, чаще всего из-за переполнения буферов. Рост ifOutDiscards на порту к серверу — признак того, что канал упирается в ёмкость, даже если средний график выглядит спокойно. И сравнивайте ifHighSpeed с ожидаемой скоростью: аплинк, согласовавшийся на 100 Мбит/с, работает, и по статусу порта этого не видно.
sysUpTime — детектор перезагрузок: значение стало меньше предыдущего, значит устройство перезапускалось (примерно через 497 суток счётчик переполняется и сбрасывается сам). CPU и памяти в IF-MIB нет: часть устройств отдаёт их через HOST-RESOURCES-MIB (hrProcessorLoad, 1.3.6.1.2.1.25.3.3.1.2), остальные — через частные MIB производителя. Высокий CPU на коммутаторе часто означает петлю или широковещательный шторм.
Зачем пинг, если есть SNMP?
Многие устройства в сети SNMP не умеют: IP-камеры, принтеры, контроллеры, датчики, терминалы. Для них единственная проверка — отвечают ли они по сети. ICMP даёт доступность и время ответа, а рост задержки до шлюза филиала часто заметен раньше обрыва. Для коммутаторов пинг — второй сигнал: не отвечают и SNMP, и пинг — устройство или путь до него недоступны; только SNMP — проблема в агенте устройства, настройках доступа или самом опросе.
Ещё одну ловушку мы разбирали в статье почему алерт молчит, когда база упала: правило «устройство не отвечает» срабатывает, только когда метрика есть и равна нулю. Если упал сам опрашивающий процесс, метрики нет, и правило молчит. Нужен отдельный алерт на «настроено, но данных нет».
Опрос из разных подсетей и карта сети
Коммутаторы в филиалах, за NAT или в изолированных VLAN с центрального сервера мониторинга часто не видны, а открывать SNMP наружу нельзя: в SNMPv2c community передаётся открытым текстом. Надёжнее опрашивать изнутри каждой площадки и привязывать устройство к узлу, из чьей сети оно доступно, иначе рабочий коммутатор будет числиться недоступным. Как это устроено у нас, описано в документации по мониторингу сети через SNMP.
Под картой сети понимают две разные вещи. Физическая топология — какой порт куда воткнут — строится по таблицам соседей LLDP или CDP, которые тоже читаются по SNMP. Логическая карта показывает, какие хосты и адреса реально обмениваются трафиком. В Voltir сделана вторая: карта сети строится по сетевым метрикам агентов, а устройства из разделов SNMP и пинга подписаны на ней своими именами.
Что проверить у себя
— Трафик считается по ifHCInOctets и ifHCOutOctets, а не по 32-битным счётчикам.
— Есть алерт на падение порта (ifOperStatus down при ifAdminStatus up) для аплинков и портов к серверам, без пользовательских портов, которые гаснут каждый вечер.
— Ошибки и discards оцениваются по скорости прироста, а не по накопленному значению.
— Скорость аплинков (ifHighSpeed) совпадает с ожидаемой.
— Перезагрузка устройства приходит алертом по сбросу sysUpTime.
— snmpwalk работает с хоста, который реально опрашивает устройство.
— Read-only community — отдельная, не public, и SNMP разрешён только с адреса опрашивающего хоста.
— Есть алерт «настроено, но не опрашивается» отдельно от «не отвечает».
— Устройства без SNMP проверяются хотя бы пингом.
— Кто-то видит алерты ночью и в выходные; если некому, дежурство можно отдать на мониторинг как услугу.
SNMPv2c или SNMPv3 — что выбрать?
SNMPv2c поддерживается практически везде, но community идёт без шифрования, поэтому его стоит использовать только в доверенной сети, с read-only community и ограничением по адресу. SNMPv3 с моделью безопасности USM из RFC 3414 добавляет аутентификацию и шифрование. Если опрос идёт через сегменты, которым вы не доверяете, выбирайте v3.
Как часто опрашивать коммутаторы?
Для статусов портов и трафика обычно хватает интервала от 30 секунд до минуты: с 64-битными счётчиками переполнение не грозит, а частый опрос больших таблиц интерфейсов нагружает процессор устройства. Если вы уходите с Zabbix, не переносите шаблоны целиком — начните с объектов из этой статьи; подробнее о переезде на странице про альтернативу Zabbix.
Как это сделано в Voltir
Коммутаторы, роутеры и NAS опрашивает агент внутри сети клиента по SNMP v2c (профиль if_mib или расширенные для MikroTik, Synology, Ubiquiti), устройства без SNMP пингуются раз в 30 секунд, каждое можно привязать к агенту своей подсети, а алерты «не отвечает» и «настроено, но не опрашивается» включены сразу. Трафик по портам, ошибки, статусы интерфейсов и аптайм можно посмотреть на живом демо.
Сколько SNMP-устройств входит в каждый тариф, указано на странице тарифов.