SNMP

Примечание

Для корректного отображения устройств на дашбоарде в Grafana следует использовать значение тега component как IP-адрес или имя устройства, которое мониторится с помощью snmp-exporter

SNMP поллинг

Для SNMP мониторинга удаленных устройств применяется snmp-exporter.

Для генерации конфигурационного файла используется специальная утилита generator. В архив с snmp-exporter добавлен каталог стандартных MIB-файлов для генерации конфигураций.

Эта утилита обрабатывает необходимые MIB-файлы и преобразует их в список OID-цепочек и названий метрик.

SNMP exporter опрашивает удаленные устройства на основе этих данных и выводит метрики в формате Prometheus для дальнейшего анализа другими системами.

Запуск snmp-exporter с помощью агента мониторинга

Для установки экспортера как сервиса см. руководство.

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

Настройка раздела exporters

В конфигурационном файле агента в разделе exporters укажите имя запускаемого экспортера и параметр is_custom:

exporters:
  - name: snmp_exporter
    is_custom: true
    args: "--config.file=/opt/astramon-agent/exporters/config/snmp.yml"
    health_address: 127.0.0.1:9116/metrics

  • Поле name должно совпадать с названием бинарного файла с учетом дополнительных условий именования сторонних экспортеров (например: astramon-snmp_exporter-custom ).

  • Параметр is_custom указывает агенту, что это сторонний экспортер, но агент может управлять им (запускать, выполнять health check, останавливать и сообщать статус работы экспортера в Config API). Также это предотвращает использование функциональности, доступной только для экспортеров, специально разработанных для агента мониторинга.

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

Настройка раздела metrics

Выполните настройку в разделе metrics:

custom_targets:
  - name: snmp_exporter1
    component: 10.177.248.228
    target: 127.0.0.1:9116
    metrics_path: /snmp?module=apcups&target=10.177.248.228
  - name: snmp_exporter2
    component: 10.177.248.234
    target: 127.0.0.1:9116
    metrics_path: /snmp?module=linux&target=10.177.248.234

  • Поле name должно быть уникальным (это особенность работы vmagent). В примере показан сбор данных с двух целевых устройств.

  • Параметр component добавляет лейбл component для различения метрик разных устройств.

  • Параметр target указывает адрес и порт, с которого будут считываться метрики.

  • Параметр metrics_path позволяет обратиться к конкретному эндпоинту для получения метрик. По умолчанию используется /metrics, но в данном случае эндпоинт выводит метрики для разных устройств. При необходимости можно добавить запись для сбора метрик напрямую из /metrics.

SNMP трапы

SNMP-трапы (SNMP traps) — это механизм уведомлений в сетевых устройствах и сервисах, который работает по принципу «произошло событие — сразу сообщи». В отличие от метрик (которые собираются периодически) или логов (которые просто фиксируют происходящее), трап — это целенаправленное уведомление о важном событии, требующем внимания, они помогают быстро обнаруживать проблемы без постоянного опроса метрик и копания в логах.

Например:

  • Сетевое устройство внезапно перезагрузилось

  • Интерфейс на коммутаторе перешёл в состояние down

  • Заканчивается место на диске сервера

  • Сработала система охлаждения на оборудовании

Трапы не ждут, пока их «спросят» (как в случае с опросом метрик через SNMP GET), а сразу отправляют информацию при наступлении события.

Чем трапы отличаются от:

  1. Логов

    • Это «сырая» хронология событий, часто избыточная

    • Требуют парсинга и фильтрации для выявления важного

    • Могут дублироваться или теряться в потоке данных

  2. Метрик

    • Показывают состояние системы в конкретный момент (CPU, RAM, нагрузка)

    • Нужно постоянно опрашивать устройство, чтобы получить актуальные данные

    • Не всегда очевидно, когда значение метрики становится проблемой

Что же такое snmp trap в astra-monitoring

Это целевые уведомления о конкретных событиях, которые:

  • Приходят однократно (не нужно ничего опрашивать)

  • содержат готовую интерпретацию события (например, не просто «интерфейс down», а «интерфейс Eth1/0/3 на устройстве SW-01 перестал отвечать из-за потери связи»)

  • Не накапливаются бесконечно — после обработки сохраняются в базу и не дублируются

Как трапы работают в нашем продукте?

  1. Устройство генерирует трап (например, роутер сообщает о перегрузке CPU).

  2. Агент (или SNMP-прокси) принимает трап и передаёт его в центральную систему.

  3. Сервис обработки трапов парсит данные, обогащает их (добавляет hostname, severity, дополнительные поля) и сохраняет в ClickHouse.

  4. Дальнейшие сценарии использования:

    • Просмотр в интерфейсе (например, в разделе События)

    • Интеграция с алертингом (в ближайших релизах появится мониторинг событий)

    • Анализ частоты срабатываний (например, «сколько раз за месяц падал интерфейс на этом коммутаторе»)

В будущем мы добавим мониторы на основе трапов (событий), чтобы вы могли:

  • Настраивать правила типа: «Если пришло 3 трапа link down за 5 минут — создать инцидент»

  • Строить графики частоты событий по типам устройств

  • Интегрировать трапы с внешними системами (например, Slack или Jira)

Где/как настроить сбор трапов?

Чтобы начать получать трапы от устройств, нужно:

  • Настроить агенты на их приём (указать community-строки, порты, фильтры).

  • Добавить устройства в конфигурацию мониторинга.

Подробная инструкция доступна в разделе Конфигурирование сбора SNMP-трапов на агенте

Там описано:

  • Как разрешить приём трапов на агентах

  • Как фильтровать ненужные события

  • Как настраивать обогащение данных (добавление тегов, severity)