Почему SNMP-мониторинг без агентов - ваш единственный выход
В гетерогенной инфраструктуре администратор регулярно сталкивается с устройствами, на которые невозможно установить стандартный агент мониторинга. Коробочные NAS вроде Synology или QNAP, проприетарные OEM-системы, коммутаторы и маршрутизаторы, устаревшее оборудование - все они закрыты для модификации. Политики безопасности часто прямо запрещают установку стороннего ПО на критичные узлы.
SNMP остаётся единственным стандартом, который поддерживается практически любым сетевым устройством с момента его появления. Протокол не требует агентов, работает на уровне firmware и позволяет унифицировать сбор метрик в единой системе мониторинга. Вы получаете данные о загрузке CPU, использовании памяти и состоянии дисков без единой команды по SSH и без изменения конфигурации целевых систем.
Этот подход закрывает главную боль администратора - необходимость поддерживать зоопарк агентов разных версий и вендоров. Один snmp_exporter для Prometheus заменяет десятки проприетарных сборщиков и даёт сквозную видимость по всей инфраструктуре.
Архитектура решения: Prometheus + snmp_exporter
Поток данных выглядит так: целевое устройство со встроенным SNMP-агентом отвечает на запросы по протоколу UDP (порт 161), snmp_exporter выступает посредником - он опрашивает устройства, преобразует SNMP-ответы в формат метрик Prometheus и отдаёт их на порту 9116. Prometheus скрапит этот эндпоинт по расписанию, сохраняет временные ряды и передаёт их в Grafana для визуализации.
snmp_exporter может опрашивать множество устройств одновременно. Достаточно описать их в конфигурации Prometheus через статический список или file_sd_configs, и один экземпляр экспортера закроет мониторинг десятков единиц оборудования.
Требования и подготовка среды
Перед началом настройки убедитесь, что у вас есть:
- Работающий Prometheus версии 2.45 или новее.
- Сетевой доступ от сервера с snmp_exporter до целевых устройств по UDP 161.
- SNMP community string для чтения (обычно public для v2c) или учётные данные для v3.
- Версия SNMP, поддерживаемая устройством (v2c или v3; v1 лучше не использовать из-за отсутствия нормальной безопасности).
Рекомендую развернуть snmp_exporter на отдельном хосте или в контейнере рядом с Prometheus. Это упрощает сетевую диагностику: если экспортер не может достучаться до устройства, проблема локализована на одном звене.
Шаг 1: Установка и запуск snmp_exporter
Два проверенных способа - прямой бинарник и Docker. Выбирайте тот, который вписывается в ваш пайплайн.
Бинарник. Скачайте актуальный релиз с GitHub (репозиторий prometheus/snmp_exporter). Распакуйте архив, переместите бинарник в /usr/local/bin. Создайте systemd-юнит:
[Unit] Description=SNMP Exporter After=network.target [Service] User=snmp_exporter ExecStart=/usr/local/bin/snmp_exporter --config.file=/etc/snmp_exporter/snmp.yml Restart=always [Install] WantedBy=multi-user.target
Запустите сервис и проверьте, что экспортер отвечает: curl http://localhost:9116. Вы должны увидеть страницу с метриками самого экспортера.
Docker. Используйте официальный образ prom/snmp-exporter. Пример docker-compose:
snmp_exporter:
image: prom/snmp-exporter:latest
ports:
- "9116:9116"
volumes:
- ./snmp.yml:/etc/snmp_exporter/snmp.yml
restart: always
После запуска контейнера проверка та же: curl на порт 9116. Экспортер готов к работе.
Шаг 2: Основы MIB и OID - как найти нужные метрики
OID - это числовой идентификатор объекта в иерархическом дереве MIB. Дерево начинается с корня и ветвится: 1.3.6.1 - стандартная ветка ISO-identified organization, под которой находятся все основные MIB. Умение ориентироваться в OID избавляет от зависимости от готовых конфигураций: вы сами находите нужные метрики для любого устройства.
Главный инструмент для исследования - утилита snmpwalk. Она обходит дерево OID и показывает, какие метрики доступны на устройстве. Пример для получения всей ветки HOST-RESOURCES-MIB:
snmpwalk -v2c -c public 192.168.1.100 1.3.6.1.2.1.25
Утилита snmptranslate помогает преобразовать числовой OID в символьное имя и обратно. Если вы знаете, что метрика называется hrSystemUptime, команда snmptranslate -On HOST-RESOURCES-MIB::hrSystemUptime вернёт её числовой OID.
Производители NAS часто расширяют стандартные MIB собственными ветками. Synology, например, отдаёт данные о температуре дисков и состоянии RAID через частные OID. Чтобы их найти, выполните snmpwalk по всей ветке предприятия: snmpwalk -v2c -c public nas_ip 1.3.6.1.4.1 и ищите знакомые названия вендора.
Типовые OID для CPU, памяти и дисков
Таблица ниже - шпаргалка для старта. OID взяты из UCD-SNMP-MIB и HOST-RESOURCES-MIB, которые поддерживаются большинством Linux-серверов с net-snmp и многими NAS.
| Метрика | OID | Описание |
|---|---|---|
| Загрузка CPU (1 мин) | 1.3.6.1.4.1.2021.10.1.3.1 | Load average за 1 минуту |
| Загрузка CPU (5 мин) | 1.3.6.1.4.1.2021.10.1.3.2 | Load average за 5 минут |
| Загрузка CPU (15 мин) | 1.3.6.1.4.1.2021.10.1.3.3 | Load average за 15 минут |
| Общий объём RAM | 1.3.6.1.4.1.2021.4.5.0 | Total RAM в килобайтах |
| Свободная RAM | 1.3.6.1.4.1.2021.4.6.0 | Free RAM в килобайтах |
| Использование RAM (%) | 1.3.6.1.4.1.2021.4.11.0 | Процент использованной памяти |
| Состояние дисков | 1.3.6.1.4.1.2021.9.1.9 | Процент использования для каждого раздела |
| Общий объём диска | 1.3.6.1.4.1.2021.9.1.6 | Размер раздела в килобайтах |
Значения могут отличаться для разных устройств. Перед использованием проверьте OID через snmpwalk на конкретной модели. Если устройство не отвечает на запрос, значит, эта ветка MIB не поддерживается - ищите альтернативные OID в документации производителя.
Шаг 3: Конфигурация snmp_exporter для сбора метрик
Файл snmp.yml описывает модули - шаблоны опроса устройств. Каждый модуль содержит walk-параметры (какие OID обходить) и маппинг OID на читаемые имена метрик. Prometheus при скрапе указывает target и module, а экспортер подставляет их в SNMP-запрос.
Базовая структура модуля для сбора CPU, памяти и дисков:
modules:
basic_system:
walk:
- 1.3.6.1.4.1.2021.10 # CPU load
- 1.3.6.1.4.1.2021.4 # Memory
- 1.3.6.1.4.1.2021.9 # Disk usage
version: 2
max_repetitions: 25
retries: 3
timeout: 5s
Параметр version указывает версию SNMP (2 для v2c, 3 для v3). max_repetitions управляет количеством OID в одном GETBULK-запросе - увеличивайте для ускорения опроса, уменьшайте при таймаутах. retries и timeout задают устойчивость к сетевым задержкам.
Для разных community string на разных устройствах создайте отдельные модули или используйте параметр auth в секции конкретного таргета Prometheus.
Пример конфигурации для мониторинга NAS
NAS на базе Linux (Synology, QNAP, TrueNAS) обычно поддерживают UCD-SNMP-MIB. Конфигурация ниже собирает загрузку CPU, использование памяти и состояние всех разделов:
modules:
nas_monitoring:
walk:
- 1.3.6.1.4.1.2021.10.1 # laLoad
- 1.3.6.1.4.1.2021.4 # memory
- 1.3.6.1.4.1.2021.9.1 # disk
version: 2
auth:
community: public
max_repetitions: 25
retries: 3
timeout: 10s
Проверьте конфигурацию до подключения к Prometheus. Запустите snmp_exporter с флагом --dry-run или выполните прямой запрос к эндпоинту экспортера:
curl "http://localhost:9116/snmp?target=192.168.1.50&module=nas_monitoring"
В ответе вы увидите все метрики, которые экспортер смог собрать. Если ответ пустой или содержит ошибку - проверьте community string и доступность порта 161 с хоста экспортера.
Пример конфигурации для мониторинга серверов и коммутаторов
Для Linux-сервера с net-snmp можно использовать тот же модуль nas_monitoring. Коммутаторы требуют другого подхода: основные метрики - трафик на интерфейсах и статус портов. Используйте IF-MIB:
modules:
switch_monitoring:
walk:
- 1.3.6.1.2.1.2.2.1 # ifTable (статус, трафик, ошибки)
- 1.3.6.1.2.1.31.1.1 # ifXTable (64-битные счётчики)
version: 2
auth:
community: public
max_repetitions: 25
retries: 3
timeout: 5s
Один snmp.yml может содержать несколько модулей. Prometheus укажет нужный модуль в параметрах скрапа для каждого устройства или группы устройств.
Шаг 4: Интеграция с Prometheus и визуализация
Добавьте job в prometheus.yml. Используйте file_sd_configs для управления списком устройств без перезагрузки Prometheus:
scrape_configs:
- job_name: 'snmp'
scrape_interval: 60s
scrape_timeout: 30s
file_sd_configs:
- files:
- /etc/prometheus/snmp_targets.yml
metrics_path: /snmp
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_module]
target_label: module
- target_label: __address__
replacement: snmp_exporter:9116
Файл snmp_targets.yml описывает устройства и модули:
- labels:
module: nas_monitoring
targets:
- 192.168.1.50
- 192.168.1.51
- labels:
module: switch_monitoring
targets:
- 192.168.1.1
После перезагрузки Prometheus метрики появятся с лейблами instance и module. Базовые PromQL-запросы для проверки:
- Загрузка CPU:
laLoad{module="nas_monitoring"} - Использование памяти:
memTotalReal - memAvailReal - Заполнение дисков:
dskPercent
Для визуализации подключите Grafana и импортируйте дашборд 11234 (SNMP Exporter Dashboard) - он покрывает базовые метрики и настраивается под ваши модули за несколько минут. Если вы строите комплексную систему мониторинга, обратите внимание на руководство по настройке стека Prometheus/Grafana с алертами - там разобрана полная цепочка от CLI-утилит до продакшн-дашбордов.
Типичные проблемы и их решение
За годы работы с SNMP я выделил несколько повторяющихся ошибок. Вот они и способы их исправить.
Таймаут при опросе. Симптом: snmp_exporter возвращает ошибку timeout или пустой ответ. Причина: сетевая задержка, перегрузка устройства или слишком короткий таймаут в конфигурации. Решение: увеличьте timeout до 10-15 секунд в snmp.yml, проверьте сетевую связность через ping и доступность порта 161 через nmap.
Неверная community string. Симптом: аутентификационная ошибка в логах экспортера. Решение: проверьте community на устройстве (обычно public для чтения), убедитесь, что в snmp.yml в секции auth указана правильная строка. На многих NAS community задаётся в веб-интерфейсе отдельно для каждого SNMP-клиента.
Несовпадение версий SNMP. Симптом: устройство не отвечает на запросы, хотя snmpwalk с теми же параметрами работает. Решение: явно укажите version в модуле snmp.yml. Устройство может поддерживать v2c, а экспортер по умолчанию пытается v3.
OID отсутствует на устройстве. Симптом: в ответе экспортера нет ожидаемых метрик, хотя другие OID собираются. Решение: выполните snmpwalk по родительской ветке OID и убедитесь, что устройство её поддерживает. Для нестандартных метрик ищите документацию производителя - Synology, QNAP и другие вендоры публикуют списки поддерживаемых OID.
Проблемы с правами доступа к snmp_exporter. Симптом: Prometheus не может получить метрики, хотя экспортер работает. Решение: проверьте, что порт 9116 открыт на файрволе и что Prometheus имеет сетевой доступ к хосту экспортера. Проверьте логи Prometheus на предмет ошибок скрапа.
Ограничения SNMP-мониторинга: когда агент все же нужен
SNMP даёт базовую видимость, но уступает агентскому мониторингу в детализации. Вы не получите данных о конкретных процессах, потребляющих CPU, не увидите очереди приложений, не соберёте логи и трассировки. Метрики обновляются с задержкой, зависящей от интервала опроса - обычно 30-60 секунд, тогда как агент может отдавать данные с секундным разрешением.
Для глубокого мониторинга Linux-серверов, где можно установить агент, используйте Node Exporter. Он собирает метрики ZFS, systemd, контейнеров и сотен других подсистем, недоступных через SNMP. Сравнение подходов и пошаговая настройка описаны в руководстве по мониторингу Linux-серверов с Node Exporter - там же есть готовые дашборды и правила алертинга.
SNMP незаменим там, где агент невозможен: коммутаторы, NAS, медицинское оборудование, промышленные контроллеры. В гетерогенной среде разумно комбинировать оба подхода: SNMP для устройств без агента и Node Exporter для серверов с полным доступом. Это даёт максимальное покрытие без слепых зон.
Если вы мониторите специфичное оборудование, например медицинские анализаторы или томографы, посмотрите руководство по SNMP-мониторингу медицинского оборудования - там разобраны частные OID и настройка оповещений о сбоях компонентов.