Мониторинг сети через SNMP. Настройка Zabbix, LibreNMS и Prometheus

Коммутатор отвечает на ping, сервер доступен, интернет формально работает, но сотрудники жалуются на медленную сеть. Администратор проверяет соединения и обнаруживает, что один порт загружен почти полностью, другой постоянно отбрасывает пакеты, а процессор маршрутизатора уже полчаса работает на пределе.

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

Настроим мониторинг на реальных примерах. Сначала запустим SNMP-агент на Linux через Net-SNMP, затем подключим коммутатор и соберём показатели в Zabbix, LibreNMS и Prometheus. Разберём графики, интервалы опроса, пороговые уведомления и ошибки, из-за которых система либо не видит оборудование, либо показывает неправильные значения.

Сразу определимся с выбором. LibreNMS удобнее для быстрого мониторинга сетевого оборудования, Zabbix лучше подходит для всей ИТ-инфраструктуры, а Prometheus со snmp_exporter разумнее использовать там, где уже построена система сбора метрик. Все три решения бесплатны и поддерживают SNMP, но требуют разного подхода к настройке и сопровождению.

Как работает SNMP-мониторинг и какие показатели собирать

SNMP, или Simple Network Management Protocol, представляет собой протокол, с помощью которого система мониторинга получает сведения о состоянии сетевых устройств. На оборудовании работает SNMP-агент, а Zabbix, LibreNMS или другой менеджер периодически отправляет запросы и сохраняет полученные значения.

В обычной конфигурации агент принимает запросы на UDP-порту 161. Уведомления SNMP Trap и Inform отправляются получателю, обычно на UDP-порт 162. Для приёма уведомлений требуется отдельная настройка соответствующего обработчика.

                 СЕРВЕР МОНИТОРИНГА
               Zabbix / LibreNMS
                        |
                        | SNMP, UDP 161
                        |
             +----------+----------+
             |          |          |
          Linux      Коммутатор  Маршрутизатор
          snmpd       SNMP       SNMP
             |          |          |
            CPU        Порты      Трафик
            RAM        Ошибки     Нагрузка
            Диски      Скорость   Датчики
 
 
                  PROMETHEUS
 
               Prometheus
                   |
                   | HTTP
                   v
              snmp_exporter
                   |
                   | SNMP, UDP 161
                   v
             Сетевые устройства

Каждый доступный показатель имеет числовой идентификатор OID. Описание показателя, его тип и расположение в дереве идентификаторов определяются через MIB, Management Information Base.

Например, OID 1.3.6.1.2.1.1.3.0 позволяет получить время работы подсистемы управления SNMP, а ветка IF-MIB содержит сведения о сетевых интерфейсах. Для обращения к определённому порту используется индекс ifIndex.

Показатель	OID	Практическая польза
Время работы SNMP	1.3.6.1.2.1.1.3.0	Обнаружение перезапуска подсистемы управления
Административное состояние порта	1.3.6.1.2.1.2.2.1.7	Проверка, разрешена ли работа интерфейса
Фактическое состояние порта	1.3.6.1.2.1.2.2.1.8	Обнаружение отключения соединения
Полученные байты	1.3.6.1.2.1.31.1.1.1.6	Расчёт входящего трафика
Отправленные байты	1.3.6.1.2.1.31.1.1.1.10	Расчёт исходящего трафика
Ошибки приёма	1.3.6.1.2.1.2.2.1.14	Поиск проблем передачи данных
Отброшенные входящие пакеты	1.3.6.1.2.1.2.2.1.13	Обнаружение потерь внутри устройства
Номинальная скорость интерфейса	1.3.6.1.2.1.31.1.1.1.15	Расчёт загрузки порта
Загрузка Linux	1.3.6.1.4.1.2021.10	Контроль load average через Net-SNMP
Простой CPU Linux	1.3.6.1.4.1.2021.11.11.0	Оценка занятости процессора

SNMP обычно возвращает не готовую скорость соединения, а накопленный счётчик байтов. Чтобы получить среднюю скорость, система сравнивает два значения, делит разницу на время между опросами и умножает результат на восемь.

Скорость, бит/с =
 
 (Счётчик_2 - Счётчик_1) * 8
 --------------------------------
      Время между опросами

Если за 60 секунд счётчик вырос на 450 миллионов байтов, средняя скорость составила 60 Мбит/с.

Для современных интерфейсов выбирайте 64-битные счётчики ifHCInOctets и ifHCOutOctets. Старые 32-битные счётчики способны переполняться за десятки секунд на гигабитных соединениях. При высокой нагрузке мониторинг может неверно рассчитать скорость, особенно если между опросами счётчик успел переполниться несколько раз.

Состояние портов тоже требует правильной интерпретации. Значение ifOperStatus=1 означает, что интерфейс работает. Значение 2 соответствует состоянию down. Существуют и другие состояния, включая testing, dormant и lowerLayerDown. Поэтому правило, которое проверяет исключительно значение 2, способно пропустить некоторые виды отказов.

Не путайте ifOperStatus с ifAdminStatus. Первый показывает фактическое состояние, второй сообщает, разрешена ли работа интерфейса администратором. Если порт специально отключили в конфигурации, отправлять аварийное уведомление обычно бессмысленно.

С загрузкой процессора, оперативной памятью и температурой всё сложнее. Стандартные MIB не гарантируют одинакового набора таких показателей на оборудовании разных производителей. Некоторые устройства используют собственные ветки OID, другие не предоставляют нужные значения вообще.

SNMP не измеряет все характеристики сети. По обычным счётчикам нельзя узнать, какое приложение заняло канал, определить источник каждого пакета или достоверно измерить задержку передачи до конкретного сервиса. Для анализа потоков используются NetFlow, sFlow и IPFIX, для задержек и потерь применяют ICMP, активные проверки и специализированные измерения.

Настраивайте SNMP только на собственном оборудовании или устройствах, которыми имеете право управлять. Для рабочей инфраструктуры выбирайте SNMPv3 в режиме authPriv, отдельные учётные записи только на чтение и доступ исключительно из управляющей сети. Открытый SNMPv1 или SNMPv2c может раскрывать сведения об инфраструктуре и использоваться для усиления DDoS-атак.

Настройка SNMP на Linux и сетевом оборудовании

Для практики понадобится Linux-сервер с установленными Debian или Ubuntu, управляемый коммутатор и сервер мониторинга. Zabbix, LibreNMS и Prometheus можно установить на разные машины, но в лабораторном примере разместим системы сбора на одном узле.

Используем следующую схему адресации.

Устройство	IP-адрес	Назначение
Сервер мониторинга	10.20.0.10	Zabbix, LibreNMS, Prometheus
Linux-сервер	10.20.0.20	SNMP-агент Net-SNMP
Коммутатор	10.20.0.1	SNMP-агент сетевого оборудования

Адреса приведены для примера. В собственной сети замените значения на реальные управляющие IP.

Устанавливаем Net-SNMP на Linux

В Debian и Ubuntu агент предоставляет пакет snmpd, а пакет snmp содержит утилиты snmpget, snmpwalk и другие инструменты диагностики.

sudo apt update
 sudo apt install -y snmpd snmp
 
 systemctl status snmpd

Проверьте, где агент принимает запросы.

sudo ss -lunp | grep ':161'

Если служба слушает только 127.0.0.1, удалённый сервер мониторинга подключиться не сможет. Такое поведение часто встречается в исходных конфигурациях Debian и Ubuntu.

Создаём пользователя SNMPv3

SNMPv3 поддерживает несколько уровней безопасности. Для нового развёртывания выбирайте authPriv, который предусматривает аутентификацию и шифрование.

В примерах используется SHA-1 для аутентификации и AES-128 для шифрования. Такое сочетание широко поддерживается сетевым оборудованием, но SHA-1 относится к устаревающим криптографическим алгоритмам. Если устройство, версия Net-SNMP и система мониторинга совместимы с SHA-256, предпочтительнее выбрать SHA-256. Нельзя просто включить новый алгоритм с одной стороны, поскольку настройки должны совпадать.

Остановите агент и сохраните конфигурацию.

sudo systemctl stop snmpd
 
 sudo cp /etc/snmp/snmpd.conf 
   /etc/snmp/snmpd.conf.backup

Создайте пользователя с правами только на чтение.

sudo net-snmp-create-v3-user 
   -ro -a SHA -x AES snmpmon

Утилита запросит пароль аутентификации и пароль шифрования. Используйте разные длинные случайные парольные фразы. Пароли должны соответствовать ограничениям Net-SNMP и выбранных криптографических алгоритмов.

Синтаксис параметров утилиты в разных пакетных сборках Net-SNMP может различаться, поэтому при ошибке проверьте локальную справку через net-snmp-create-v3-user --help. В частности, не перепутайте параметры выбора алгоритма с параметрами передачи парольной фразы.

Утилита создаёт учётную запись в постоянной конфигурации Net-SNMP и правило доступа на чтение. На Debian и Ubuntu постоянные данные обычно находятся в каталоге /var/lib/snmp.

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

Ограничиваем сетевой доступ

Откройте файл настроек агента.

sudo nano /etc/snmp/snmpd.conf

Для лабораторного Linux-сервера можно использовать минимальную конфигурацию.

agentAddress udp:10.20.0.20:161
 
 sysLocation ServerRoom
 sysContact admin@example.local
 
 rouser snmpmon priv

Параметр agentAddress определяет интерфейс, на котором SNMP-агент принимает запросы. Правило rouser snmpmon priv разрешает пользователю snmpmon читать SNMP-объекты только при использовании уровня безопасности authPriv.

Если команда создания пользователя уже добавила строку rouser, замените существующее правило, а не создавайте второе с другими условиями доступа.

Проверьте конфигурацию на наличие старых правил доступа с community public или private. Удалите либо отключите ненужные rocommunity, rwcommunity и другие широкие разрешения.

В приведённом примере пользователь получает доступ на чтение к доступному дереву OID. Для промышленной инфраструктуры лучше дополнительно ограничить SNMP-представление через механизм VACM, оставив только необходимые ветки MIB. Некоторые системные и расширенные OID способны раскрывать сведения о программном обеспечении и конфигурации сервера.

Запустите службу.

sudo systemctl enable --now snmpd
 sudo systemctl restart snmpd
 
 sudo ss -lunp | grep ':161'

Если сервер защищён UFW, разрешите входящие запросы только от сервера мониторинга.

sudo ufw allow from 10.20.0.10 
   to any port 161 proto udp

Правило не заменяет проверку существующей политики межсетевого экрана. Если UFW отключён или доступ разрешён более широкими правилами, добавленная строка сама по себе не гарантирует изоляцию SNMP.

При наличии отдельных Zabbix Proxy, LibreNMS Poller или snmp_exporter разрешите адреса фактических источников запросов, а не только центрального веб-сервера.

Проверяем SNMP-запросы

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

Чтобы не вводить пароли в каждом вызове snmpget и не оставлять их в аргументах процесса, создайте защищённый пользовательский файл настроек SNMP-клиента.

mkdir -p ~/.snmp
 chmod 700 ~/.snmp
 
 nano ~/.snmp/snmp.conf

Добавьте параметры доступа.

defVersion 3
 defSecurityName snmpmon
 defSecurityLevel authPriv
 
 defAuthType SHA
 defPrivType AES
 
 defAuthPassphrase AUTH_PASSWORD
 defPrivPassphrase PRIV_PASSWORD

Замените AUTH_PASSWORD и PRIV_PASSWORD реальными парольными фразами. Для SHA-256 нужно также указать поддерживаемое клиентом имя соответствующего алгоритма.

Ограничьте доступ к файлу.

chmod 600 ~/.snmp/snmp.conf

Такой файл подходит для отдельной защищённой административной учётной записи. Не сохраняйте его в общем домашнем каталоге, резервной копии без шифрования или репозитории Git.

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

snmpget 10.20.0.20 
   1.3.6.1.2.1.1.3.0

При успешном ответе Net-SNMP вернёт значение типа Timeticks, например время работы подсистемы управления в сотых долях секунды с человекочитаемым представлением.

Проверьте таблицу сетевых интерфейсов.

snmpwalk -On 10.20.0.20 
   1.3.6.1.2.1.31.1.1.1.1

Команда возвращает имена интерфейсов, если агент предоставляет ifName. Через стандартную таблицу можно также посмотреть их фактическое состояние.

snmpwalk -On 10.20.0.20 
   1.3.6.1.2.1.2.2.1.8

Для проверки процессора Linux используется ветка UCD-SNMP-MIB.

snmpwalk -On 10.20.0.20 
   1.3.6.1.4.1.2021.11

Например, показатель ssCpuIdle характеризует процент времени простоя CPU. Приблизительная загрузка процессора равна 100 минус ssCpuIdle. Не путайте такую оценку с load average, которое характеризует нагрузку системы иначе и не выражается в процентах.

Если все запросы возвращают значения, Net-SNMP готов к подключению системы мониторинга.

Настраиваем SNMP на коммутаторе или маршрутизаторе

Для сетевого оборудования принцип похож, но команды зависят от производителя. Нужно включить SNMPv3, создать пользователя, разрешить чтение нужных MIB и ограничить адреса менеджеров.

Для Cisco IOS и некоторых версий IOS XE базовая конфигурация выглядит следующим образом.

configure terminal
 
 ip access-list standard SNMP_POLLERS
  permit 10.20.0.10
  exit
 
 snmp-server view SNMP_READ iso included
 
 snmp-server group NMS v3 priv 
  read SNMP_READ access SNMP_POLLERS
 
 snmp-server user snmpmon NMS v3 
  auth sha AUTH_PASSWORD 
  priv aes 128 PRIV_PASSWORD
 
 snmp-server location ServerRoom
 snmp-server contact admin@example.local
 
 end
 copy running-config startup-config

Символы обратной косой черты в примере показывают перенос длинных строк для публикации. В консоли Cisco соответствующие команды нужно вводить одной строкой.

Созданная группа NMS разрешает чтение через указанное SNMP-представление и ограничивает доступ списком SNMP_POLLERS. Разрешение на запись отдельно не предоставляется. Представление iso включает широкое дерево MIB, поэтому для оборудования с чувствительными управляющими OID его следует сузить.

Синтаксис SNMP-команд, правила применения ACL и поддерживаемые криптографические алгоритмы могут отличаться между моделями и версиями IOS. Перед использованием на работающем коммутаторе проверьте команды на своей платформе. Также убедитесь, что исходная конфигурация не содержит старых разрешений SNMPv1 и SNMPv2c, доступных из других сегментов сети.

На MikroTik, Huawei, HPE, Juniper и других устройствах SNMPv3 настраивается через соответствующий интерфейс или собственный CLI. Общими остаются пользователь, уровень authPriv, алгоритмы, пароли и ограничения источников запросов.

После настройки проверьте коммутатор с сервера мониторинга.

snmpwalk -On 10.20.0.1 
   1.3.6.1.2.1.31.1.1.1.1

Полученный список позволит сопоставить SNMP-индексы с интерфейсами оборудования. Например, физическому порту GigabitEthernet1/0/1 может соответствовать индекс 10101, а не 1. Поэтому никогда не предполагают, что номер порта на корпусе совпадает с ifIndex.

Если оборудование поддерживает только SNMPv2c, используйте случайную community, права только на чтение и изолированную управляющую сеть. SNMPv2c не обеспечивает шифрование и не подходит для передачи учётных данных через недоверенные сети.

Zabbix и LibreNMS. Настраиваем графики и уведомления

Zabbix. Подключаем устройство через SNMP

Zabbix объединяет мониторинг сетевого оборудования, Linux, Windows, баз данных и приложений. Если инфраструктура уже контролируется через Zabbix, добавлять отдельную платформу только ради коммутаторов обычно не требуется.

Для практики используем интерфейс Zabbix 7.4. В октябре уже доступна ветка 7.4.16, а Zabbix 8.0 находится на этапе кандидатов в выпуск. Поэтому инструкции ориентированы на стабильную ветку 7.4. Для длительной эксплуатации можно также рассмотреть поддерживаемую LTS-ветку.

Откройте Data collection → Hosts → Create host и создайте устройство с именем core-sw01. Добавьте его в группу Network devices или собственную группу сетевого оборудования.

В разделе Interfaces добавьте SNMP-интерфейс с IP 10.20.0.1 и портом 161.

Выберите SNMPv3 и заполните параметры.

Параметр	Значение
SNMP version	SNMPv3
Security name	snmpmon
Security level	authPriv
Authentication protocol	SHA1
Privacy protocol	AES128
Authentication passphrase	Пароль аутентификации
Privacy passphrase	Пароль шифрования
Context name	Пустое значение, если контекст не используется

Если SNMP-пользователь создан с SHA-256, выберите соответствующий алгоритм в Zabbix. Доступность расширенных алгоритмов аутентификации зависит в том числе от используемой версии Net-SNMP, с которой собран Zabbix.

Для парольных фраз можно применять пользовательские макросы Zabbix типа Secret text. Такой способ уменьшает риск случайно раскрыть значения в интерфейсе, хотя не заменяет полноценное управление секретами и правами доступа.

Выбираем шаблон Zabbix

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

Если производитель поддерживается, выбирайте специализированный шаблон соответствующей модели или семейства. Для базового мониторинга неизвестного устройства можно использовать Network Generic Device by SNMP.

Шаблон собирает доступные общесистемные показатели и предусматривает контроль сетевых интерфейсов. Для Linux с установленным Net-SNMP можно использовать Linux by SNMP.

После добавления шаблона проверьте автоматически создаваемые элементы данных и правила обнаружения Low-Level Discovery. Механизм LLD позволяет находить интерфейсы и создавать элементы данных, триггеры и графики по соответствующим прототипам.

Однако автоматическое обнаружение не гарантирует, что система правильно определит назначение каждого порта. После первого опроса стоит проверить имена интерфейсов и исключить ненужные виртуальные, административно отключённые или служебные порты.

Для проверки откройте Monitoring → Latest data, выберите core-sw01 и убедитесь, что появляются свежие значения. Если данные поступают, откройте простой график интерфейса или создайте собственную панель Dashboard.

Добавляем собственный SNMP-показатель в Zabbix

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

Допустим, проверка через snmpwalk показала, что нужному интерфейсу соответствует ifIndex 3.

В разделе Data collection → Hosts → Items → Create item создайте элемент со следующими параметрами.

Поле	Значение
Name	Uplink operational status
Type	SNMP agent
Key	port3.oper
SNMP OID	get[1.3.6.1.2.1.2.2.1.8.3]
Type of information	Numeric (unsigned)
Update interval	30s

Для одиночных значений в Zabbix 7.4 предпочтительнее использовать синтаксис get[OID]. Старый способ с непосредственным числовым OID поддерживается, но асинхронные get[] и walk[] лучше подходят для массового опроса.

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

Name: Uplink administrative status
 Type: SNMP agent
 Key: port3.admin
 SNMP OID: get[1.3.6.1.2.1.2.2.1.7.3]
 Type of information: Numeric (unsigned)
 Update interval: 30s

Теперь можно создать триггер, который реагирует на фактический отказ включённого администратором порта.

last(/core-sw01/port3.oper)<>1
 and
 last(/core-sw01/port3.admin)=1

Условие проверяет, что интерфейс не находится в состоянии up, хотя административно разрешён. Для важных портов полезно добавить задержку срабатывания, например требовать устойчивого отклонения на протяжении двух минут. Иначе кратковременное переключение соединения может вызвать лишнюю тревогу.

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

Как строить графики трафика Zabbix

При ручном добавлении счётчика ifHCInOctets Zabbix сначала получает накопленное число байтов. Без предобработки график будет показывать рост счётчика, а не скорость канала.

Создайте SNMP-элемент с OID.

get[1.3.6.1.2.1.31.1.1.1.6.3]

В разделе Preprocessing добавьте шаг Change per second. Для отображения скорости в битах в секунду добавьте следующий шаг Custom multiplier со значением 8. Единицы измерения установите в bps.

Аналогично настройте исходящий трафик через OID.

get[1.3.6.1.2.1.31.1.1.1.10.3]

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

Для совместного графика входящего и исходящего трафика создайте график с двумя элементами данных. Так будет видно не только абсолютную нагрузку, но и её направление.

Для уведомлений настройте способ доставки через Alerts → Media types, укажите получателя в профиле пользователя и создайте действие в Alerts → Actions → Trigger actions. Проверьте, что правило относится к нужной группе устройств и отправляет как сообщения о проблеме, так и сообщения о восстановлении.

Порог загрузки интерфейсов лучше задавать через макросы выбранного шаблона, если шаблон предусматривает такую настройку. Например, в некоторых сетевых шаблонах используется {$IF.UTIL.MAX}. Универсального макроса, одинаково работающего во всех шаблонах Zabbix, нет.

LibreNMS. Быстро поднимаем сетевой мониторинг

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

Для первого знакомства можно использовать Docker Compose. Предполагается, что Docker Engine и Compose уже установлены.

mkdir librenms
 cd librenms
 
 curl -L 
   -o librenms.zip 
   https://github.com/librenms/docker/archive/refs/heads/master.zip
 
 unzip librenms.zip
 
 cd docker-master/examples/compose

Перед запуском откройте .env и измените исходный пароль базы данных. Проверьте файл compose.yml, опубликованные порты и расположение постоянных томов.

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

Запустите контейнеры.

docker compose -f compose.yml up -d
 
 docker compose -f compose.yml ps

В типовой конфигурации примера веб-интерфейс доступен на порту 8000. Откройте адрес сервера мониторинга и завершите первоначальную настройку.

Не публикуйте административный интерфейс напрямую в интернет. Для рабочей среды нужны HTTPS, ограничение сетевого доступа, резервное копирование и сохранение ключа APP_KEY. LibreNMS шифрует учётные данные с использованием APP_KEY, поэтому потеря ключа может сделать сохранённые секреты недоступными даже при наличии копии базы данных.

Добавляем SNMP-устройство в LibreNMS

Откройте веб-интерфейс LibreNMS и перейдите в раздел Devices → Add Device. Укажите IP 10.20.0.1 и порт 161.

Для SNMPv3 задайте пользователя snmpmon, уровень authPriv, алгоритмы SHA и AES, а также обе парольные фразы.

В актуальных сборках LibreNMS учётные данные SNMP хранятся как зашифрованные секреты. Наборы паролей можно создавать в Settings → Secrets и выбирать при подключении устройств.

Для автоматического обнаружения оборудования можно назначить наборы секретов в Global Settings → Poller → SNMP. LibreNMS будет последовательно пробовать разрешённые учётные данные на обнаруживаемых устройствах.

Не следует использовать старые параметры snmp.community, snmp.v3 и snmp.version в config.php как основной способ настройки современных выпусков. Такие параметры больше не управляют учётными данными в актуальной схеме хранения секретов.

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

В разделе Ports обычно доступны входящий и исходящий трафик, скорость соединения, ошибки и отброшенные пакеты. Набор дополнительных показателей зависит от поддерживаемых устройством MIB и механизмов обнаружения LibreNMS.

Если оборудование не распознано по модели, базовые графики интерфейсов всё равно могут работать благодаря стандартным IF-MIB. А вот показателей температуры, вентиляторов и блоков питания может не быть без специализированной поддержки.

Настраиваем пороговые уведомления LibreNMS

Откройте Alerts → Alert Rules и создайте правило. Для недоступного устройства можно использовать выражение.

devices.status != 1

Для отключённых сетевых интерфейсов удобнее использовать готовый макрос macros.port_down, который учитывает состояние порта и исключает часть намеренно отключённых либо игнорируемых интерфейсов.

macros.port_down = 1

Правило высокой загрузки канала можно построить через макрос.

macros.port_usage_perc >= 85

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

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

В разделе Alerts → Alert Transports настройте доставку по электронной почте или через поддерживаемые интеграции.

Для LibreNMS особенно полезна комбинация правил, которая отдельно контролирует отказ устройства, состояние магистральных портов, использование канала и рост ошибок. Необязательно создавать аварийное уведомление на каждый неиспользуемый порт коммутатора.

Prometheus и snmp_exporter. Сбор метрик, интервалы и диагностика

Prometheus работает по другой схеме. Вместо встроенного SNMP-опросчика используется snmp_exporter, который преобразует ответы сетевого оборудования в метрики Prometheus.

Такой подход особенно удобен, если Prometheus уже собирает показатели приложений, контейнеров Kubernetes, Linux-серверов и баз данных. SNMP позволяет добавить в общую систему коммутаторы и маршрутизаторы.

Устанавливаем snmp_exporter

Для примера используем snmp_exporter 0.30.1 для Linux x86-64. Выпуск доступен в опубликованных пакетах проекта. Перед установкой на рабочий сервер проверьте контрольную сумму архива.

curl -fL -O 
   https://github.com/prometheus/snmp_exporter/releases/download/v0.30.1/snmp_exporter-0.30.1.linux-amd64.tar.gz
 
 tar -xzf 
   snmp_exporter-0.30.1.linux-amd64.tar.gz
 
 cd snmp_exporter-0.30.1.linux-amd64
 
 ls -l snmp_exporter snmp.yml

Файл snmp.yml содержит готовые модули опроса. Для большинства устройств с поддержкой IF-MIB можно начать с модуля if_mib.

Конфигурация snmp_exporter разделяет два понятия. Auth определяет способ подключения к оборудованию, а module указывает, какие OID запрашивать. Благодаря разделению можно использовать один модуль сбора интерфейсов с разными SNMP-пользователями.

Настраиваем SNMPv3 для экспортёра

Создайте рядом с основным snmp.yml дополнительный файл snmp-auth.yml.

auths:
   network_v3:
     version: 3
     username: snmpmon
     security_level: authPriv
     auth_protocol: SHA
     password: ${SNMP_AUTH_PASSWORD}
     priv_protocol: AES
     priv_password: ${SNMP_PRIV_PASSWORD}

Пароли задаются через переменные окружения. Такой способ позволяет не сохранять открытые парольные фразы непосредственно в YAML-файле.

В отдельном терминале задайте значения.

read -rs -p 'Auth password: ' SNMP_AUTH_PASSWORD
 echo
 
 read -rs -p 'Privacy password: ' SNMP_PRIV_PASSWORD
 echo
 
 export SNMP_AUTH_PASSWORD
 export SNMP_PRIV_PASSWORD

Команда read -rs не отображает вводимые символы. После запуска секреты остаются доступны через окружение соответствующего процесса, поэтому для постоянной службы нужен защищённый механизм передачи секретов. Переменные окружения не следует считать универсальным хранилищем паролей.

Запустите экспортёр.

./snmp_exporter 
   --web.listen-address=127.0.0.1:9116 
   --config.file=snmp.yml 
   --config.file=snmp-auth.yml 
   --config.expand-environment-variables

Параметр --config.expand-environment-variables позволяет подставить переменные в поддерживаемые поля авторизации. Два параметра --config.file загружают готовые модули и отдельные учётные данные.

Экспортёр слушает 127.0.0.1:9116, поскольку для примера Prometheus работает на той же машине. Если Prometheus находится на другом сервере, настройте доступ к HTTP-службе экспортёра только для доверенных источников. snmp_exporter также поддерживает TLS и базовую HTTP-аутентификацию.

Проверяем SNMP через HTTP

В другом терминале выполните запрос.

curl -fsS 
   'http://127.0.0.1:9116/snmp?target=10.20.0.1&auth=network_v3&module=if_mib'

Если SNMP-соединение работает, экспортёр вернёт набор метрик, среди которых могут присутствовать ifOperStatus, ifHCInOctets, ifHCOutOctets, ifInErrors и ifHighSpeed.

Вместе с числовыми значениями обычно передаются метки интерфейсов, например ifIndex, ifName и ifDescr. Состав меток определяется используемым модулем.

Проверяйте наличие нужных метрик по фактическому выводу. Отсутствие ifHCInOctets не обязательно означает ошибку экспортёра. Некоторые устройства не поддерживают 64-битные счётчики или не предоставляют их для определённых интерфейсов.

Для нестандартных MIB потребуется создать собственный модуль. Генератор snmp_exporter позволяет преобразовать определения MIB в конфигурацию сбора. Ручное редактирование автоматически созданного snmp.yml обычно менее удобно и затрудняет обновления.

Подключаем snmp_exporter к Prometheus

Откройте файл prometheus.yml и добавьте новое задание в существующий раздел scrape_configs.

scrape_configs:
   - job_name: network-snmp
     scrape_interval: 60s
     scrape_timeout: 20s
 
     metrics_path: /snmp
 
     params:
       auth: [network_v3]
       module: [if_mib]
 
     static_configs:
       - targets:
           - 10.20.0.1
           - 10.20.0.20
 
     relabel_configs:
       - source_labels: [__address__]
         target_label: __param_target
 
       - source_labels: [__param_target]
         target_label: instance
 
       - target_label: __address__
         replacement: 127.0.0.1:9116
 
   - job_name: snmp-exporter
     static_configs:
       - targets:
           - 127.0.0.1:9116

Первое задание собирает показатели с коммутатора и Linux-сервера. Второе отдельно контролирует доступность самого экспортёра.

Такое разделение полезно при диагностике. Если пропали данные SNMP и одновременно перестал отвечать экспортёр, искать причину на коммутаторе преждевременно.

Параметр __param_target передаёт исходный адрес оборудования snmp_exporter. Метка instance сохраняет адрес устройства в Prometheus, чтобы интерфейсы разных коммутаторов не смешивались между собой.

Проверьте конфигурацию.

promtool check config prometheus.yml

Перезагрузите конфигурацию Prometheus способом, предусмотренным для вашей установки. Затем откройте Status → Targets и проверьте состояние заданий network-snmp и snmp-exporter.

Значение UP у network-snmp означает, что Prometheus успешно получил метрики через экспортёр. Значение DOWN указывает на неудачный сбор, но само по себе не объясняет, где возникла проблема.

Строим графики сетевого трафика

В интерфейсе Prometheus откройте редактор запросов и выполните выражение для входящего трафика.

rate(ifHCInOctets[5m]) * 8

Для исходящего трафика.

rate(ifHCOutOctets[5m]) * 8

Функция rate() рассчитывает среднюю скорость изменения счётчика в секунду. Prometheus также умеет учитывать обнаруженные сбросы монотонных счётчиков, например после перезапуска устройства. Однако некорректные показания SNMP-агента или несколько переполнений старого 32-битного счётчика между опросами не всегда удаётся исправить автоматически.

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

Чтобы показать трафик конкретного коммутатора, добавьте фильтр.

rate(
   ifHCInOctets{instance="10.20.0.1"}[5m]
 ) * 8

Для расчёта загрузки интерфейса в процентах можно сопоставить текущую скорость передачи с ifHighSpeed.

100 * 8 * rate(ifHCInOctets[5m])
 /
 on(instance, ifIndex)
 (ifHighSpeed * 1000000)

Формула предполагает, что обе метрики содержат метки instance и ifIndex. Перед применением проверьте фактические метки экспортёра. Также исключите интерфейсы с неизвестной или нулевой скоростью.

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

Для обнаружения растущих ошибок приёма используйте запрос.

rate(ifInErrors[5m])

Для отброшенных пакетов.

rate(ifInDiscards[5m])

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

SNMP-счётчики не всегда позволяют определить точную причину. Например, рост ifInErrors не доказывает неисправность кабеля. Дополнительно проверяйте CRC, согласованную скорость, оптические уровни и собственные диагностические показатели коммутатора.

Для постоянных панелей удобнее использовать Grafana. В Grafana можно вывести входящий и исходящий трафик на одном графике, добавить загрузку интерфейса в процентах, ошибки и историю состояния портов.

Настраиваем уведомления в Prometheus

Создайте файл snmp.rules.yml с правилом недоступности.

groups:
   - name: network-snmp-alerts
     rules:
       - alert: SNMPDeviceUnavailable
         expr: up{job="network-snmp"} == 0
         for: 2m
         labels:
           severity: critical
         annotations:
           summary: "SNMP polling failed"
           description: "Device {{ $labels.instance }}"
 
       - alert: SNMPExporterUnavailable
         expr: up{job="snmp-exporter"} == 0
         for: 1m
         labels:
           severity: critical
         annotations:
           summary: "SNMP exporter unavailable"

Первое правило реагирует на отсутствие успешного SNMP-опроса в течение двух минут. Второе помогает отдельно обнаружить отказ экспортёра.

Если оба правила срабатывают одновременно, причина может находиться на сервере мониторинга. Чтобы не получать десятки сообщений об устройствах при отказе одного экспортёра, в Alertmanager можно настроить подавление зависимых уведомлений.

Подключите файл правил к основному конфигурационному файлу Prometheus.

rule_files:
   - snmp.rules.yml

Проверьте синтаксис.

promtool check rules snmp.rules.yml

После перезагрузки конфигурации проверьте правила в интерфейсе Prometheus. Для доставки писем и других уведомлений потребуется настроить Alertmanager и соответствующие маршруты доставки.

Для контроля загруженных интерфейсов можно добавить отдельное правило с порогом 85%, но использовать его следует только для портов с корректно определённой скоростью. Порог лучше применять после наблюдения за нормальной нагрузкой в течение нескольких рабочих дней.

Как выбрать интервалы опроса

Одна из распространённых ошибок состоит в стремлении опрашивать всё оборудование каждые несколько секунд. На слабых коммутаторах SNMP-запросы обрабатывает управляющий процессор, ресурсы которого ограничены. Массовый опрос большого количества OID способен увеличить задержки ответов, вызвать пропуски данных и создать дополнительную нагрузку.

Для начала можно использовать следующие интервалы.

Показатель	Интервал	Комментарий
Доступность устройства	30–60 секунд	Дополнять независимой ICMP-проверкой
Важные интерфейсы	30–60 секунд	Быстрое обнаружение отказа
Сетевой трафик	60 секунд	Подходит для обычных графиков
Ошибки интерфейсов	60–120 секунд	Контроль скорости роста счётчиков
CPU и память	1–2 минуты	Отслеживание устойчивой нагрузки
Температура оборудования	1–5 минут	Зависит от динамики и критичности
Обнаружение новых интерфейсов	15–60 минут	Не требует постоянного частого запуска
Полная инвентаризация	Несколько часов	Проверка состава и характеристик оборудования

Таблица содержит стартовые рекомендации, а не обязательные значения. Для критичного оборудования параметры выбирают с учётом допустимого времени обнаружения аварии.

В Zabbix интервал задаётся у элементов данных. Для обнаружения интерфейсов существует отдельный интервал LLD. В Prometheus частота определяется параметром scrape_interval, а максимальная длительность одного сбора ограничивается scrape_timeout.

В LibreNMS стандартный цикл SNMP-опроса обычно составляет пять минут. Система поддерживает более частый сбор, но переход на минутный интервал требует согласованной настройки планировщика, сбора и хранения данных.

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

Для быстрого обнаружения недоступности оборудования в LibreNMS часто разумнее использовать Fast Ping, а не уменьшать интервал всех SNMP-запросов.

Не рассчитывайте, что минутный опрос гарантированно обнаружит любой кратковременный сбой. Если порт отключился и восстановился между двумя запросами, система может не увидеть изменения. SNMP Trap способен дополнить периодический опрос, но сообщения Trap могут потеряться, поскольку сами по себе не предусматривают подтверждение получения.

Диагностика SNMP. Почему устройства не отвечают и графики врут

Сначала разделите неисправности на три группы. Первая связана с сетевым доступом, вторая с авторизацией SNMP, третья с обработкой полученных значений.

Симптом	Возможная причина	Проверка
Timeout	Фильтрация UDP 161, неверный IP, неправильные SNMPv3-параметры	Firewall, ACL, tcpdump, snmpget
Authentication failure	Ошибка пароля или алгоритма	Пользователь, SHA, пароль
Unknown user name	Учётная запись отсутствует	Настройки SNMPv3 на устройстве
No Such Object	OID не поддерживается или закрыт для чтения	MIB, SNMP view, правильность OID
Не обнаруживаются порты	Нет доступа к IF-MIB или ошибка обнаружения	snmpwalk, LLD, журналы LibreNMS
Неправильная скорость трафика	Нет расчёта скорости, переполнение или сброс счётчика	Предобработка, ifHCInOctets
Пропадают отдельные показатели	Слишком большие SNMP-ответы или тайм-ауты	GETBULK, max repetitions
Prometheus показывает DOWN	Ошибка SNMP или HTTP-соединения с экспортёром	curl, журналы экспортёра, Targets

1. Проверяем Linux. Убедитесь, что служба запущена и слушает нужный адрес.

sudo systemctl status snmpd
 
 sudo journalctl -u snmpd 
   -n 100 --no-pager
 
 sudo ss -lunp | grep ':161'

2. Проверяем поступление пакетов. На Linux-сервере запустите tcpdump, затем выполните snmpget с сервера мониторинга.

sudo tcpdump -ni any 
   'udp port 161'

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

3. Проверяем размер SNMP-запросов. Некоторые устройства неправильно обрабатывают большие ответы GETBULK. Проблема чаще проявляется на коммутаторах с большим количеством интерфейсов.

В Zabbix можно уменьшить параметр Max repetition count для SNMP-интерфейса. При ошибках объединённых запросов проверьте параметр Use combined requests, который относится к другому механизму группировки.

В LibreNMS настройки Max repeaters и Max OIDs позволяют управлять размером и характером SNMP-операций. Увеличивать значения наугад нельзя. Слишком большие ответы могут повысить задержки, вызвать фрагментацию UDP-пакетов или привести к сбоям опроса.

4. Проверяем LibreNMS. В обычной Linux-установке откройте каталог программы и запустите диагностику.

cd /opt/librenms
 
 sudo -u librenms ./validate.php

Для контейнерной установки диагностику выполняют внутри соответствующего контейнера. Дополнительно проверьте состояние планировщика и длительность циклов опроса.

5. Проверяем snmp_exporter. Сначала запросите метрики напрямую через curl. Если SNMP-опрос через экспортёр проходит успешно, а Prometheus показывает DOWN, ищите ошибку в scrape_configs, relabel_configs, сетевом доступе или тайм-аутах.

Если не работает прямой запрос, проверяйте snmp-auth.yml, алгоритмы, пароли, SNMP view и доступность оборудования.

Отдельно встречается ошибка SNMPv3 notInTimeWindow. Протокол использует идентификатор SNMP engine и внутренние счётчики времени и перезапусков для защиты от повторной передачи сообщений. Ошибка может возникать после перезапуска или некорректной работы SNMP-агента.

Синхронизация часов через NTP полезна для инфраструктуры в целом, но не устраняет автоматически проблемы SNMPv3 engineBoots и engineTime. На устройствах с одинаковыми или неправильно сохраняемыми engineID могут возникать дополнительные ошибки аутентификации и кэширования.

Что выбрать для сети. Zabbix, LibreNMS или Prometheus

Критерий	Zabbix	LibreNMS	Prometheus
Главная задача	Мониторинг всей ИТ-инфраструктуры	Мониторинг сетевого оборудования	Сбор и анализ метрик
SNMP	Встроенный опрос	Встроенный опрос	Через snmp_exporter
Обнаружение интерфейсов	Через LLD	Автоматическое обнаружение	Через настройки модулей
Готовые графики	Да	Да, с акцентом на сети	Базовые, расширенные через Grafana
Пороговые уведомления	Встроенные триггеры и действия	Встроенные правила и транспорты	Правила и Alertmanager
Производительские MIB	Шаблоны и собственные OID	Поддержка обнаружения и специальных модулей	Генератор snmp_exporter
Масштабирование	Zabbix Proxy, распределённая архитектура	Распределённые опросчики	Экспортёры и масштабирование хранилища метрик
Первоначальная настройка	Средняя сложность	Обычно проще для поддерживаемых устройств	Больше ручной настройки
Лучший сценарий	Серверы, приложения и сеть вместе	Коммутаторы, маршрутизаторы, каналы	Инфраструктура с Prometheus и Grafana

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

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

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

Частые вопросы о SNMP-мониторинге

Можно ли мониторить Linux только через SNMP, без Zabbix Agent?

Да. Net-SNMP предоставляет показатели процессора, памяти, файловых систем и сетевых интерфейсов. Однако для подробного контроля процессов, служб, системных журналов и приложений Zabbix Agent или специализированные экспортёры обычно удобнее. SNMP особенно полезен, когда нужна единая схема опроса разных типов оборудования.

Можно ли одновременно подключить устройство к Zabbix и LibreNMS?

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

Почему SNMP показывает состояние интерфейса, но не его трафик?

Устройство может предоставлять базовые объекты IF-MIB, но не поддерживать нужные высокоразрядные счётчики. Также возможны ограничения SNMP view, ошибки индексации или отсутствие предварительной обработки значений в системе мониторинга. Проверьте ifHCInOctets и ifHCOutOctets через snmpwalk и убедитесь, что выбран правильный ifIndex.

Почему после перезагрузки коммутатора поменялись графики портов?

Некоторые устройства могут менять ifIndex после перезагрузки, обновления прошивки или изменения конфигурации. Для более устойчивой идентификации портов используйте ifName, ifDescr и ifAlias, а также правила автоматического обнаружения. Не полагайтесь исключительно на числовой индекс.

Что лучше для быстрого обнаружения аварий, SNMP Trap или обычный опрос?

Оба механизма полезно сочетать. Trap позволяет устройству сообщить о событии без ожидания очередного опроса, но сообщение может потеряться. Inform предусматривает подтверждение получения, однако также требует правильной настройки отправителя и приёмника. Регулярный опрос необходим для проверки текущего состояния и обнаружения проблем, о которых устройство не отправило уведомление.

Может ли SNMP показать, какое приложение перегрузило канал?

Обычные счётчики SNMP показывают объём трафика интерфейса, но не раскрывают состав сетевых соединений по приложениям. Для анализа источников, получателей и типов трафика лучше использовать NetFlow, sFlow или IPFIX, если оборудование поддерживает соответствующие технологии.

Подойдёт ли SNMP для контроля температуры и вентиляторов коммутатора?

Да, при наличии соответствующих датчиков и SNMP-объектов. Для части оборудования используются стандартные ENTITY-SENSOR-MIB и связанные MIB, для других моделей нужны определения производителя. Если устройство не предоставляет показания через SNMP, Zabbix, LibreNMS и Prometheus не смогут получить их без другого источника данных.

Почему SNMPv3 работает через snmpwalk, но не подключается в Zabbix?

Проверьте, что Zabbix обращается к устройству с того же сетевого адреса, что и snmpwalk. Сравните имя пользователя, уровень authPriv, алгоритмы, пароли и контекст SNMPv3. Если используется Zabbix Proxy, запросы отправляет именно Proxy. При ошибках после перезагрузки устройства дополнительно проверьте SNMP engineID и состояние кэша SNMPv3.

Можно ли полностью заменить SNMP потоковой телеметрией?

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

Вывод. Для первого внедрения SNMP-мониторинга достаточно одного Linux-сервера с Net-SNMP, управляемого коммутатора и выбранной системы сбора показателей. Начните с SNMPv3 authPriv, проверьте ответы через snmpget и snmpwalk, затем подключите интерфейсы и настройте первые графики.

Если основная инфраструктура состоит из коммутаторов и маршрутизаторов, начните с LibreNMS. Если требуется объединить сетевое оборудование с серверами, базами данных и приложениями, выбирайте Zabbix. Если уже работает Prometheus, подключите snmp_exporter и используйте существующие средства анализа и уведомлений.

Не пытайтесь сразу собирать сотни показателей каждую секунду. Сначала контролируйте доступность устройств, состояние критичных портов, входящий и исходящий трафик, ошибки и отброшенные пакеты. Проверьте полученные значения под нормальной нагрузкой, настройте пороги, а затем добавляйте датчики и специализированные MIB.

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

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