你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 通信服务通话日志概述
Azure 通信服务提供的日志记录功能可用于监视和调试通信服务解决方案。 通过 Azure 门户配置这些功能。
本文中的内容指的是通过 Azure Monitor 启用的日志（另请参阅常见问题解答）。 要为通信服务启用这些日志，请参阅在诊断设置中启用日志记录。
如何使用通话日志
建议在 Log Analytics 资源中收集所有可用的通话日志，以便监视通话使用情况和改进通话质量，并在我们发布新日志时从 Azure 通信服务接收这些日志。
可使用两个主要工具来监视通话并提高通话质量。
建议使用“语音和视频见解”仪表板来启动任何质量调查，并根据需要使用通话诊断，以在需要精细的详细信息时浏览单次通话。
可用日志
Azure 通信服务创建八个通话日志：
通话摘要更新日志：
此类日志数据到达 Azure Monitor 的速度比通话摘要日志快，我们建议使用这些日志而不是通话摘要日志架构。 该日志包含有关通话的基本信息，包括所有相关 ID、时间戳、终结点和 SDK 信息。
若要了解详细信息，请参阅：通话摘要更新日志架构
通话摘要日志：
该日志是通话摘要更新日志架构的子集， 包含有关通话的基本信息，包括所有相关 ID、时间戳、终结点和 SDK 信息。 为实现更低的日志延迟，请改用通话摘要更新日志。
若要了解详细信息，请参阅：通话摘要日志架构
通话诊断更新日志：
此类日志数据到达 Azure Monitor 的速度比通话诊断日志快，我们建议使用这些日志而不是通话诊断日志架构。 此日志包含有关参与者通话媒体流的信息，以及一组指示通话体验质量度量的指标。
若要了解详细信息，请参阅：通话诊断更新日志架构
通话诊断日志：
该日志是通话诊断更新日志架构的子集， 包含有关流的信息，以及一组指示通话体验质量度量的指标。 为实现更低的日志延迟，请改用通话摘要更新日志。
若要了解详细信息，请参阅：通话诊断日志架构
通话客户端操作日志：
包含详细的通话客户端事件。 这些日志事件是针对呼叫中的每个 EndpointId 生成，生成的事件日志的数量取决于参与者在呼叫期间执行的操作。
若要了解详细信息，请参阅：通话客户端操作日志架构
通话客户端媒体统计信息日志：
包含详细的媒体流值。 这些日志针对呼叫中的每个媒体流生成。 对于呼叫中的每个 EndpointId（包括服务器），Azure 通信服务会为终结点之间的每个媒体流（例如音频或视频）创建一个不同的日志。 每个日志中生成的数据量取决于呼叫的持续时间和呼叫中的媒体流数。
在 P2P 呼叫中，每个日志都包含与各个出站流相关的数据，而各个出站流则与各个终结点关联。 在组呼叫中，与 endpointType = "Server" 关联的每个流都会创建一个日志，其中包含入站流的数据。 所有其他流都会创建包含所有非服务器终结点的出站流数据的日志。 在群组呼叫中，将使用 participantId 值作为密钥从而将相关的入站和出站日志加入到单独的参与者连接中。
若要了解详细信息，请参阅：通话客户端媒体统计信息时序日志架构
通话调查结束日志：
当 Web 通话客户端在通话结束时提交调查时，系统将填充这些日志。 你可以使用这些日志来了解用户对通话质量的主观感知。
有关详细信息，请参阅通话结束调查概述
通话指标日志：
此类日志包含基于 SDK 版本、OS 名称和错误子代码等属性，按每日时间区间汇总的通话指标。 这些日志用于语音和视频见解仪表板，根据各种操作的成功和失败通话的 SDK API 通话计数来可视化可靠性、质量和性能的长期图表。
若要了解详细信息，请参阅：通话指标日志架构
数据概念
以下对数据概念的大致描述特定于语音通话和视频通话。 务必查看这些概念，以便你可以了解日志中捕获的数据的含义。
实体和 ID
熟悉以下术语：
呼叫：如数据所示，呼叫是由
correlationId描述的抽象。 每个呼叫的correlationId的值都是唯一的，并且是基于callStartTime和callDuration有时限的。参与者：代表终结点和服务器之间的连接。 只有在群组呼叫时，才存在参与者 (
participantId)。终结点：最具唯一性的实体，由
endpointId表示。 每次呼叫都是一个事件，包含来自两个或多个终结点的数据。 终结点代表呼叫的参与者。EndpointType能告诉你终结点是人类用户（PSTN 或 VoIP）、机器人还是管理呼叫中多个参与者的服务器。 当endpointType值为"Server"时，不会为终结点分配唯一的 ID。 可以分析endpointType和endpointId值的数量，以确定有多少用户和其他非人类参与者（机器人和服务器）加入呼叫。适用于 Android 和 iOS 的本机 SDK 会跨多个呼叫为用户重复使用相同的
endpointId值，从而使你能够理解跨会话的体验。 此过程与基于 Web 的终结点不同，后者会始终为每个新呼叫生成新的endpointId值。流：最精细的实体。 每个方向（入站或出站）和
mediaType值（例如Audio或Video）都有一个流。
P2P 呼叫与群组呼叫的对比
注意
在本文中，P2P 和群组通话默认都位于同一租户内。 整篇文章中相应地说明了跨租户的所有通话方案。
呼叫类型（由 callType 表示）有两种：
对等 (P2P) 呼叫：仅在两个终结点之间的连接，无服务器终结点。 P2P 呼叫是作为这两个终结点之间的呼叫而启动的，而不是在连接之前作为群组呼叫事件而创建的。
群组呼叫：连接了 2 个以上终结点的任何呼叫。 群组呼叫包括一个服务器终结点，以及每个终结点和服务器之间的连接。 如果 P2P 呼叫在呼叫过程中添加了其他终结点，则该呼叫不再是 P2P 呼叫，而是成为了群组呼叫。 使用
participantStartTime和participantDuration指标可以确定每个终结点加入呼叫的时间线。
各种通话类型的示例
注意
在本文中，P2P 和群组通话默认都位于同一租户内。 整篇文章中相应地说明了跨租户的所有通话方案。
示例：P2P 呼叫
下图表示 P2P 呼叫中两个直接连接的终结点。 在此示例中，通信服务创建了两个通话摘要日志（每个 participantID 值一个）和四个通话诊断日志（每个媒体流一个）。
对于 Azure 通信服务呼叫客户端参与者，还有一系列呼叫客户端操作日志和呼叫客户端媒体统计信息时序日志。 这些日志的确切数量取决于呼叫的 SDK 操作类型以及呼叫持续时间。
示例：群组呼叫
下图表示具有三个 participantId 值（这意味着三个参与者）和一个服务器终结点的群组呼叫示例。
endpointId 的多个值可能会出现在多个参与者中，例如，当他们从同一设备重新加入呼叫时。 通信服务会为每个 participantId 值创建一个呼叫摘要日志。 它将创建四个通话诊断日志：每个 participantId 的每个媒体流一个。
对于 Azure 通信服务呼叫客户端参与者，呼叫客户端操作日志与 P2P 呼叫相同。 对于每个使用呼叫 SDK 的参与者，都会有一系列的呼叫客户端操作日志。
对于 Azure 通信服务呼叫客户端参与者，呼叫客户端操作日志和呼叫客户端媒体统计信息时序日志与 P2P 呼叫相同。 对于使用呼叫 SDK 的每个参与者，都会有一系列呼叫客户端操作日志和呼叫客户端媒体统计信息时序日志。
示例：跨租户 P2P 呼叫
下图显示了跨多个租户的两个参与者，他们在 P2P 呼叫中直接连接。 在此示例中，通信服务使用经过修订的 OS 和 SDK 版本创建一个呼叫摘要日志（每个参与者一个）。 通信服务还创建四个通话诊断日志（每个媒体流一个）。 每个日志包含与 participantID 的出站流相关的数据。
示例：跨租户群组呼叫
下图显示了一个群组呼叫示例，其中的三个 participantId 值跨多个租户。 通信服务使用经过修订的 OS 和 SDK 版本为每个参与者创建一个呼叫摘要日志。 通信服务还创建了四个与每个 participantId 值相关的通话诊断日志（每个媒体流一个）。
注意
此版本仅支持出站诊断日志。 可以修订与机器人和参与者关联的 OS 和 SDK 版本，因为通信服务以相同的方式处理参与者和机器人的标识。
常见问题解答
如何存储日志？
以下部分将对这一要求进行说明。
默认情况下，Azure 通信服务日志不会存储在 Azure 帐户中，因此你需要开始存储这些日志，以便“语音和视频见解”仪表板和通话诊断等工具正常工作。 要收集这些呼叫日志，需要启用将呼叫数据定向到 Log Analytics 工作区的诊断设置。
数据不会进行追溯性存储，因此仅在配置诊断设置后开始捕获呼叫日志。
按照在 Azure Monitor 中通过诊断设置启用日志为资源添加诊断设置。 建议最初收集所有日志。 了解 Azure Monitor 中的功能后，确定要保留哪些日志以及要保留多长时间。 添加诊断设置时，系统会提示你选择日志。 若要收集所有日志，请选择“allLogs”。
Azure Monitor 的 Log Analytics 中的数据量、保留期和使用情况通过现有的 Azure 数据计量计费。 出于成本考虑，建议根据需要监视数据使用情况和保留策略。 有关详细信息，请参阅控制成本。
如果你有多个 Azure 通信服务资源 ID，则必须为每个资源 ID 启用这些设置。