Мониторинг SoftEther VPN написанный на python. Методика сбора данных: JSON RPC API

Требования

• fping системная утилита fping, нужна в случае если будет использоваться мониторинг сетевых задержек.
• zabbix протестирован на версии 6.4.
• python3 и его пакеты: requests, re, sys, urllib3 и прочие.
• SoftEtherVPN c поддержкой JSON RPC API. Проверено на beta v4.34 build 9745

Установка На примере AlmaLinux 8

• dnf install -y fping python3{,-requests}
• Копируем sevpn.conf файл в *conf.d каталог заббикс агента
• Копируем все .py файлы из каталога scripts/ репозитория в каталог скриптов заббикс агента (если скрипты на Вашем сервере лежат не в /etc/zabbix/scripts/, то необходимо исправить файл sevpn.conf)
• В файле sevpn.ini указать пароль.
• Если используется мониторинг сетевых задержек (он по-умолчанию включен), то для корректной работы необходимо установить параметры Timeout для zabbix-agent и zabbix-server/proxy в 18 и 20 секунд соответственно. Это нужно потому, что утилита fping по умолчанию использует 10 пакетов для проверки + время выполнения самого скрипта. Если не указать достаточно большое значение Timeout, то результаты fping в заббиксе не будут видны, а логи заббикс сервера/прокси будут содержать ошибки по типу "first network error"
• Импортируем файл шаблона из репозитория в заббикс фронтэнд.

Тонкая настройка сетевого мониторинга Мастер элемент данных с ключем get.ping вызывает метод собирающий информацию о сетевых задержках по внешним (интернет) и внутренним (каскады sevpn) каналам. Для того чтобы активировать мониторинг сетевых задержек по внутренним каналам необходимо, чтобы имя Вашего каскада имело следующий формат: target-name:[CIDR|FQDN]

• target-name - любое строковое значение не содержащее символ ':' (потому что он используется для отдлеления адреса)
• CIDR - валидный ip адрес, FQDN - имя узла которое может быть разрешено в ip.

Пример: Пусть у нас существует виртуальный хаб OFFICE и в нем создаем каскад. Назовем наш каскад main_office:192.168.0.1 По моей задумке 192.168.0.1 это ближайший узел по ту сторону каскада (т.е. чтобы мониторить задержки и потери только внутри каскада и не подмешивать сюда любые другие next hop узлы). По-этому рекомендуется, чтобы у двух узлов между которыми создается каскад были сетевые интерфейсы с ip адресами пинг между которыми будет проходить внутри только этого каскада и не более. Технически можно пинговать любой другой узел, но не вижу в этом особого смысла.

В шаблоне по-умолчанию создано несколько макросов:

• {$VPN_PROC_NAME} - имя процесса sevpn в системе (участвует в подсчете необходимого количества запущенных процессов в системе Linux. Привязан триггер.)
• {$VERSION} - по задумке должен был использоваться для опредления места где SEVPN остался не обновленным.
• ${SEVPN_PING_COUNT} - каким количеством пакетов будет осуществлена проверка канала. По-умолчанию: 10 (пакетов)

Пинги и потери внешних узлов:

• {$SEVPN_EXT_PING_HIGH} - начальный уровень эскалации. Когда пинг превышает допустимый порог. По-умолчанию: 150 (ms)
• {$SEVPN_EXT_PING_VERY_HIGH} - следующий уровень эскалации. По-умолчанию: 500 (ms)
• {$SEVPN_EXT_PING_TOO_HIGH} - максимальный уровень эскалации. По-умолчанию: 1500 (ms)
• {$SEVPN_EXT_LOSS_HIGH} - процент потерь пакетов который будет считаться достаточно выхоким, чтобы отобразить алерт. Значение по-умолчанию - 10 (%)
• {$SEVPN_EXT_LOSS_VERY_HIGH} - следующий уровень эскалации по потерям пакетам. Значение по-умолчанию - 20 (%)
• {$SEVPN_EXT_LOSS_TOO_HIGH} - максимальный уровень эскалации по потерям пакетов. Значение по-умолчанию - 40 (%) Примечание: т.к. для пинга по умолчанию используется 10 пакетов, то нет смысла в этих макросах указывать значения не кратные 10. Т.к. если при проверке из 10 пакетов потеряется 1, то это будет 10% потерь. Укаызвать 5% или 15% нет особого смысла. Увеличение количества пакетов при проверке увеличивает время обработки запроса и, следовательно, заставляет повышать Timeout в настройках агента/прокси/сервера.

Пинги и потери внутренних узлов:

• {$SEVPN_INT_PING_HIGH} - начальный уровень эскалации. Когда пинг превышает допустимый порог. По-умолчанию: 150 (ms)
• {$SEVPN_INT_PING_VERY_HIGH} - следующий уровень эскалации. По-умолчанию: 500 (ms)
• {$SEVPN_INT_PING_TOO_HIGH} - максимальный уровень эскалации. По-умолчанию: 1500 (ms)
• {$SEVPN_INT_LOSS_HIGH} - процент потерь пакетов который будет считаться достаточно выхоким, чтобы отобразить алерт. Значение по-умолчанию - 10 (%)
• {$SEVPN_INT_LOSS_VERY_HIGH} - следующий уровень эскалации по потерям пакетам. Значение по-умолчанию - 20 (%)
• {$SEVPN_INT_LOSS_TOO_HIGH} - максимальный уровень эскалации по потерям пакетов. Значение по-умолчанию - 40 (%)

После успешного Discovery для всех каскадов будет возможность тонкой настроки значений потерь и задержек. Потому что единое значение пинга неудобно. В зависимости от качества канала и удаленности сервера пинг до одного сервера в 500ms может быть очень хорошим значением, а для другого в 300ms - не важным. Для этого можно создать именованные макросы: {$SEVPN_INT_PING_HIGH:"main_office"} = 500 - данная настройка задаст индивидуальный порог для каскада main_office, и триггер по нему не будет загараться, в то время как для остальных будет действовать значение по-умолчанию.

Быстрая проверка

• Запустить sudo -u zabbix zabbix_agentd -t sevpn[hub.discovery]

На выходе должнен получиться валидный JSON-объект.