Шаг 17. Потоковая статистика и записи разговоров

Лог-журнал cdr представляет собой текстовый файл, относящийся к конкретной дате. Каждая строчка содержит событие и его базовые атрибуты. Он служит для быстрого анализа истории администратором, имеющим доступ к файловой системе серверов или к API мониторинга (для скачивания лог-журналов). Этот режим работает даже тогда, когда все остальные не настроены или недоступны. Файлы лог-журналов автоматически разбиваются на порции по 100 МБ и по датам. Они автоматически удаляются системой по истечению короткого периода хранения (2 дня), либо при превышении количества файлов в каталоге (20 файлов).

B2B генерирует основные события класса callevents. Дополнительные события класса callevents генерируют также mixer, recmover, asr.

В брокер отправляются события класса callevents. Оттуда их забирает CallStore. Он выстраивает модель вызовов, мониторит сервер сигнализации и медиа-шлюз. Генерирует запасные события для завершения оборванных вызовов. Наполняет модельную БД мастер-домена событиями СОРМ-3. В брокер отправляются задания для микшера. Их генерирует B2B или CallStore. В брокер отправляются задания для recmover. Их генерирует соответствующий микшер, обработавший запись. В брокер отправляются задания для asr. Их генерирует recmover.

В ходе завершения задания каждый из упомянутых сервисов генерирует событие класса callevents и задание для следующего события. При этом callevents на общих основаниях рассылается во все упомянутые выше направления непосредственно с ноды генерации.

Запись микшируется в случае, если она велась локальными сервисами.

Экземпляры роли Mixer являются конкурирующими подписчиками боркера на очередь c паттерном "mixer.tasks", которая наполняется экземплярами роли B2B или CallStore на основе CDR-событий, связанных с окончанием звонка. Им последовательно производится:

Результатом микширования является моно или стерео аудиофайл в кодеке MP3, G.711 или G.610 – кодек и битрейт настраиваются в опциях роли. Целевая задача по микшированию аудио- (и видео-) требовательна к ресурсам. Легко можно дать такую нагрузку на сайт, что количество трафика, подлежащего микшированию и упаковке, превысит производительность одного сервера. Поэтому роль Mixer резервируется и масштабируется в режиме Active-Active. В конфигурации плотно нагруженной системы целесообразно для ролей Mixer предусматривать отдельные серверы, аналогично ролям MG.

Файловое хранилище для записей разговоров – это внешний сетевой диск, либо S3-хранилище, точка доступа к которому определяется в списке хранилищ. В случае, если файловое хранилище оказывается недоступным, Mixer продолжает работу, складируя результаты на локальном диске. При восстановлении доступа к хранилищу файлы автоматически переносятся. Поэтому для роли Mixer помимо производительного процессора важно наличие свободного места на локальном диске.

Сервис recmover работает в режиме active-passive в рамках сайта. Он является подписчиком брокера и генератором события callevents.records_moved. RecMover переносит данные в хранилища, настроенные в рабочих доменах - это либо локальный диск, либо NFS, либо S3.

Работоспособность критических коммуникационных процессов системы не зависит от доступности и производительности консьюмеров событий и баз данных. Однако от этого зависит функция сохранения истории событий и смежные с ней функции: доступ к журналам звонков, прослушивание записей разговоров, построение отчетов на основе истории звонков.

Роль WSSubscr содержит все веб-сокет подписки на все классы событий. Подписка осуществляется через WebSocket API роли WS. Подписка может быть создана только на время, и продлевается. Подписка устанавливает категории и типы интересующих событий, а также фильтр по связанным с событием учетным записям пользователей.

Так например, некоторая внешняя система может произвести две подписки на события callevents:

В результате этого роль WSSubscr будет уведомлять внешнюю систему о каждом звонке 101 и 102, причем по звонкам 102 будет отправляться весь ряд событий, а по звонкам 101 только dlg_start и dlg_stop. При этом, если вдруг произойдет разговор 101 и 102, то события dlg_start и dlg_stop не будут дублироваться.

Подписка осуществляется в рамках домена, в котором производится авторизация внешней системы. То есть звонки между пользователями других доменов не отправляются подписчику. Зато отправляются события по домену со всех сайтов, где домен обслуживается (хотя это имеет смысл только, если в домене не используется продуктовый слой, с необходимостью требующий точку целостности данных).

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

Рядом с каждым звонком на том же сайте может быть активен сценарий контекста звонка, обрабатывающий все события. Этот сценарий создается администратором мастер-домена. Что может делать сценарий? Всё, что настроил администратор. Например, он может обрабатывать события самостоятельно. Либо инициировать запуск контекстных сценариев в дочерних доменах, а затем пересылать им события. А те в свою очередь создаются администраторами доменов, и могут, например, отправлять события во внешние системы, соблюдая какие-то кастомные протоколы.

Контекстный сценарий может быть настроен также в рабочем домене. Он будет получать все события класса callevents, сгенерированные в вызова, инициированых абонентами домена (в том числе сервисами).

Если возникает необходимость сохранять все события CDR, то целесообразно в мастер домене настроить подключение к внешнему брокеру KAFKA. Каждое событие отправляется непосредственно с ноды, его сгенерировавшей на один из доступных эндпойнтов.