На странице описывается архитектура системы 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.
Требования к серверам
Для использования необходимы операционные системы:
- Ubuntu 22.04 Server или выше;
- astra linux 1.8.3 или выше.
Системные требования к slave- и master-сенсорам отличаются ввиду различий выполняемого ими функционала. Ниже приведены таблицы с указанием необходимых ресурсов в зависимости от количества одновременных вызовов.
Slave
| Одновременные вызовы | CPU | RAM (ГБ) | Сеть (Гбит/с) |
|---|---|---|---|
| 50 | 1 | 4 | 1 |
| 200 | 1 | 6 | 1 |
| 500 | 2 | 8 | 1 |
| 1000 | 2 | 10 | 1 |
| 2000 | 4 | 12 | 1-10 |
| 5000 | 6 | 16 | 10 |
Master
| Одновременные вызовы | CPU | RAM (ГБ) | Сеть (Гбит/с) | Диск RTP (ТБ/неделя) | Диск БД (ГБ/неделя) |
|---|---|---|---|---|---|
| 50 | 1 | 4 | 1 | 0.1 | 1 |
| 200 | 2 | 8 | 1 | 0.5 | 1.5 |
| 500 | 4 | 16 | 1 | 1.25 | 3.5 |
| 1000 | 6 | 32 | 1 | 2.5 | 7 |
| 2000 | 8 | 64 | 1-10 | 5 | 14 |
| 5000 | 16 | 128 | 10 | 10 | 36 |
Данные таблицы применимы для случая, когда 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 имеет ограниченные ресурсы (или вы не хотите увеличивать нагрузку на неё), а прямое подключение к сети невозможно.
- Локальная обработка — удаленное зондирование ("packetbuffer_sender=no"): удаленный сенсор "Slave" обрабатывает все пакеты локально, анализируют вызовы, генерирует CDR и сохраняет файлы PCAP на своем диске. Отправляет на "Master" только CDR (метаданные). Идеально подходит для случаев, когда удаленный компьютер обладает достаточным объемом оперативной памяти, ресурсов процессора и дискового ввода-вывода для обработки нагрузки. Подходит для сетей с низкой пропускной способностью, сводит к абсолютному минимуму сетевой трафик между удаленным объектом и центральным сервером;
- Преимущество: Централизованное управление и единый обзор по местоположениям. Сенсоры могут работать в режиме с низким потреблением ресурсов.
Вариант 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-сенсоры отсутствуют.