性能是为了确保工作负载获取必要的资源，而性能管理在很大程度上是一项消除活动。该方法对每一层进行划分，并确定该层是否导致出现性能问题。必须具有单个衡量指标用于指示某个特定层是否正常运行。此主要衡量指标恰当地命名为关键性能指标 (KPI)。

该 KPI 的计算方法是将 Horizon 性能阈值应用于构成 KPI 的每个衡量指标。
图 1. KPI 衡量指标

每个衡量指标（如磁盘延迟）有四个范围：绿色、黄色、橙色和红色。

为了便于监控，该范围对应于 0–100%。绿色对应于 75–100%，红色对应于 0-25%。将 100% 分为四个相等的范围，使每个范围都具有适当的大小条带。

上述技术支持将具有不同单位的衡量指标组合在一起。其中每个对应于同一条带，即一个百分比。

将衡量指标正确对应于四个范围的逻辑需要五个衡量指标，而不是四个。例如，在磁盘延迟中：

  • 如果为 41 毫秒，则为 0%（红色），因为红色的上限为 40 毫秒。

  • 如果为 35 毫秒，则为 12.5%，因为位于 30 毫秒和 40 毫秒的中间，并且为红色。

  • 如果为 30 毫秒，则为 25%，因为位于红色和橙色的边框上。

将每个衡量指标转换为 0–100% 范围后，可利用平均值（而不是峰值）得出 KPI 衡量指标。使用平均值是为了避免任何衡量指标在 KPI 值中占主导地位。如果有衡量指标对您的运维至关重要，则可以对此使用警示。使用平均值可反映实际情况，因为每个衡量指标的占比相同。

注： 在某些衡量指标中，红色并不表示存在紧急情况，以及用户面临着真正的性能问题。KPI 背后的动机是为您提供预警并支持主动操作。对于被动操作，应使用警示。

这些仪表板使用 KPI 来显示使用者层的 Horizon 会话性能以及 Horizon 基础架构层的工作负载整体性能。这些仪表板专为 Horizon 架构师或首席管理员而设计。它们提供桌面即服务的数据中心部分的整体性能。

从性能管理角度看 Horizon

对于性能监控和故障排除，Horizon 类似于客户端/服务器架构，其中客户端通过 WAN 网络。网络和数据中心组件相互独立，它们使用不同的衡量指标集，并且必须单独作为一个实体进行监控。它们有自己的一组修复操作。在大型企业中，网络由单独的团队负责。

之后，Management Pack for Horizon 单独进行监控，提供 KPI。

客户端组件是性能监控的最后一个焦点，因为它本质上就像一台电视机。它显示传输的像素，并接受简单的输入。此外，客户端问题往往为孤立问题。但是，网络和数据中心中断可能会影响许多用户。

性能故障排除的三个流程

性能管理包括三个不同的流程，分别是：

  • 计划：在此流程设置性能目标。当您构建 vSAN 时，想要磁盘延迟是多少毫秒？在虚拟机级别（而不是 vSAN 级别）衡量的 10 毫秒是良好的开端。

  • 监控。在此流程比较计划与实际情况。实际情况是否与架构所要交付的内容匹配？如果不匹配，必须对其进行修复。

  • 故障排除。当实际情况比计划糟糕时执行此流程，而不是有人投诉时才执行。您不希望在故障排除上花费时间，因此最好主动执行。

性能管理的两个衡量指标

性能的主要计数器是争用。大多数客户都关注利用率，因为他们担心如果利用率很高，可能会出现错误。这就是争用。争用以不同的形式呈现。可以是队列、延迟、已丢弃、已中止或环境切换。

不要将利用率指标超高与性能问题混淆。仅仅因为 ESXi 主机出现内存膨胀、压缩和交换，并不意味着您的虚拟机存在内存性能问题。您可以根据主机为其虚拟机提供服务的情况来衡量主机的性能。虽然与 ESXi 利用率相关，但性能衡量指标不是基于利用率，而是基于争用衡量指标。

集群中的虚拟机可能出现性能不佳的情况，而集群利用率较低。一个主要原因是集群利用率考虑提供者层 (ESXi)，而性能考虑单个使用者（虚拟机）。

图 2. 集群性能不佳的各种可能原因

从性能管理的角度来看，vSphere 集群是资源中最小的逻辑构造块。虽然资源池和虚拟机主机关联性可以提供更小的单元，但在操作上非常复杂，而且无法提供承诺的 IaaS 服务质量。资源池无法提供差异化服务类别。例如，您的 SLA 规定高级桌面比普通桌面快两倍，因为其价格高出 200%。资源池可为高级桌面提供两倍的份额。无法预先确定那些转换为 CPU 就绪的一半的额外份额。

深度和广度

主动监控需要从多个角度进行洞察。如果用户遇到性能导致的问题，您接下来应提出的问题是：

  1. 有多糟糕？您想要衡量问题的深度。

  2. 有多少个用户受到影响？您想要衡量问题的广度。

第二个问题的答案会影响故障排除过程。是孤立事件还是普遍存在？如果是孤立问题，则可以更密切地查看受影响的对象。如果是普遍问题，则可以查看受影响对象之间共享的通用区域（例如集群、数据存储、资源池和主机）。

请注意，您没有问平均性能是多少？因为，在此情况下，平均值已为时已晚。等到平均性能不佳时，可能已有一半的用户受到影响。

当成员数量很大时，Count() 的作用要优于 Percentage()。例如，在一个具有 10 万用户的 VDI 环境中，受影响的用户为五个，占 0.005%。使用计数更容易监控，因为您可以了解实际情形。

整体流

Management Pack for Horizon 仪表板并非孤立设计。它们形成一个流，随着您向下钻取传递上下文。以下示例以鸟瞰视图展示了如何下钻至支持会话的底层虚拟机。第一个仪表板涵盖了 Horizon 环境中的所有 Pod。从该仪表板，可以下钻至 RDS 场或 VDI 池。在每个分支中，可以下钻至单个会话。

设计注意事项

所有性能仪表板都采用相同的设计原则。它们特意采用类似设计，因为如果每个仪表板的外观不同，会让人感到困惑。仪表板具有相同的目标。

仪表板采用自上而下进行设计，包含摘要和详细信息部分。

  • 摘要部分通常放在仪表板的顶部，便于您了解整体情况。

  • 详细信息部分放在摘要部分下方。可在其中下钻至某个特定对象。例如，如果是虚拟机的性能，可以获取特定虚拟机的详细性能。

此外，在此详细信息部分中还设计了快速环境切换，以便于您在性能故障排除期间检查多个对象的性能。例如，“RDS 主机性能”仪表板提供了所有 RDS 主机特定信息，并且无需更换屏幕即可查看 KPI。您可以从一个 RDS 主机移至另一个 RDS 主机并查看详细信息，而无需打开多个窗口。

从用户界面的角度讲，仪表板使用渐进式呈现来最大程度地减少信息过载，并确保网页快速加载。只要您的浏览器会话保持活动状态，就会记住您的最后选择。

颜色作为含义

当使用不同的阈值时，仪表板使用颜色传达含义。

计数器 使用的阈值
KPI

绿色：75% - 100%

黄色：50% - 75%

橙色：25% - 50%

红色：0% - 25%

相应地，阈值集为 25%、50% 和 75%。

红色范围内的项目计数。例如，具有红色 KPI 的 VDI 会话计数。

此值应始终为 0，因为任何 VDI 会话的 KPI 值都不应位于红色范围内。相应地，阈值集为 1、2、3。

如果您希望在计数为 1 时显示红色，则可以将其设置为 0.1、0.2 或 1。

显示的数字应位于绿色区域内 (75%-100%)。平均值可能不是 100%，但目标是在绿色范围内。

表作为见解

表只是一个列表，其中每一行表示一个对象，每一列显示一个值。这将列出数百行，并且能够筛选和排序。每个单元格值也可以采用颜色编码。

表适用于呈现详细信息。但是，总的来说，主要问题是如何随着时间的推移提供见解，因为每个单元格只能容纳一个值。如何深入了解过去发生的情况？例如，如何查看过去 1 周的性能？过去 7 天内有数千个数据点，应挑选哪个数据点？

vRealize Operations Cloud 8.2 中有几个可能的选项

  • 当前数字。说明当前情况非常有用。但是，不会说明五分钟前发生的情况。

  • 一段时间内的平均值。平均值是一个滞后指标。等到平均值不佳时，大约有一半的数字都可能不佳。

  • 一段时间内的最差值。此方法可能过于极端，因为它只需要一个峰值。在某些情况下，数百个数据点中有一个数字可能是异常值。此方法适用于峰值检测，但需要进行补充。

  • 第 95 百分位。这是一个介于平均值和最差值之间的不错中间点。对于性能监控，第 95 百分位比平均值能更好地提供性能摘要。

请同时使用最差值和第 95 百分位数，从第 95 百分位数开始。如果这两个数字相差很大，则表明最差值可能是异常值。

为了更好地了解，请考虑添加第 98 百分位以补充第 95 百分位和最差值。

条形图作为见解

分布图有很多形状，其中条形图是最常见的一种。可使用条形图深入剖析大型数据集。例如，vSphere 共享数据存储按剩余容量显示。它们分为五段，从最小剩余容量到最大剩余容量。每段都分配有一种颜色来传达含义。大于 80% 的容量用灰色表示，因为大量容量未使用表示资源浪费。