Мониторинг устройств по SNMP

Обзор

Сетевое оборудование — коммутаторы, маршрутизаторы, межсетевые экраны, ИБП, системы хранения, принтеры — опрашивает по SNMP subagent opagent-snmp. Это отдельный процесс, который супервизор агента скачивает, запускает и обновляет рядом с агентом на том же узле, поэтому опрос по SNMP можно обновлять и перезапускать, не трогая мониторинг самого узла.

Опрос идёт с узла, а не из кластера: сетевой доступ до оборудования нужен узлу, кластеру — нет.

По умолчанию subagent выключен. Опрос начинается, когда сделано и то и другое:

1. Subagent назначен на узлы в веб-интерфейсе администратора.
2. На узел положен файл конфигурации со списком устройств.

Без своего файла конфигурации процесс работает вхолостую и ничего не опрашивает.

Устройства опрашиваются раз в минуту. Все сэмплы одного цикла получают один timestamp, выровненный по минутной сетке, чтобы rate() по счётчикам не рвался от плавающей длительности опроса.

Включение

Назначение subagent

Subagent и его версия назначаются в разделе Админ → Агенты мониторинга → Сабагенты:

• Набор по умолчанию — то, что получает каждый узел без переопределения. Добавьте строку, выберите subagent (opagent-snmp), его версию и, если нужно, лимиты CPU (mCPU) и памяти (байт). В списке версий — те, что модуль опубликовал в хранилище инсталляции, поэтому новая версия появляется здесь после обновления модуля.
• Закреплённая версия — версии и лимиты, закреплённые за конкретным проектом или узлом. Закрепление приоритетнее набора по умолчанию.
• Состояние — то, что сообщают супервизоры: запущенная и желаемая версия subagent по каждому узлу.

Что такое subagent и как назначается его версия — в разделе Веб-интерфейс → Сабагенты.

Размещение конфигурации на узле

Subagent читает один YAML-файл из каталога конфигураций плагинов агента:

• каталог — plugins_config_dir из config.yaml агента, а если агент его не задал, /usr/local/<product>/etc/config.d/ (<product> — значение monitoring.agent.productName, по умолчанию okagent);
• файл — первый по глобу *.yaml, затем *.yml, у которого верхний ключ plugin равен snmp. Имя файла роли не играет;
• список устройств лежит под ключом config.

Каталог пересканируется раз в минуту, поэтому добавление, правка и удаление файла вступают в силу без перезапуска чего бы то ни было.

Минимальная конфигурация — одно устройство, один профиль аутентификации:

plugin: snmp              # по этому ключу subagent и находит свой файл
config:
  targets:
    - host: 192.168.1.1
  auths:
    default:              # профиль один, в таргете его можно не называть
      community: public
      version: 2

Конфигурация

Поля верхнего уровня

Ключ, которого нет в таблице, молча игнорируется.

Таргет

Профиль аутентификации

Автопоиск устройств

Автопоиск выполняется один раз, на первом цикле опроса. Найденные адреса становятся таргетами и проходят автоклассификацию, уже перечисленные в targets хосты пропускаются. Зонды идут профилем с именем discovery из auths, а если такого профиля нет — полями этой секции.

Проверка конфигурации

Конфигурация, при которой опрашивать нечего или опрашивать пришлось бы учётными данными, которые никто не выбирал, отвергается:

• нужен хотя бы один таргет либо непустой discovery.subnets;
• непустой auths обязателен, когда discovery.subnets пуст;
• у каждого таргета должен быть непустой host;
• targets[].auth должен называть ключ карты auths; таргет без auth принимается, только когда в auths ровно один профиль;
• scrape_timeout должен разбираться, и ни он, ни limit не могут быть отрицательными.

Версия SNMP не проверяется: неизвестная читается как v2c.

Пример с SNMPv3, автопоиском и явными модулями

plugin: snmp
config:
  scrape_timeout: 45s     # дедлайн основной фазы; без ключа дедлайна нет
  limit: 20000            # потолок рядов за цикл, по умолчанию 10000
  default_modules: [if_mib, system, lldp]
  auths:
    v3:
      version: 3
      username: monitor
      security_level: authPriv
      auth_protocol: SHA256
      password: <парольная фраза аутентификации>
      priv_protocol: AES256
      priv_password: <парольная фраза шифрования>
    ro: {community: public, version: 2}
  targets:
    - host: 10.0.0.1
      auth: v3            # профилей больше одного — имя обязательно
    - host: 10.0.0.2
      auth: ro
      modules: [if_mib, system]   # явный список: автоклассификации не будет
  discovery:
    subnets: [10.0.1.0/24]
    community: public     # профиль discovery соберётся отсюда

Автоклассификация устройств

У таргета без собственного modules на первом цикле запрашивается sysObjectID, и модули подходящего вендора добавляются к модулям по умолчанию. Правил 47, они заданы по префиксам enterprise OID и покрывают Cisco (включая WLC), Huawei, Juniper, Arista, MikroTik, Eltex, QTECH, Extreme, Allied Telesis, D-Link, Netgear, TP-Link, Zyxel, Ubiquiti, Ruckus, NEC IX, HPE и Aruba, Dell (и серверы, и Dell Networking), Fortinet, Palo Alto, Check Point, Sophos, F5, Citrix, Kemp, Brocade, NetApp, QNAP, Synology, APC и другие ИБП, а также принтеры.

Устройство, не ответившее на зонд, и устройство, чей префикс не совпал ни с одним правилом, остаются с модулями по умолчанию. Таргет с явным modules не классифицируется вовсе.

Метрики

То, что присылает subagent, — отдельный поток рядов со своими именами и лейблами; это не плагин netdev агента, и имена его метрик не переиспользуются. Справочник — в разделе Метрики агента → Subagent SNMP.

Лейблы

Имена метрик устройств — это имена объектов MIB (ifHCInOctets, sysUpTime, lldpRemSysName и так далее), они сохраняются как есть, а текстовые значения приходят info-метриками (ifType_info{ifType="…"} 1).

Собственные метрики subagent

Отдельного heartbeat-ряда нет: живость subagent — это time() - timestamp(snmp_build_info).

Карта инфраструктуры и список устройств

Опрошенные устройства — не только поток метрик: из них платформа строит список устройств проекта и его карту инфраструктуры. Обе страницы — в боковом меню проекта, Инфраструктура → Устройства и Инфраструктура → Карта; они появляются, когда администратор включил раздел инфраструктуры в настройках платформы, а интерфейс SNMP-инфраструктуры — в настройках проекта. И список, и карта пересобираются из рядов в хранилище раз в десять минут.

• Устройства. Устройство попадает в список, как только приходит его sysName, — по одной записи на опрашиваемый адрес. Что в этой записи написано — производитель, категория (коммутатор, маршрутизатор, файрвол, ИБП и так далее), расположение, контакт — читается из системных метрик самого устройства: sysObjectID, sysDescr, sysLocation, sysContact, а по сущностям ENTITY-MIB стек коммутаторов отличается от одиночного. На странице устройства к этому добавляются порты — статус, скорость, трафик, ошибки, дропы — и связи этого устройства.
• Карта. Связи между устройствами берутся из LLDP (lldpRemSysName, lldpRemChassisId, lldpRemPortId), а там, где LLDP молчит, — из CDP (cdpCacheDeviceId). Связь порта коммутатора с сервером даёт таблица коммутации (dot1dTpFdbPort): выученный на порту MAC сопоставляется с MAC-адресами, о которых отчитывается агент мониторинга сервера. Связью становится только порт, за которым ровно один сервер, поэтому аплинки и межкоммутаторные транки ложных связей не дают.
• Сосед по LLDP, который не опрашивается, всё равно получает собственную запись, в разделе «Обнаруженные устройства»: на карте он есть, метрик у него нет. Добавьте его адрес в targets — и он станет опрашиваемым устройством.

Устройство, чей sysName не приходил час, помечается устаревшим, а не появлявшееся тридцать дней — удаляется; со связями так же.

Дашборды

С модулем приезжают готовые дашборды по SNMP:

• SNMP Devices — парк устройств: все опрашиваемые устройства, их доступность и нагрузка.
• SNMP Device Detailed — одно устройство: системная информация, интерфейсы, их трафик и ошибки.

Разбор проблем

Начинать стоит с snmp_config_status: он приходит каждый цикл, даже когда опроса нет.

Требования

• Сетевой доступ с опрашивающего узла до оборудования по SNMP: UDP, порт 161. Собственные зонды subagent — зонд классификации по sysObjectID, автопоиск VLAN и сканирование подсетей — ходят только на порт 161.
• Учётные данные оборудования: community для SNMPv1 и v2c либо пользователь USM для SNMPv3.
• Опрос идёт с того узла, где установлен агент, поэтому значение имеет сетевой доступ узла, а не кластера.
• Для пер-VLAN опроса таблиц коммутации на оборудовании Cisco — пользователь SNMPv3 с доступом к SNMP-контекстам vlan-.