你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
呼叫客户端操作日志架构
呼叫客户端操作日志提供有关呼叫终结点和呼叫中涉及的参与者的客户端信息。 这些日志目前处于预览状态,显示呼叫中发生的客户端事件以及客户在呼叫期间执行的操作。
此日志提供有关呼叫期间所采取操作的详细信息,可用于通过使用 Azure 通信服务资源的呼叫诊断来可视化和调查呼叫问题。 详细了解通话诊断
如何使用呼叫日志
建议在 Log Analytics 资源中收集所有可用的呼叫日志,以便监视呼叫使用情况和改进通话质量,并在我们发布新日志时从 Azure 通信服务接收这些日志。
可使用两个主要工具来监视通话并提高通话质量。
建议使用“语音和视频见解”仪表板来启动任何质量调查,并根据需要使用通话诊断,以在需要精细的详细信息时浏览单次呼叫。
数据概念
重要
若要分析日志,必须收集这些日志。 若要了解详细信息,请参阅:如何存储日志?
除非启用这些特定的诊断设置,否则 Azure 不会存储呼叫日志数据。 呼叫数据不可追溯。 创建诊断设置后,将累积数据。
数据定义
呼叫客户端操作日志架构
下表介绍了每个属性。
properties | 说明 |
---|---|
CallClientTimeStamp |
在 SDK 上发生该操作时的时间戳 (UTC)。 |
OperationName |
在呼叫 SDK 上触发的操作的名称。 |
CallId |
呼叫的唯一 ID。 它可从单次呼叫期间连接的所有参与者和终结点中标识相关事件,并且可用于联接来自不同日志的数据。 它类似于通话摘要日志和通话诊断日志中的 correlationId。 |
ParticipantId |
每个呼叫回合(在群组呼叫中)或呼叫参与者(在对等呼叫中)的唯一标识符。 此 ID 是 CallSummary、CallDiagnostic、CallClientOperations 和 CallClientMediaStats 日志之间的主要关联点。 |
OperationType |
呼叫客户端操作。 |
OperationId |
标识 SDK 操作的唯一 GGUID。 |
DurationMs |
呼叫 SDK 操作失败或成功所花费的时间。 |
ResultType |
描述操作成功或失败的字段。 |
ResultSignature |
类似 HTTP 的失败或成功代码(200、500)。 |
SdkVersion |
正在使用的呼叫 SDK 版本。 |
UserAgent |
使用基于浏览器或呼叫 SDK 的平台的标准用户代理字符串。 |
ClientInstanceId |
标识 CallClient 对象的唯一 GGUID。 |
EndpointId |
表示连接到呼叫的各个终结点的唯一 ID,其中 endpointType 定义终结点类型。 当该值为 null 时,意味着连接的实体是通信服务服务器 (endpointType = "Server")。 对于本机客户端,有时可为跨多个呼叫 (correlationId) 的同一用户保留 endpointId 值。 endpointId 值的数量将决定呼叫摘要日志的数量。 对于每个 endpointId 值,都会创建一个单独的摘要日志。 |
OperationPayload |
根据操作而变化的动态负载,可提供更多特定于操作的详细信息。 |
各种呼叫类型的示例数据
呼叫客户端操作日志
以下是“CreateView”操作的呼叫客户端操作日志:
"properties": {
"TenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
"TimeGenerated": "2024-01-09T17:06:50.3Z",
"CallClientTimeStamp": "2024-01-09T15:07:56.066Z",
"OperationName": "CreateView" ,
"CallId": "92d800c4-abde-40be-91e9-3814ee786b19",
"ParticipantId": "2656fd6c-6d4a-451d-a1a5-ce1baefc4d5c",
"OperationType": "client-api-request",
"OperationId": "0d987336-37e0-4acc-aba3-e48741d88103",
"DurationMs": "577",
"ResultType": "Succeeded",
"ResultSignature": "200",
"SdkVersion": "1.19.2.2_beta",
"UserAgent": "azure-communication-services/1.3.1-beta.1 azsdk-js-communication-calling/1.19.2-beta.2 (javascript_calling_sdk;#clientTag:904f667c-5f25-4729-9ee8-6968b0eaa40b). Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
"ClientInstanceId": "d08a3d05-db90-415f-88a7-87ae74edc1dd",
"OperationPayload": "{"StreamType":"Video","StreamId":"2.0","Source":"remote","RemoteParticipantId":"remote"}",
"Type": "ACSCallClientOperations"
}
每个参与者可以有许多不同的呼叫指标。 你可以在 Azure 门户中的 Log Analytics 中运行以下查询,以列出呼叫客户端操作日志中的所有可能操作:
ACSCallClientOperations | distinct OperationName
常见问题解答
如何存储日志?
以下部分将对这一要求进行说明。
默认情况下,Azure 通信服务日志不会存储在 Azure 帐户中,因此你需要开始存储这些日志,以便“语音和视频见解”仪表板和通话诊断等工具正常工作。 要收集这些呼叫日志,需要启用将呼叫数据定向到 Log Analytics 工作区的诊断设置。
数据不会进行追溯性存储,因此仅在配置诊断设置后开始捕获呼叫日志。
按照在 Azure Monitor 中通过诊断设置启用日志为资源添加诊断设置。 建议最初收集所有日志。 了解 Azure Monitor 中的功能后,确定要保留哪些日志以及要保留多长时间。 添加诊断设置时,系统会提示你选择日志。 若要收集所有日志,请选择“allLogs”。
Azure Monitor 的 Log Analytics 中的数据量、保留期和使用情况通过现有的 Azure 数据计量计费。 出于成本考虑,建议根据需要监视数据使用情况和保留策略。 有关详细信息,请参阅控制成本。
如果你有多个 Azure 通信服务资源 ID,则必须为每个资源 ID 启用这些设置。
后续步骤
查看所有语音和视频日志的概述,请参阅:Azure 通信服务呼叫日志概述
了解管理呼叫质量和可靠性的最佳做法,请参阅:改善和管理呼叫质量
了解如何使用呼叫日志通过呼叫诊断来诊断呼叫质量和可靠性问题,请参阅:呼叫诊断