Обзор журналов вызовов Службы коммуникации Azure

Службы коммуникации Azure предоставляет возможности ведения журнала, которые можно использовать для мониторинга и отладки решения служб коммуникации. Настройте эти возможности с помощью портал Azure.

Содержимое этой статьи относится к журналам, включенным с помощью Azure Monitor (см. также вопросы и ответы). Чтобы включить эти журналы для служб коммуникации, см . раздел "Включить ведение журнала в параметрах диагностики".

Использование журналов вызовов

Мы рекомендуем собирать все доступные журналы вызовов в ресурсе log analytics, чтобы отслеживать использование звонков и улучшать качество звонков и получать новые журналы из Службы коммуникации Azure по мере их выпуска.

Существует два основных инструмента, которые можно использовать для мониторинга звонков и улучшения качества звонков.

• Панель мониторинга аналитики голосовой связи и видео
• Диагностика вызовов

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

Доступные журналы

Вызовы Служб коммуникации Azure создают восемь различных типов журналов, каждый из которых обслуживает определенную цель:

Журналы обновлений сводок вызовов

Быстро поступающие журналы с базовыми метаданными вызова (идентификаторы, метки времени, конечные точки, информация об SDK). Эти данные журнала поступают в Azure Monitor быстрее, чем журналы сводки вызовов. Этот журнал содержит основные сведения о вызове, включая все соответствующие идентификаторы, метки времени, конечные точки и сведения пакета SDK.

• Может содержать несколько строк для каждого участника вызова.
• Содержит последние обновления для каждого участника.
• Полезно для мониторинга и анализа активности вызовов в почти реальном времени.

Дополнительные сведения см. в Схеме журнала обновлений сводки вызовов

Журналы сводки вызовов:

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

• Содержит одну строку для каждого участника вызова.
• Представляет моментальный снимок состояния вызова во время завершения.
• Полезно для анализа и создания отчетов после вызова.

Дополнительные сведения см. в статье " Схема сводного журнала вызовов"

Журналы обновлений диагностики вызовов:

Эти данные журнала поступают в Azure Monitor быстрее, чем журналы диагностики вызовов, и мы рекомендуем использовать эти журналы вместо использования схемы журналов диагностики вызова. Этот журнал содержит сведения о потоке мультимедиа вызовов участника, а также набор метрик, указывающих на качество измерений опыта.

Дополнительные сведения см. в разделе Обновления журнала схемы диагностических вызовов

Журналы диагностики вызовов:

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

Дополнительные сведения см. в "Схема журнала диагностики вызовов"

Вызов журналов операций клиента:

Содержит подробные события клиента приложения вызова. Эти события журнала создаются для каждого EndpointId вызова, а количество созданных журналов событий зависит от операций, выполняемых участником во время вызова.

Дополнительные сведения см. в статье : Схема журнала операций вызова клиента

Журналы статистики мультимедиа клиента:

Содержит подробные значения потока мультимедиа. Эти логи создаются для каждого потока мультимедиа в вызове. Для каждого EndpointId, входящего в состав вызова (включая сервер), Служба коммуникаций Azure создает отдельный журнал для каждого потока данных (например, аудио или видео) между конечными точками. Объем данных, создаваемых в каждом журнале, зависит от длительности вызова и количества потоков мультимедиа в вызове.

В вызове P2P каждый журнал содержит данные, относящиеся к каждому из исходящих потоков, связанных с каждой конечной точкой. В групповом вызове каждый поток, связанный с endpointType = "Server" создает журнал, содержащий данные для входящих потоков. Все остальные потоки создают журналы, содержащие данные для исходящих потоков для всех конечных точек, не являющихся серверами. В групповых вызовах используйте значение participantId в качестве ключа для подключения связанных входящих и исходящих журналов к отдельному подключению участника.

Дополнительные сведения см. в разделе "Схема журнала временных рядов статистики клиентских мультимедиа"

Завершение журналов опроса вызовов:

Эти журналы заполняются, когда клиент веб-звонков отправляет опрос в конце вызова. Эти журналы можно использовать для изучения субъективного восприятия качества звонка от пользователей.

Чтобы узнать больше, см. обзор опроса по завершению вызова

Журналы метрик вызовов:

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

Дополнительные сведения см. в статье " Схема журнала метрик вызовов"

Основные понятия данных

Следующие высокоуровневые описания концепций данных относятся к голосовой связи и видеозвонкам. Эти понятия важны для проверки, чтобы понять смысл данных, захваченных в журналах.

Сущности и идентификаторы

Ознакомьтесь со следующими терминами:

• Вызов: как представлено в данных, вызов является абстракцией, показанной correlationId. Значения для correlationId уникальны для каждого вызова и зависят от времени по параметрам callStartTime и callDuration.

• Участник. Представляет соединение между конечной точкой и сервером. Участник (participantId) присутствует только в том случае, если вызов является групповым вызовом.

• Конечная точка: самая уникальная сущность, представленная endpointId. Каждый вызов — это событие, содержащее данные из двух или нескольких конечных точек. Точки доступа представляют участников вызова.

  EndpointType указывает, является ли конечная точка пользователем (ТСОП или VoIP), ботом или сервером, который управляет несколькими участниками в вызове. Если значение равноendpointType, конечная "Server" точка не назначается уникальному идентификатору. Вы можете проанализировать endpointType и количество значений endpointId , чтобы определить, сколько пользователей и других участников, не являющихся пользователями (ботами и серверами) присоединяются к вызову.

  Нативные пакеты SDK для Android и iOS повторно используют одно и то же endpointId значение для пользователя в нескольких обращениях, чтобы получить понимание опыта между сеансами. Этот процесс отличается от веб-ориентированных конечных точек, которые всегда генерируют новое значение endpointId для каждого нового вызова.

• Stream: самая детализированная сущность. Для каждого направления (входящего или исходящего) и mediaType значения (например, Audio или Video) существует один поток.

Вызовы P2P и групповые звонки

Существует два типа вызовов, представляемых с помощью callType:

• Одноранговый вызов (P2P): подключение между двумя конечными узлами без конечного узла сервера. Вызовы P2P инициируются как вызов между этими конечными точками и не создаются как событие группового вызова перед подключением.

  

• Групповой вызов: любой вызов, имеющий более двух подключенных конечных точек. Групповые вызовы включают конечную точку сервера и подключение между каждой конечной точкой и сервером. Вызовы P2P, добавляющие другую конечную точку во время вызова, перестают быть P2P, и они становятся групповым вызовом. Можно определить временную шкалу того момента, когда каждая конечная точка присоединилась к вызову, используя метрики participantStartTime и participantDuration.

  

Примеры различных типов вызовов

Пример: вызов P2P

На следующей схеме представлены две конечные точки, подключенные непосредственно в вызове P2P. В этом примере служба связи создает два журнала сводки вызовов (по одному для каждого participantID значения) и четыре журнала диагностики вызовов (по одному для каждого потока мультимедиа).

Для участников вызовов, использующих клиента Службы коммуникации Azure, также существует ряд журналов операций клиента вызовов и журналов временных рядов статистики носителей клиента вызовов. Точное количество этих журналов зависит от типа операций ПАКЕТА SDK и длительности вызова.

Пример: групповой вызов

На следующей схеме представлен пример группового вызова с тремя participantId значениями (что означает три участника) и конечной точкой сервера. Несколько значений для endpointId потенциально могут быть видны у нескольких участников, например, когда они снова подключаются к вызову с одного и того же устройства. Службы коммуникации создают один журнал сводки вызовов для каждого participantId значения. Он создает четыре журнала диагностики вызова: по одному для каждого мультимедийного потока на participantId.

Для участников вызова в Службе коммуникации Azure журналы операций клиента вызова совпадают с вызовами P2P. Для каждого участника вызова через SDK существует ряд логов операций клиента.

Для участников Службы коммуникации Azure клиента вызова журналы операций и журналы временных рядов статистики клиента вызова аналогичны вызовам P2P. Для каждого участника, использующего SDK для звонков, существует ряд журналов операций вызова клиента и журналы временных рядов статистики клиентских медиа.

Пример: вызов P2P между клиентами

На следующей схеме представлены два участника в нескольких арендаторах, которые подключены непосредственно для P2P вызова. В этом примере Службы коммуникации создают один журнал сводки вызовов (по одному для каждого участника) с редактируемыми версиями ОС и пакета SDK. Службы связи также создают четыре журнала диагностики вызовов (для каждого потока мультимедиа). Каждый журнал содержит данные, относящиеся к исходящему потоку participantID.

Пример: групповая связь между арендаторами

На следующей схеме представлен пример группового вызова с тремя participantId значениями для нескольких арендаторов. Службы коммуникации создают один журнал сводки вызовов для каждого участника с редактируемыми версиями ОС и пакета SDK. Службы коммуникации также создают четыре журнала диагностики вызовов, относящиеся к каждому participantId значению (по одному для каждого потока мультимедиа).

Часто задаваемые вопросы

Как я могу хранить логи?

В следующем разделе объясняется это требование.

Службы коммуникации Azure не хранят журналы в вашей учетной записи Azure по умолчанию, поэтому вам необходимо начать их хранение, чтобы средства, такие как панель мониторинга голосовой и видеосвязи и диагностика вызовов, могли работать. Чтобы собрать эти журналы вызовов, необходимо включить параметр диагностики, который направляет данные вызова в рабочую область Log Analytics.

Данные не хранятся ретроактивно, поэтому вы начинаете записывать журналы вызовов только после настройки параметра диагностики.

Следуйте инструкциям по добавлению параметров диагностики для ресурса в разделе "Включить журналы" с помощью параметров диагностики в Azure Monitor. Рекомендуется сначала собрать все журналы. После понимания возможностей в Azure Monitor определите, какие журналы необходимо сохранить и как долго. При добавлении параметра диагностики вам будет предложено выбрать журналы. Чтобы собрать все журналы, выберите allLogs.

Плата за объем данных, хранение и использование в Log Analytics в Azure Monitor взимается через существующие счетчики данных Azure. Рекомендуется отслеживать использование данных и политики хранения с учетом затрат по мере необходимости. Дополнительные сведения см. в разделе "Управление затратами".

Если у вас несколько идентификаторов ресурсов Служб коммуникации Azure, необходимо включить эти параметры для каждого идентификатора ресурса.

Дальнейшие шаги

• Ознакомьтесь с рекомендациями по управлению качеством и надежностью звонков, см. статью "Улучшение качества звонков и управление ими".

• Узнайте о панели мониторинга аналитики для мониторинга журналов голосовых звонков и видеозвонок.

• Узнайте, как использовать журналы вызовов для диагностики качества и надежности вызовов, см. в статье " Диагностика звонков"