Мониторинг сетевого оборудования с помощью Proto Observability

Инструкции по подключению компонентов Proto OBP для получения метрик производительности сетевого оборудования.

Описание

ProtoOBP агент поддерживает сбор метрики производительнсти сетевого оборудования используя SNMP v2 и v3 протокол. Сбор метрик сетевого оборудования имеет два варианта конфигурации:

Автоматчиеское сканирование заданной подсети и сбор метрик со всех обнаруженных сетевых устройств
Ручное указание адреса сетевого устройства для сбора его метрик

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

Список поддерживаемых профилей “из коробки”:

Cisco ASA
Cisco Catalyst
Cisco ISM
F5 BIG-IP
Fortinet FortiGate
Check Point Firewall
и многие другие

Полный список встроенных профилей можно посмотреть в каталоге с конфигурацией ProtoOBP агента /etc/protoobp-agent/conf.d/snmp.d/profiles/ Для добавления своих профилей, добавьте файл с профилем в каталог /etc/protoobp-agent/conf.d/snmp.d/profiles/

Автоматический поиск сетевых устройств и сбор их метрик

Для включения автоматического поиска сетевых устройств в файле конфигурации ProtoOBP агента /etc/protoobp-agent/protoobp.conf укажите следующее:

    listeners:
      - name: snmp
    snmp_listener:
    loader: core
    use_device_id_as_hostname: true
    configs:
      - network_address: 10.10.0.0/24  # CIDR подсети
        loader: core
        snmp_version: 2 #Версия SNMP протокола
        port: 161 # Порт
        community_string: '***'  # Community string
        #profile: "<profile_name >" # Если используется нестандартный профиль
      - network_address: 10.20.0.0/24
        loader: core
        snmp_version: 2
        port: 161
        community_string: '***'

После внесения изменния перезапустите ProtoOBP агента.

Ручная конфигурация мониторинга сетевого устройства и сбор его метрик

Для сбора метрик с конткретного сетевого устройства в файле конфигурации ProtoOBP агента /etc/protoobp-agent/conf.d/snmp.d/conf.yaml укажите следующее:

init_config:
  loader: core
  use_device_id_as_hostname: true
instances:
  - ip_address: 10.10.0.3 #IP адрес устройства
    port: 1161 # порт
    community_string: '***' # Community string
    loader: core
    use_device_id_as_hostname: true

После внесения изменния перезапустите ProtoOBP агента.

Какие именно метрики собираются

В конфиге instances: адрес устройства указывается без перечня метрик — потому что что именно опросить, определяется отдельным слоем «профиля устройства». Есть три уровня, по убыванию автоматизации:

Уровень 1 — встроенный профиль по `sysObjectID` (по умолчанию)

После первого опроса устройства агент делает SNMP GET для sysObjectID (1.3.6.1.2.1.1.2.0) и ищет файл в /etc/protoobp-agent/conf.d/snmp.d/profiles/, у которого в sysobjectid: указан этот OID (поддерживаются wildcard’ы и regex). Подходящий профиль содержит готовый список метрик — агент опросит ровно их.

Для большинства распространённого сетевого железа (Cisco, Juniper, F5, Fortinet, Check Point, …) встроенные профили уже есть — пользователь OID’ы не пишет.

Уровень 2 — собственный профиль для нестандартного устройства

Если устройства нет среди встроенных или нужны дополнительные OID, кладётся новый файл профиля в /etc/protoobp-agent/conf.d/snmp.d/profiles/:

# /etc/protoobp-agent/conf.d/snmp.d/profiles/my-router.yaml
extends:
  - _base.yaml           # стандартные sysUpTime/sysName/...
  - _generic-if.yaml     # IF-MIB / ifTable
sysobjectid:
  - 1.3.6.1.4.1.99999.1.*     # все железки этого вендора
metrics:
  - MIB: MY-VENDOR-MIB
    symbol:
      OID: 1.3.6.1.4.1.99999.2.1.0
      name: cpuUsagePercent
  - MIB: MY-VENDOR-MIB
    table:
      OID: 1.3.6.1.4.1.99999.3
      name: powerSupplyTable
    symbols:
      - { OID: 1.3.6.1.4.1.99999.3.1.1.2, name: psuStatus }
      - { OID: 1.3.6.1.4.1.99999.3.1.1.3, name: psuTemperature }
    metric_tags:
      - tag: psu_index
        column: { OID: 1.3.6.1.4.1.99999.3.1.1.1, name: psuIndex }

После рестарта агента к устройству с подходящим sysObjectID автоматически применится этот профиль — instances: менять не нужно.

Уровень 3 — inline `metrics:` прямо в `conf.yaml`

Когда заводить отдельный профиль избыточно (одно устройство, две-три метрики), список OID указывается прямо в инстансе:

init_config:
  loader: core
instances:
  - ip_address: 10.10.0.3
    community_string: '***'
    snmp_version: 2
    loader: core
    metrics:
      # скалярный OID
      - OID: 1.3.6.1.2.1.1.3.0
        name: sysUpTimeInstance
        forced_type: gauge

      # символ из MIB
      - MIB: IF-MIB
        symbol:
          OID: 1.3.6.1.2.1.2.2.1.10
          name: ifInOctets
        forced_type: counter

      # walk по таблице — одна запись агрегирует несколько колонок
      - MIB: IF-MIB
        table:
          OID: 1.3.6.1.2.1.2.2
          name: ifTable
        symbols:
          - { OID: 1.3.6.1.2.1.2.2.1.10, name: ifInOctets }
          - { OID: 1.3.6.1.2.1.2.2.1.16, name: ifOutOctets }
        metric_tags:
          - tag: interface
            column: { OID: 1.3.6.1.2.1.2.2.1.2, name: ifDescr }

Поля внутри metrics::

Поле	Назначение
`OID`	Числовой OID, обязателен.
`name`	Имя метрики в ProtoOBP. Попадает в storage как `snmp.<name>`.
`MIB`	Имя MIB (справочно, не парсится).
`forced_type`	`gauge`, `counter`, `rate`, `percent`, `monotonic_count`, `flag_stream`. Для счётчиков обязателен — иначе агент посчитает значение как gauge.
`symbol` / `symbols`	Скаляр / список колонок таблицы.
`table`	Walk по поддереву; обязателен, если `symbols` — массив.
`metric_tags`	Какие колонки таблицы становятся тэгами метрики (например `interface`, `psu_index`).

Обработка и сохранение полученных значений

SNMP-устройство ──GET/WALK──▶ ProtoOBP агент (snmp check)
                                       │
                                       ▼
                              метрики snmp.<name>{snmp_host, snmp_device, snmp_profile,
                                                  device_namespace, device_vendor, device_role,
                                                  <metric_tags>, ...}
                                       │
                                       ▼
                              proto-metric-storage
                                       │
                                       ▼
                              PromQL: snmp_ifInOctets{interface="eth0", ...}

Что важно знать:

Имя метрики в хранилище — snmp_<name> (из поля name: или из профиля). Через namespace: <ns> в инстансе префикс меняется на <ns>_<name>. На стороне агента в конфиге имена пишутся в нотации с точкой (ifInOctets, cpuUsagePercent); на ingest’е точки в имени метрики заменяются на _ — proto-metric-storage точек в именах не допускает. То же касается namespace-разделителя.
Тэги — это измерения метрики. Агент проставляет:
- snmp_host (имя/DNS устройства), snmp_device (IP), snmp_profile (имя сматчившегося профиля) — всегда;
- device_namespace — из поля namespace: инстанса;
- device_vendor, device_model, device_role и т.п. — если они объявлены в блоке metadata: подобранного профиля. Для встроенного профиля juniper-mx это, например, device_vendor="juniper-networks", device_role="edge_router".
Поверх — metric_tags: для табличных метрик и общий tags: инстанса. Все эти лейблы — обычные Prometheus-лейблы в proto-metric-storage; фильтр в PromQL работает напрямую:
```
snmp_ifInOctets{device_vendor="juniper-networks", interface="ge-0/0/0"}
```
Типы и rate-обработка. counter и monotonic_count агент превращает в скорость (delta/interval) до отправки в storage — в proto-metric-storage лежит уже rate, не сырое значение. Rate появляется не раньше второго опроса (нужно две точки).
Период опроса — min_collection_interval в инстансе (по умолчанию 15 с). Для устройств с большими таблицами имеет смысл повышать до 60 с — SNMP walk дорогой.

Альтернатива: Prometheus snmp_exporter

Если на устройстве нужны нестандартные OID, или у вас уже развёрнут Prometheus-стек, или для девайса нет встроенного профиля ProtoOBP — используйте компонент proto-snmp-exporter. Он опрашивает устройство по SNMP и публикует метрики в Prometheus-формате на HTTP-порту 9116. ProtoOBP собирает метрики с этого эндпоинта через интеграцию prometheus:

+-----------+    SNMP udp/161    +---------------------+   HTTP 9116   +----------+
|  SNMP dev | <----------------- | proto-snmp-exporter | <------------ | ProtoOBP |
+-----------+                    +---------------------+    (scrape)   +----------+

proto-snmp-exporter уже содержит сгенерированный snmp.yml (auth-блок public_v2 + модуль if_mib и другие стандартные модули) — для типового опроса по IF-MIB настраивать ничего не нужно. Для кастомных OID соберите свой snmp.yml генератором snmp_exporter, смонтируйте его и укажите POBP_SNMP_EXPORTER_CONFIG_FILE=/config/snmp.yml.

Минимальный snmp.yml (auth-блок + модуль с walks по нужным MIB-поддеревьям):

auths:
  public_v2:
    community: public
    version: 2

modules:
  if_mib:
    walk:
      - 1.3.6.1.2.1.1                    # system
      - 1.3.6.1.2.1.2                    # interfaces (ifTable)
      - 1.3.6.1.2.1.31.1.1               # ifXTable
    metrics:
      - { name: sysUpTime, oid: 1.3.6.1.2.1.1.3, type: gauge }
      - { name: ifInOctets, oid: 1.3.6.1.2.1.2.2.1.10, type: counter,
          indexes: [{ labelname: ifIndex, type: gauge }] }
      - { name: ifOutOctets, oid: 1.3.6.1.2.1.2.2.1.16, type: counter,
          indexes: [{ labelname: ifIndex, type: gauge }] }
      # ... остальные счётчики из IF-MIB

Запрос: GET /snmp?target=<device>&auth=public_v2&module=if_mib.

Подключение в conf.d/prometheus.d/conf.yaml (хост):

init_config:
instances:
  - prometheus_url: http://<snmp-exporter-host>:9116/snmp?target=<device>&auth=public_v2&module=if_mib
    namespace: snmp_exporter
    metrics:
      - "if*"
      - "sys*"
    min_collection_interval: 30

или через autodiscovery-лейблы на контейнере proto-snmp-exporter:

labels:
  com.protoobp.ad.check_names: '["prometheus"]'
  com.protoobp.ad.init_configs: '[{}]'
  com.protoobp.ad.instances: '[{"prometheus_url": "http://%%host%%:9116/snmp?target=<device>&auth=public_v2&module=if_mib", "namespace": "snmp_exporter", "metrics": ["if*", "sys*"], "min_collection_interval": 30}]'

Метрики приходят с namespace-префиксом: snmp_exporter_ifInOctets, snmp_exporter_ifOutOctets, snmp_exporter_ifOperStatus, snmp_exporter_sysUpTime и т.п. (в proto-metric-storage точки разделителей заменяются на _ — точек в именах метрик хранилище не допускает). Counter-метрики (ifInOctets/ifOutOctets) появляются после ≥ 2 запусков проверки — раньше агент не может посчитать rate.

Когда что использовать

Параметр	Прямая SNMP-проверка (`snmp`)	Через snmp_exporter (`prometheus`)
Профили устройств «из коробки»	200+ (Cisco/Juniper/F5/Fortinet/…)	нет — задаются вручную в `snmp.yml`
Namespace в ProtoOBP	`snmp_*`	`<namespace>_<metric_name>`
Auto-теги из профиля (vendor/role/…)	да (`metadata:`-блок профиля → лейблы)	нет — `tags:` указывается вручную
Latency	один SNMP round-trip	SNMP round-trip + HTTP-hop
Подходит, когда	стандартное сетевое железо	нужны кастомные OID, или есть Prometheus

Приём SNMP-трапов

SNMP-трапы — асинхронные нотификации от устройств (linkDown/linkUp/coldStart/authenticationFailure/…) на UDP/162. Для их приёма в состав ProtoOBP входит компонент proto-snmp-trap-receiver: он принимает трапы, форматирует каждый в одну строку и пишет в лог, который собирает ProtoOBP (фильтр source:snmptrap).

Контейнер слушает непривилегированный UDP-порт 1162 и работает под непривилегированным пользователем (root и CAP_NET_BIND_SERVICE не нужны); на хосте порт публикуется как 162:1162/udp, поэтому устройства по-прежнему шлют трапы на стандартный 162. Поведение настраивается переменными POBP_SNMP_TRAP_RECEIVER_* (community, режим авторизации). Компонент входит в стандартную поставку ProtoOBP.

Если разворачиваете snmptrapd вручную (на хосте или собственным контейнером), ниже — минимальная конфигурация.

Минимальный snmptrapd.conf:

disableAuthorization yes

# format1 — SNMPv1, format2 — v2c/v3. snmptrapd НЕ добавляет newline
# автоматически — нужен явный \n в конце.
format1 %#04.4y-%#02.2m-%#02.2lT%#02.2h:%#02.2j:%#02.2K from %a uptime=%T trap=%W vars=%v\n
format2 %#04.4y-%#02.2m-%#02.2lT%#02.2h:%#02.2j:%#02.2K from %a uptime=%T trap=%W vars=%v\n

outputOption s

Запуск:

snmptrapd -f -n -Lf /var/log/snmp/snmptrap.log -c /etc/snmp/snmptrapd.conf udp:0.0.0.0:162

disableAuthorization yes отключает проверку community/v3-user’а — допустимо только в изолированной тестовой сети; в проде используйте authCommunity log,execute <community> или v3-пользователей.

Пример строки в /var/log/snmp/snmptrap.log:

2026-05-12T12:11:38 from 0.0.0.0 uptime=0 trap=Cold Start vars=sysUpTimeInstance = Timeticks: (171423) 0:28:34.23	snmpTrapOID.0 = OID: linkUp	ifIndex.81 = INTEGER: 81

Подключение в ProtoOBP как лог-источник.

Хост: в conf.d/snmp_trap.d/conf.yaml или общую logs:-секцию агента добавьте file-источник:

logs:
  - type: file
    path: /var/log/snmp/snmptrap.log
    source: snmptrap
    service: snmptrapd
    log_processing_rules:
      - type: multi_line
        name: log_start_with_iso8601
        pattern: \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}

Docker: autodiscovery-лейбл на контейнере snmptrapd:

labels:
  com.protoobp.ad.logs: |
    [{
      "type": "file",
      "path": "/var/log/snmp/snmptrap.log",
      "source": "snmptrap",
      "service": "snmptrapd",
      "log_processing_rules": [
        {"type": "multi_line", "name": "log_start_with_iso8601",
         "pattern": "\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}"}
      ]
    }]

(volume с /var/log/snmp должен быть смонтирован read-only в контейнере агента — snmptrapd пишет, агент читает.)

Проверка:

docker exec protoobp-agent agent status | grep -A 6 "Source: snmptrap"
# → Source: snmptrap, Status: OK, BytesRead > 0, MultiLine matches > 0

В Logs Explorer ProtoOBP трапы доступны с фильтром pobpsource:snmptrap.

Отправка алертов ProtoOBP как SNMP-трапов

Обратное направление — когда сам ProtoOBP уведомляет внешнюю систему мониторинга (например, Zabbix) о своих алертах по SNMP. Для этого служит компонент proto-snmp-notifier: он принимает вебхуки от proto-alertmanager и отправляет их как SNMP-трапы во внешний NMS. Адрес получателя задаётся переменной POBP_SNMP_NOTIFIER_DESTINATION (версия и community — POBP_SNMP_NOTIFIER_VERSION / POBP_SNMP_NOTIFIER_COMMUNITY).

Компонент входит в стандартную поставку и слушает :9464 во внутренней сети. Чтобы включить отправку, добавьте в конфигурацию алертинга webhook-приёмник, указывающий на http://proto-snmp-notifier:9464/alerts.

Собираемые метрики

Uptime
Использование CPU
Bandwitch - Гбит/с
Трафик In - Бит/с
Трафик Out - Бит/с
Количество интерфейсов
Ошибки интерфейсов
Отброшенные пакеты
Операционный статус интерфейса
Статус интерфейса