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

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

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

Внимание

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

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

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

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

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

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

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

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

Службы коммуникации Azure создает восемь журналов вызовов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вызов журналов статистики мультимедиа клиента:

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

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

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

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

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

Дополнительные сведения см. в статье "Завершение опроса вызовов"

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

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

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

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

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

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

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

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

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

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

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

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

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

Вызовы P2P и группы

Примечание.

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

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

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

  

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

  

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

Разделы справки хранить журналы?

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

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

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

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

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

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

Следующие шаги

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

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

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