Мониторинг коммутатора через SNMP

Этот перевод выполнен автоматически и ещё не вычитан. Читать английскую версию

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

Перед началом

У вас есть доступ к командной строке коммутатора от root через SSH. Если его нет, попросите поддержку FlySIP выполнить шаги 1 и 2.
Вы знаете IP-адрес своего хоста мониторинга и выбрали строку сообщества (community string), например fs-monitor-7Qx.
На вашем хосте мониторинга для проверки есть инструменты snmpwalk и snmpget (пакет net-snmp).

Шаг 1: Разрешите свой хост мониторинга

Агент SNMP отвечает только 127.0.0.1, пока вы не добавите свой хост. Фаервол коммутатора открывает UDP 161 только для хостов, перечисленных в конфигурации агента.

Откройте на коммутаторе /home/ssp/etc/snmpd.conf. В нём уже есть строка, которая отдаёт статистику коммутатора:
```
pass_persist .1.3.6.1.4.1.36523  /home/ssp/scripts/snmp_statsd.py
```
Добавьте строку со своей строкой сообщества и хостом мониторинга:
```
rocommunity  fs-monitor-7Qx  198.51.100.20
```
Перезапустите агент и перезагрузите правила фаервола. Запускайте скрипт фаервола внутри screen, чтобы обрыв SSH-сессии его не прервал:
Окно терминала
```
/usr/local/etc/rc.d/snmpd restart
screen /home/ssp/scripts/rc.firewall.sh
```

Результат: UDP 161 коммутатора принимает запросы от 198.51.100.20 с этой строкой сообщества.

Шаг 2: Скопируйте файл MIB (необязательно)

Приведённые ниже OID работают без MIB. Чтобы видеть в своём инструменте названия вместо чисел, скопируйте файл MIB, который поставляется в /home/ssp/etc/ на коммутаторе, в каталог MIB своего хоста мониторинга, например /usr/share/snmp/mibs/. Если не можете его найти, обратитесь в поддержку FlySIP.

Шаг 3: Считайте счётчики

Все OID начинаются с .1.3.6.1.4.1.36523.1.1. Обойдите дерево со своего хоста мониторинга:

snmpwalk -v2c -On -c fs-monitor-7Qx 203.0.113.10 .1.3.6.1.4.1.36523.1.1

.1.3.6.1.4.1.36523.1.1.1.1.1.1 = STRING: "1/Primary/"
.1.3.6.1.4.1.36523.1.1.1.2.1.1 = INTEGER: 42
.1.3.6.1.4.1.36523.1.1.1.3.1.1 = INTEGER: 37

Для каждой среды

OID имеет вид .1.3.6.1.4.1.36523.1.1.1.<n>.1.<i_environment>.

`<n>`	Значение
`1`	ID и название среды, например `"1/Primary/"`
`2`	Активные звонки: маршрутизируемые звонки плюс соединённые звонки
`3`	Соединённые звонки
`4`	Средний `ptime` процессора звонков
`5`	Средний `aa_ptime` процессора звонков
`6`	Среднее количество авторизованных звонков
`7`	Среднее количество маршрутизированных звонков
`8`	Среднее количество соединённых звонков
`9`	Количество авторизованных звонков, счётчик
`10`	Количество маршрутизированных звонков, счётчик
`11`	Количество соединённых звонков, счётчик
`12`	Общая длительность звонков, счётчик
`13`	Количество полученных звонков, счётчик
`14`	Количество инициированных звонков, счётчик
`15`	Количество зарегистрированных устройств

ID корневой среды - 1. Другие среды имеют ID, показанные в System Management → Environments (среды).

Для каждого аккаунта, клиента, вендора и подключения

OID имеет вид .1.3.6.1.4.1.36523.1.1.<object>.<n>.1.<i_environment>.<id>, где <n> равно 2 для активных звонков и 3 для соединённых.

`<object>`	Объект	`<id>`
`2`	Аккаунт	`i_account`
`3`	Вендор	`i_vendor`
`4`	Подключение	`i_connection`
`5`	Клиент	`i_customer`

Например, активные звонки подключения 64 в среде 1:

snmpget -v2c -On -c fs-monitor-7Qx 203.0.113.10 .1.3.6.1.4.1.36523.1.1.4.2.1.1.64

.1.3.6.1.4.1.36523.1.1.4.2.1.1.64 = INTEGER: 52

ID можно найти в панели: откройте объект и посмотрите значение i_… в адресной строке или получите их через API.

Ретрансляция медиа

OID	Значение
`.1.3.6.1.4.1.36523.1.1.6.1`	Звонки с SDP на обоих плечах, но с RTP только на одном плече
`.1.3.6.1.4.1.36523.1.1.6.2`	Звонки с описанием медиа только на одном плече
`.1.3.6.1.4.1.36523.1.1.6.3`	Звонки с SDP на обоих плечах и без RTP ни на одном
`.1.3.6.1.4.1.36523.1.1.6.4`	Отброшенные пакеты RTP и RTCP, обычно из неизвестных источников

Рост количества звонков с односторонним RTP или без RTP указывает на проблемы с NAT или фаерволом на пути медиа.

Шаг 4: Проверьте настройку

Выполните команду snmpwalk из шага 3 на хосте мониторинга. Она выводит среды.
Сделайте тестовый звонок и выполните snmpget для активных звонков среды (<n> = 2). Пока звонок идёт, значение увеличивается на единицу.