На странице описывается архитектура системы VoIP Monitor. В ней рассказывается о ключевых компонентах системы и объясняются основные модели развертывания: от простой установки «все в одном» до сложных распределенных решений для мониторинга нескольких объектов.

Основные компоненты

Система VoIP Monitor состоит из трёх основных логически разделённых компонентов (VoIP_Monitor Sensor(Slave)/Sensor(Master)/UI(Web_GUI)), которые могут работать на одном сервере или могут быть распределенными между несколькими машинами для обеспечения масштабируемости. Для первоначальной конфигурации/изменений/обновлений также требуется VoIP_Monitor Install Server.

Сенсор (Sniffer)

Сенсоры логически разделяются на Master и Slave. Основная задача slave-сенсора — прослушивание сетевого интерфейса, сбор данных о вызовах и передача их на master. 

Slave является пассивным сетевым анализатором по принципу работы схожим с такими инструментами, как tcpdump или wireshark. Выполняет следующие операции в режиме реального времени:

• Анализ трафика: прослушивает сетевой трафик для определения SIP-сигналов и связанных с ними RTP-потоков (аудио/видео);
• Восстановление вызова: собирает воедино SIP- и RTP-пакеты, относящиеся к одному VoIP-вызову;
• Создание CDR: на основе проанализированных данных создает подробный CDR, который затем отправляется в базу данных MySQL на master-сенсоре.

Master играет роль центрального обработчика информации. Его основной функционал:

• Получение данных о вызовах от одного или нескольких slave-сенсоров;

• Хранение базы данных. VoIPmonitor использует базу данных, совместимую с MySQL, для хранения записей о звонках (CDR), показателей качества связи и системных данных. Все взаимодействия между графическим интерфейсом/сенсором и базой данных осуществляются через стандартный TCP-интерфейс MySQL.

При отсутствии отдельно вынесенных slave-сенсоров master выполняет функции slave. 

Важной функцией сенсоров также является сохранение данных о вызовах (как SIP-, так и RTP-потоки) на локальном диске в стандартном формате PCAP. Это позволяет проводить детальное устранение неполадок на уровне пакетов и воспроизводить вызовы прямо из графического интерфейса. Может выполняться как на slave, так и на master-сенсоре.

Веб-графический интерфейс (UI)

Веб-интерфейс — это основной уровень представления и управления. Он предоставляет мощный интерфейс для анализа вызовов, просмотра статистики и настройки системы. Он может работать на том же сервере, что и база данных и сенсор или на полностью выделенном компьютере.

Install server — виртуальная машина или сервер, на котором выполняется подготовка к установке Voip Monitor и установка или добавление дополнительных сенсоров. Физически может находиться на виртуальной машине/сервере, где устанавливается master-сенсор или же на любом другом, имеющим доступность по протоколу SSH к другим серверам в составе Voip Monitor.

Требования к серверам

Системные требования к slave- и master-сенсорам отличаются ввиду различий выполняемого ими функционала. Ниже приведены таблицы с указанием необходимых ресурсов в зависимости от количества одновременных вызовов.

Slave

Master

Данные таблицы применимы для случая, когда RTP сохраняется централизованно на master-сервере (packetbuffer_sender=yes). Ресурсы slave-сенсора требуются на сбор информации о вызовах и создание метаданных без сохранения RTP. В случае необходимости локального сохранения pcap на slave-сенсоре (packetbuffer_sender=no) следует ориентироваться на вторую таблицу в зависимости от того, сколько одновременных вызовов обрабатывает конкретный сенсор. При этом ресурсы диска для хранения базы данных в обоих случаях будут относиться к master-сенсору.

Для наиболее точного определения необходимого размера диска можно выполнить расчет следующим образом — 2 КБ требуется на одну запись CDR при включенном сжатии таблиц (mysqlcompress = yes). Емкость диска для хранения RTP можно вычислить из расчета:
2 МБ/минута на звонок × количество одновременных вызовов × часов в день × дней хранения.

Также стоит отметить, что сохранение RTP не является обязательным, оно регулируется параметром savertp в конфигурационном файле master-сенсора. Но при отключении данного параметра прослушивание вызовов не будет возможным.

Сценарии развертывания

Мониторинг отдельных VoIP-серверов (ECSS10/SMG и др.)

Для отслеживания работы нескольких VoIP-серверов есть три основных варианта архитектуры в зависимости от топологии вашей сети и требований:

Вариант 1: Универсальный сервер — централизованный мониторинг (рекомендуется для одного центра обработки данных/локальной сети)

Если оба VoIP-сервера находятся в одной локальной сети (в одной стойке/здании), проще всего направить трафик на один выделенный сенсор.

• Как это работает: Настройте сетевой коммутатор на зеркалирование (SPAN/RSPAN) трафика с двух портов VoIP-серверов на один выделенный хост-сенсора VoIP Monitor. Это позволяет централизовать обработку, хранение и управление.
• Преимущество: Управление с помощью одного сенсора, централизованное хранение, упрощенное развертывание.
• Примечание: Требуется настройка коммутатора, а сервер мониторинга должен обрабатывать совокупный трафик со всех источников.

Вариант 2: Распределённая клиент-серверная архитектура: центральный Master/БД + графический интерфейс UI с удалёнными сенсорами Slave (рекомендуется для глобальных сетей/сайтов)

Для более крупных или географически распределённых сред рекомендуется использовать распределённую модель. Как правило, она включает в себя центральный сервер (Master) с графическим интерфейсом (UI либо сервер UI на отдельной машине) и базой данных, который собирает данные с одного или нескольких удалённых сенсоров (Slave). Удалённые сенсоры можно настроить двумя основными способами в зависимости от ресурсов, доступных на устройстве, на котором осуществляется сбор трафика.

• Как это работает: Установите облегчённый сенсор (Slave) на каждый VoIP-сервер (ecss1/ecss2). Сервера подключаются к центральному более мощному серверу (Master + графический интерфейс UI + база данных MySQL), который обрабатывает и хранит данные. Доступны два подрежима:
  • Локальная обработка — удаленное зондирование ("packetbuffer_sender=no"): удаленный сенсор "Slave" обрабатывает все пакеты локально, анализируют вызовы, генерирует CDR и сохраняет файлы PCAP на своем диске. Отправляет на "Master" только CDR (метаданные). Идеально подходит для случаев, когда удаленный компьютер обладает достаточным объемом оперативной памяти, ресурсов процессора и дискового ввода-вывода для обработки нагрузки. Подходит для сетей с низкой пропускной способностью, сводит к абсолютному минимуму сетевой трафик между удаленным объектом и центральным сервером;
    
  • Зеркалирование пакетов ("packetbuffer_sender=yes"): Для его реализации требуется пара сенсоров: отправитель (Slave) и получатель (Master). Удаленные сенсоры (Slave), установленные на удалённом SSW/SBC, не выполняют никакой обработки. Он перехватывает все VoIP-пакеты и пересылает их по сжатому TCP-потоку центрального сенсора (Master). Затем Master выполняет всю обработку пакетов от нескольких отправителей. Идеально подходит для сценариев, в которых удалённый SSW/SBC имеет ограниченные ресурсы (или вы не хотите увеличивать нагрузку на неё), а прямое подключение к сети невозможно. 
    
• Преимущество: Централизованное управление и единый обзор по местоположениям. Сенсоры могут работать в режиме с низким потреблением ресурсов.

Вариант 3: Независимые установки (простой, но менее масштабируемый)

Установите полное приложение VoIP Monitor (сенсор + локальная база данных + дополнительный локальный графический интерфейс) на каждый из серверов VoIP.

• Как это работает: Каждый сервер запускает свой собственный полностью независимый экземпляр voipmonitor. Никакой централизации, никакого взаимодействия между ними;
• Преимущество: Абсолютная изоляция (сбой на одном сервере не влияет на другие), отсутствие сетевых зависимостей, простая первоначальная настройка (стандартные установки);
• Недостатки:
  • Занимает больше ресурсов процессора/оперативной памяти/диска на каждом VoIP-сервере (может повлиять на качество связи);
  • Нет единого представления — необходимо входить в систему на каждом сервере отдельно;
  • Больше работы по обслуживанию (отдельные базы данных для обновления, резервного копирования, мониторинга);
  • Нет централизованной отчетности по всем серверам.
• Пример использования: когда полная независимость важнее удобства управления.

Описание модулей

Проект VoIP Monitor состоит из двух модулей VoIP monitor core и VoIP monitor UI.

Каждый из них разворачивается в пяти Docker-контейнерах, которые работают на хостовой сети, поэтому все последующее описание портов и файловой системы относится именно к тому хосту, на котором находится модуль.

VoIP Monitor UI

Клиентский модуль представляет собой три Docker-контейнера, описание которых приведено ниже.

API\BFF (NestJS)

Осуществляется взаимодействие с VoIP Monitor core:

• Cчитывание Истории вызовов. По умолчанию VoIP core записывает данные в MySQL, подключиться к которой можно по порту 3306. Таблица MуSQL содержит всю историю звонков — CDR;
• Прослушивание активных вызовов. VoIP core предоставляет порт 5029 (по умолчанию), на котором есть возможность слушать активные звонки;
• Считывание файловой системы. В процессе работы VoIP core записывает файлы PCAP, которые извлекаются для предоставления пользователю SIP-аналитики на клиенте. Для предоставления аналитики используется zstd и tshark, которые необходимо поставить на хостинг, где стоит VoIP core;
• Пользовательская информация. Во-первых, необходимо сохранять данные по активным сенсорам, которые работают с основным VoIP core в кластере (хотя нет возможности управления масштабированием через API NestJS, информацию о других узлах необходимо сохранять). Во-вторых, необходимо сохранять пользовательскую информацию по пользователям (фильтры и пр.). Для сохранения используется MySQL, который относится к VoIP core (master). 

Таблицы, которые были созданы:

• eltex_alert_cdr
• eltex_alert_group_seq
• eltex_alert_settings
• eltex_migrations
• eltex_sensors
• eltex_user_filter_templates

Client (Angular)

Отображает интерфейс.

Authorization (Keycloak):

Предоставляется базовый функционал авторизации, есть один пользователь по умолчанию, можно создать дополнительных в панели администратора Keycloak. Связан только с контейнером Client (Angular).

VoIP Monitor core

Модуль VoIP Monitor core представляет собой два Docker-контейнера:

• voipmonitor-core-sniffer
• voipmonitor-core-mysql

Варианты использования продукта

UI вынесен на отдельный хост

UI ставится на удаленный от VoIP core хост, подключается к нему по SSH и "пересылает" нужные порты (активные звонки\история вызовов) на свои порты. Файловую систему читает c удаленного хоста VoIP core для снятия детализации по SIP.

UI развернут локально с master-сенсором

UI ставится на локальный VoIP core хост, слушает свои порты, поскольку они заняты VoIP core. Файловую систему читает свою для снятия детализации по SIP.

UI развернут локально с master-сенсором без вынесенных slave-сенсоров

UI ставится на локальный VoIP core хост (master), слушает свои порты, поскольку они заняты VoIP core. Файловую систему читает свою для снятия детализации по SIP. Удаленные slave-сенсоры отсутствуют.