你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 虚拟桌面见解术语表
本文列出并简要介绍了与 Azure 虚拟桌面见解相关的关键术语和概念。
警报
在订阅中配置并归类为 0 级严重程度的任何有效 Azure Monitor 警报都将显示在“概述”页中。 若要了解如何设置警报，请参阅 Azure Monitor 日志警报。
可用会话数
可用会话显示了主机池中的可用会话数。 此服务通过以下方式计算此数字：将虚拟机 (VM) 的数量与每个虚拟机允许的最大会话数相乘，然后减去总会话数。
客户端操作系统 (OS)
客户端操作系统 (OS) 显示访问 Azure 虚拟桌面资源的最终用户当前使用的 OS 版本。 客户端 OS 还显示用户拥有的 Web (HTML) 客户端和完整远程桌面客户端的版本。 有关 Windows OS 版本的完整列表，请参阅操作系统版本。
连接成功
此项显示连接运行状况。 “连接成功”表示连接可以到达主机，该虚拟机上的堆栈可确认。 连接失败表示着该连接无法到达主机。
每日活动用户 (DAU)
在过去 24 小时内启动会话的用户总数。
每日警报数
每天触发的警报总数。
每日连接数和重新连接数
在过去 24 小时内开始或完成的连接和重新连接的总数。
每日连接小时数
在过去 24 小时内用户连接到会话所用的总小时数。
诊断和错误
Azure 虚拟桌面见解中出现的错误或警报分为以下三类：
活动类别：此类别是 Azure 虚拟桌面诊断对错误进行分类的方式。 类别包括管理活动、源、连接、主机注册、错误和检查点。 有关这些类别的详细信息，请参阅将 Log Analytics 用于诊断功能。
种类：此类别显示错误的位置。
- 标记为“service”或“ServiceError = TRUE”的错误发生在 Azure 虚拟桌面服务中。
- 标记为“deployment”或“ServiceError = FALSE”的错误发生在 Azure 虚拟桌面服务之外。
- 若要了解有关 ServiceError 标记的详细信息，请参阅常见错误情况。
源：该类别提供有关错误发生位置的更具体描述。
诊断：负责监视和报告服务活动的服务角色，使用户能够观察和诊断部署问题。
RDBroker：负责协调部署活动、维护对象状态、验证身份验证等内容的服务角色。
RDGateway：负责处理最终用户和虚拟机之间的网络连接的服务角色。
RDStack：用户可借助安装在 VM 上的软件组件，使 VM 能够与 Azure 虚拟桌面服务进行通信。
客户端：在最终用户计算机上运行的软件，为 Azure 虚拟桌面服务提供接口。 做出选择后，它会显示已发布资源的列表并托管远程桌面连接。
每个诊断问题或错误都包含一条消息，说明发生的错误。 若要详细了解如何排查错误，请参阅识别和诊断 Azure 虚拟桌面问题。
网关区域代码
Azure 虚拟桌面见解中的一些指标列出了用户所连接的网关区域。 网关区域由 3 个或 4 个字母的代码表示，该代码对应于网关所在的 Azure 区域。 下表列出了网关区域代码及其相应的 Azure 区域：
| 网关区域代码 | Azure 区域 |
|---|---|
| AUC | 澳大利亚中部 |
| AUC2 | 澳大利亚中部 2 |
| AUE | 澳大利亚东部 |
| AUSE | 澳大利亚东南部 |
| BRS | Brazil South |
| CAC | 加拿大中部 |
| CAE | 加拿大东部 |
| CHNO | 瑞士北部 |
| CIN | 印度中部 |
| CUS | 美国中部 |
| EAS | 东亚 |
| EEU | 东欧 |
| EUS | 美国东部 |
| EUS2 | 美国东部 2 |
| FRAS | 法国南部 |
| FRC | 法国中部 |
| GEC | 德国中部 |
| GEN | 德国北部 |
| GENE | 德国东北部 |
| GWC | 德国中西部 |
| JPE | 日本东部 |
| JPW | 日本西部 |
| KRC | 韩国中部 |
| KRS | 韩国南部 |
| KRS2 | 韩国 2 |
| NCUS | 美国中北部 |
| NEU | 北欧 |
| NOE | 挪威东部 |
| NOW | 挪威西部 |
| SAN | 南非北部 |
| SAW | 南非西部 |
| SCUS | 美国中南部 |
| SEA2 | 东南亚 2 |
| SEAS | 东南亚 |
| SIN | 印度南部 |
| SWW | 瑞士西部 |
| UAEC | 阿联酋中部 |
| UAEN | 阿拉伯联合酋长国北部 |
| UKN | 英国北部 |
| UKS | 英国南部 |
| UKS2 | 英国南部 2 |
| UKW | 英国西部 |
| WCUS | 美国中西部 |
| WEU | 西欧 |
| WIN | 印度西部 |
| WUS | 美国西部 |
输入延迟
Azure 虚拟桌面见解中的“输入延迟”表示每个会话的每个进程性能计数器的输入延迟。 在“主机性能” (aka.ms/azmonwvdi) 页面上，我们已将此性能计数器配置为每 30 秒向服务发送一次报告。 这 30 秒的间隔称为“示例”，并在该窗口中报告最坏的情况。 中值和 p95 值反映所有示例中的中值和第 95 个百分点值。
在“输入延迟(按主机)”下，你可以选择一个会话主机行，将页面中的所有其他视觉对象筛选到该主机。 还可以选择进程名称，筛选一段时间内的输入延迟的中值。
我们将延迟分为以下几类：
- 好：低于 150 毫秒。
- 可接受：150-500 毫秒。
- 较差：500-2000 毫秒（低于 2 秒）。
- 差：超过 2000 毫秒（2 秒及以上）。
若要了解输入延迟计数器的工作原理，请参阅用户输入延迟性能计数器。
月度活跃用户 (MAU)
在过去 28 天内启动会话的用户总数。 如果数据的存储时间少于或等于 30 天，则在可用数据时间少于 28 天的期间，你可能会看到低于预期的 MAU 和连接值。
性能计数器
性能计数器显示硬件组件、操作系统和应用程序的性能。
下表列出了 Azure Monitor for Azure Virtual Desktop 的建议性能计数器和时间间隔：
| 性能计数器名称 | 时间间隔 |
|---|---|
| Logical Disk(C:)\Avg. Disk Queue Length | 30 秒 |
| Logical Disk(C:)\Avg. Disk sec/Transfer | 60 秒 |
| Logical Disk(C:)\Current Disk Queue Length | 30 秒 |
| Memory(*)\Available Mbytes | 30 秒 |
| Memory(*)\Page Faults/sec | 30 秒 |
| Memory(*)\Pages/sec | 30 秒 |
| Memory(*)\% Committed Bytes in Use | 30 秒 |
| PhysicalDisk(*)\Avg. Disk Queue Length | 30 秒 |
| PhysicalDisk(*)\Avg. Disk sec/Read | 30 秒 |
| PhysicalDisk(*)\Avg. Disk sec/Transfer | 30 秒 |
| PhysicalDisk(*)\Avg. Disk sec/Write | 30 秒 |
| Processor Information(_Total)\% Processor Time | 30 秒 |
| Terminal Services(*)\Active Sessions | 60 秒 |
| Terminal Services(*)\Inactive Sessions | 60 秒 |
| Terminal Services(*)\Total Sessions | 60 秒 |
| *User Input Delay per Process(*)\Max Input Delay | 30 秒 |
| *User Input Delay per Session(*)\Max Input Delay | 30 秒 |
| RemoteFX Network(*)\Current TCP RTT | 30 秒 |
| RemoteFX Network(*)\Current UDP Bandwidth | 30 秒 |
潜在连接问题
潜在连接问题显示了连接失败率较高的主机、用户、已发布资源以及客户端。 选择“报告者”筛选器后，可以检查这些列中的值来评估问题的严重性：
- 尝试（连接尝试数）
- 资源（已发布应用或桌面数）
- 主机（VM 数）
- 客户端
例如，如果选择“按用户”筛选器，则可以在“尝试”列中查看每个用户的连接尝试。
如果你注意到连接问题跨多个主机、用户、资源或客户端，则该问题可能会影响整个系统。 如果不是，则这是较低优先级的问题。
你还可以选择条目以查看其他信息。 可以查看与此问题相关的主机、资源和客户端版本。 还将显示在连接尝试过程中报告的任何错误。
往返时间 (RTT)
往返时间 (RTT) 是最终用户的位置与会话主机的 Azure 区域之间的连接往返时间的估算值。 若要查看哪些位置的延迟最短，请在 Azure 网络往返延迟统计信息中查找所需的位置。
会话历史记录
“会话”项显示所有会话的状态（已连接和已断开连接）。 “空闲会话”仅显示已断开连接的会话。
0 级严重程度警报
你需要立即处理的最紧急的项目。 如果未解决这些问题，则可能会导致 Azure 虚拟桌面部署停止工作。
连接时间
连接时间是指从用户打开资源以启动会话，到桌面完成加载并可供使用之间的时间。 例如，对于 RemoteApp，连接时间是指启动该应用程序所需的时间。
连接时间分为两个阶段：
- 连接，指的是 Azure 服务将用户路由到会话主机所用的时间。
- “登录”，指的是服务执行与登录用户并在会话主机上建立会话相关的任务所用的时间。
在监视连接时间时，请记住以下事项：
连接时间是通过 Azure 虚拟桌面服务诊断数据中的以下检查点来衡量的。 Insights 用于确定连接建立时间的检查点对于桌面与 RemoteApp 方案是不同的。
开始：WVDConnection 状态 = 已启动
结束：WVDCheckpoints 名称 = ShellReady（桌面）；名称 = RdpShellAppExecuted（RemoteApp。对于计时，请考虑仅启动第一个应用）
例如，Insights 根据启动 Windows 资源管理器所需的时间来衡量桌面体验启动的时间。 Insights 还根据启动 shell 应用的第一个实例进行连接所花费的时间来衡量 RemoteApp 启动的时间。
注意
如果用户启动多个 RemoteApp，有时 shell 应用可以在单个连接期间执行多次。 为了准确衡量连接时间，应仅对每个连接使用第一个执行检查点。
建立新会话通常比重新建立与现有会话的连接所需的时间要长，因为新连接和已建立连接的“登录”过程存在差异。
需要从用户连接时间中减去用户提供凭据所用的时间，因为用户可能需要一段时间来输入凭据或使用备用身份验证方法进行登录。
在解决连接时间较长的问题时，Azure Monitor 会将总连接时间数据分解为四个部分，帮助你确定如何缩短登录时间。
注意
本节中的这几个部分只显示主要的连接阶段。 这几个部分可以并行运行，这意味着它们加起来不会等于总连接时间。 总连接时间是 Azure Monitor 在单独的进程中确定的测量结果。
以下流程图显示了登录过程的四个阶段：
流程图显示了以下四个部分：
用户路由：从用户选择 Azure 虚拟桌面图标以启动会话，到服务确定要连接的主机所用的时间。 高网络负载、高服务负载或独特的网络流量路由都可能导致较长的路由时间。 要解决用户路由问题，请查看你的网络路径。
连接堆栈：从服务为用户解析目标会话主机，到服务在会话主机与用户的远程客户端之间建立连接所用的时间。 与用户路由一样，网络负载、服务器负载或独特的网络流量路由都可能会影响连接时间。 对于这一部分，还需要注意网络路由。 要缩短连接时间，请确保已在客户端和会话主机上正确配置所有代理配置，并确保到服务的路由是最佳的。
登录：从建立到与主机的连接，到 shell 开始加载所用的时间。 登录时间包括几个可导致较长连接时间的进程。 你可以在 Insights 中查看“登录”阶段的数据，看看平均时间是否有意外的峰值。
“登录”过程分为四个阶段：
配置文件：为新会话加载用户的配置文件所用的时间。 加载所用的时间取决于用户配置文件的大小或者你所用的用户配置文件解决方案（例如用户体验虚拟化）。 如果你使用的解决方案依赖于网络存储的配置文件，那么过长的延迟也可能会导致配置文件加载时间延长。
组策略对象 (GPO)：将组策略应用到新会话所用的时间。 如果这方面的数据出现峰值，表明你的组策略过多，应用策略所用的时间太长，或者会话主机遇到资源问题。 为了优化处理时间，可以做的是确保域控制器尽可能地靠近会话主机。
shell 启动：启动 shell（通常为 explorer.exe）所用的时间。
FSLogix (Frxsvc)：在新会话中启动 FSLogix 所用的时间。 较长的启动时间可能表明用于托管 FSLogix 用户配置文件的共享存在问题。 要解决这些问题，请确保共享与会话主机在一起，并根据登录到主机的平均用户数量进行适当的调整。 你应该注意的另一个方面是配置文件大小。 如果配置文件较大，可能会增加启动时间。
从 shell 启动到 shell 就绪：从 shell 开始加载，到它完全加载并可供使用的时间。 如果在此阶段出现延迟，可能是由于会话主机重载（高 CPU、内存或磁盘活动）或配置问题导致的。
用户报表
在用户报表页上，你可以查看特定用户的连接历史记录和诊断信息。 每个用户报表都显示了使用模式、用户反馈以及用户在其会话过程中遇到的任何错误。 大多数小问题可以通过用户反馈解决。 如果需要深入了解，还可以筛选有关特定连接 ID 或时间段的信息。
每核心用户数
这是每个虚拟机核心中的用户数。 跟踪一段时间内每个核心的最大用户数有助于确定环境是否以高、低或波动的用户数（每个核心）持续运行。 了解有多少用户处于活动状态有助于有效地为环境提供资源并缩放环境。
Windows 事件日志
Windows 事件日志是由 Windows 虚拟机上的 Azure Monitor 代理或 Log Analytics 代理收集的数据源。 除了由需要监视的应用程序创建的自定义日志，还可以从标准日志，如“系统”和“应用程序”中收集事件。
下表列出了 Azure 虚拟桌面见解所需的 Azure 事件日志：
| 事件名称 | 事件类型 |
|---|---|
| 应用程序 | “错误”和“警告” |
| Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin | “错误”、“警告”和“信息”。 |
| Microsoft-Windows-TerminalServices-LocalSessionManager/Operational | “错误”、“警告”和“信息”。 |
| System | “错误”和“警告” |
| Microsoft-FSLogix-Apps/Operational | “错误”、“警告”和“信息”。 |
| Microsoft-FSLogix-Apps/Admin | “错误”、“警告”和“信息”。 |
后续步骤
- 若要开始，请参阅使用 Azure 虚拟桌面见解来监视部署。
- 若要估计、度量和管控数据存储成本，请参阅估计 Azure Monitor 成本。
- 如果遇到问题，请查看故障排除指南，获取帮助并了解已知问题。
你还可以设置 Azure 顾问，以帮助你确定如何解决或阻止常见问题。 在 Azure 顾问简介中了解更多信息。
如果你需要帮助或有任何问题，请查看我们的社区资源：
可在 Azure 虚拟桌面技术社区向社区提出问题或建议。
若要了解如何留下反馈，请参阅 Azure 虚拟桌面的故障排除概述、反馈和支持。
还可以在 Azure 虚拟桌面反馈中心提供关于 Azure 虚拟桌面的反馈