随着越来越多的用户将生产应用迁移到云平台，一些传统 IT 的运维功能也相应的需要改变，例如监控，备份等等。我们希望通过这一系列的文章来协助用户更好的理解在 Azure 云平台上实现资源监控的方法。
在今后的系列文章中，我们会详细介绍详细的 Azure 平台的一些监控服务。由于很多用户以虚拟机方式迁移之前本地数据中心的生产环境，我们就从虚拟机的监控作为切入点。今天的内容就从最基本的了解虚拟机的性能指标开始。
我们知道 Azure 的宿主机是基于 Hyper-V 平台，从平台层面，无论运行的是 Windows 还是 Linux 的虚拟机，Hyper-V 平台都可以针对虚拟机这个对象来提供一定的性能指标。具体的技术实现细节可以参考： 资源监视介绍。对于磁盘和网络的指标很容易理解。而 CPU 的计算相对复杂，建议可以仔细阅读其中关于 CPU 资源的详细解释。
| 计数器 | 说明 |
|---|---|
| Disk Read Bytes | 上一个采样周期内的磁盘读取数据量 |
| Disk Read Operations/Sec | 虚拟机的各个磁盘上每秒读操作次数的总和 |
| Disk Write Bytes | 上一个采样周期内的磁盘写入数据量 |
| Disk Write Operations/Sec | 虚拟机的各个磁盘上每秒写操作次数的总和 |
| Network In | 虚拟机所有网卡上的进站数据总量 |
| Network Out | 虚拟机所有网卡上的出站数据总量 |
| Percentage CPU | 虚拟机的 CPU 资源的总体运行繁忙程度 |
除了由平台层面提供的性能指标，虚拟机可以通过内部运行的应用拓展来提供更细节的性能指标。对于 Windows 和 Linux 虚拟机的性能指标，在这里列出的是本人对这些指标的理解，在不同的操作系统上可能有细微的差别。
Windows 虚拟机
-
内存相关
计数器 说明 Memory\% Committed Bytes in Use 这两个计数器都是关于 Committed Bytes。在 Windows 系统的内存管理中，内存使用遵循 Reserve 和 Commit 的方式。Committed Byes 可以认为是系统确认使用的内存。而系统可以使用的内存是有限的，其上限为内存 + Paging File。当 % Committed Bytes in Use 接近 90%，我们可以认为当前虚拟内存的使用已经接近极限，需要特别留意。 Memory\% Committed Bytes MemoryAvailable Bytes 在系统中现在可以用于直接满足内存申请的内存数量。这个数值包括了内存中的 Standby 内存页列表，Free 内存页列表和全零内存页列表。通常情况，如果此计数器低于内存总数的 10%，需要引起注意。但是对于某些特定的生产压力，如 SQL，Exchange 和 IIS 等，这些应用会从操作系统尽可能多的申请内存来自主管理。因此，仅仅以这一个指标不足以说明是否存在内存不足的问题。通常需要总和考虑 Page/Sec 这个计数器 MemoryCache Faults/Sec Cache Faults 是 Paging Faults 其中的一种，通常由于系统尝试访问一个打开文件的某些段数据时，该段数据不在内存中而产生的。注意 Cache Faults 包含 Hard Fault 和 Soft Fault，只有 Hard Fault 的类型才会真正出发磁盘文件读写。一般这个计数器被用作内存分析的辅助判断。 MemoryPage Faults/Sec 这几个计数器是被用作是否存在内存不足情况的最主要计数器。其中 Paging Faults/Sec 指的是系统中产生的内存页交换请求。注意这个请求包含 Hard Fault 和 Soft Fault。Soft Fault 指的是该请求可以不通过从磁盘上读写文件就可以满足，而 hard fault 指的是必须经过物理磁盘读写才可以解决。很显然，hard fault 更影响系统的性能。因此，我们用 Page/Sec 来标注所有的 Hard Fault。当 Hard Fault 引起的磁盘 IO 超过系统 IO 总量的 70% 时，并参照可用内存的数量，我们可以判断是否存在内存不足的问题。 MemoryPage Reads/Sec MemoryPage/Sec MemoryPool Nonpaged Bytes Nonpaged Pool 和 Paged Pool 是操作系统在系统内核定义的两种内存资源。其中 NonPaged Pool 是指这块资源必须存储在物理内存中，而 Paged Pool 可以被写入页面交换文件。这两种资源在操作系统内部是有限的。一旦耗尽会导致系统失去相应。在 64 位系统中，由于地址空间的扩展和内存增大，资源耗尽的问题相对比较少见。监控这两种资源可以判断是否存在特定的资源泄露问题。 MemoryPool Paged Bytes Process(_Total)Working Set Working Set是Windows平台一个常用术语，指的是某个进程在物理内存中使用的内存总量。单个进程的Working Set包含可共享部分（例如DLL文件的代码段）和私有部分（数据段）。其中可以跟踪私有部分的Working Set数值来判断是否内存使用量过高或是否存在内存泄露的问题。 Process(_Total)Working Set Private -
处理器相关
计数器 说明 Processor Information(_Total)Processor Performance Processor Frequency 反映了 CPU 的运行频率而 Processor Performance 反映了 CPU 的运行效能，比如在 CPU 主频的多大范围内运行。在物理系统上，由于 CPU 可能存在一些操作系统之外的功能来提高频率，这个数据有可能超过 100%。而在虚拟机环境中，正常数据应在 100% 以下。通常我们使用 Processor Performance 来判断 CPU 的负载效能。 Processor Information(_Total)Processor Frequency Processor Information(_Total)Parking Status Parking 一般用于物理系统上有效安排系统的使用的物理内核，这样可以在负载较低时关闭一定的 CPU 处理能力而节省能源。在虚拟机的运行环境中处理了解 CPU 的负载状态外，没有特别的意义。 Processor Information(_Total)\% Interrupt Time 系统使用的 CPU 时间片中，用于中断处理程序（ISR）的 CPU 时间。一般这个计数器的数值很低，在 5% 以下。如果数值较高，很有可能是硬件出现问题导致中断异常。 Processor Information(_Total)\% Processor Time Windows 操作系统中，由于将代码运行模式划分为内核态（kernel mode）和用户态（User Mode），因此代码的运行时间也就相应被划分为 % Privileged Time 和 % User Time。而两者的总和为 % Processor Time。一般来讲，桌面应用程序和系统服务的 CPU 异常，反映在 User Time 上，而硬件，驱动程序和内核异常反映在 % Privileged Time 上。 Processor Information(_Total)\% Privileged Time Processor Information(_Total)\% User Time -
系统资源，进程相关
计数器 说明 Process(_Total)\% Processor Time 操作系统会以每秒 100 次的频率产生内部中断，中断处理程序会去检查当时 CPU 上运行的各个线程，从而以次数来推断该线程/进程占用的时间片，继而计算出全部进程的 CPU 时间占用，即便单个进程的 CPU 统计可能有些的偏差，总计的数值应该精确的反应了 CPU 的负载压力。 Process(_Total)Handle Count 进程的句柄数一半代表了进程访问的系统对象的数目。通过判断句柄数过高，或者有异常增长状况，可以判断是否存在资源使用异常，或是泄露问题。 Process(_Total)Page Faults/sec 此计数器同 Memory/Page Faults/sec 意义相同，只是将各个进程引起的 Page Faults 累加得到。 Process(_Total)Private Bytes 所有进程的私有内存空间（可以是在物理内存中，或者是在内存交换文件中的空间）总和。一般使用这个计数器来跟踪私有内存空间的变化趋势，从而判断是否有内存泄露的问题。 Process(_Total)Thread Count 所有进程中的线程数目总和。在 Windows 系统中，线程是真正执行代码的单元。线程数目可以反应出当前系统中运行的代码单元的多少。线程数目的异常变化，一定程度上反应了系统的负载变化。 SystemProcesses 当前操作系统中运行的进程和线程总数。 SystemThreads Thread(_Total)Context Switches/sec Context Switch 指的是在 CPU 上运行的线程被其他线程替代。在 Windows 系统中，Context Switch 是一个正常线程处理操作。这个数据的高低并不代表系统是否异常。系统管理员也无法对这个数据进行调整。通常我们可以根据长期观察到的单个系统上的 Context Switch 数值作为此系统的一个基础数值。只有出现极度异常的量级改变时，才需要引起注意。而这类问题也多发于物理设备异常。 -
磁盘相关
计数器 说明 PhysicalDisk(_Total)Disk Read Bytes/sec 所有磁盘上的每秒读或写的数据量 PhysicalDisk(_Total)Disk Write Bytes/sec -
网络相关
计数器 说明 TCPv4Connection Failure 连接失败的数量。连接失败指的是连接的状态从 SYN-SENT 或是 SYN-RCVD 直接被置为 CLOSED，或者是从 SYN-RCVD 状态置为 LISTEN。 TCPv4Connection Established 当前系统中 TCP 连接的状态是 ESTABLISHED 或 CLOSE-WAIT 的数目。 TCPv4Connection Reset 连接被重置的数量。重置指的是 TCP 连接的状态从 ESTABLISHED 或是 CLOSE-WAIT 的直接被置为 CLOSED。 TCPv4Segments Received/sec 当前建立的连接中，每秒接收的数据段，包括错误的数据段。 TCPv4Segments Restransmitted/sec 每秒中重传的数据段数目。重传的数据段指的是数据段中包括 1 个以上的字节数是以前传送过的数据。 TCPv4Segments Sent/sec 当前建立的连接中，每秒发送的数据段。但如果一个数据段中只包含之前的重传数据，则不被计入。
此外，Azure 平台还收集了一些 Windows 系统中应用相关的计数器，如 .Net，由于我们主要讨论的是虚拟机层面的监控，在此就不再具体解释。如果需要，可以参考相应的技术文档，如： .NET Framework 性能指标
Linux 虚拟机
与 Windows 虚拟机不同的是，Windows 虚拟机的某些性能指标指定了 _Total，也就是说系统已经统计了同一个指标在多个实例上的数据，比如多 CPU 系统，多个磁盘系统。在 Linux 虚拟机中，我们可以指定的是针对某一个特定实例还是总计的数值。具体设置请参照 : 使用 Linux 诊断扩展监视性能指标及日志
-
内存相关：
计数器 说明 Mem. Percent available 当前系统的可用内存比例 Mem. Used by cache 系统内存中被磁盘缓存使用的数量 Memory available 当前系统可以使用的内存。可用内存指的是系统在收到内存请求时，可以不需要进行 Paging 操作，而直接可以使用的内存。他包括 Free 的内存和一部分可以被重新使用的 Cache 内存。 Memory percentage 已用内存的比例 Memory used 已用内存的数量 Page reads 每秒中从后端存储中（swap file, program file, mapped file）读取写入总计的内存页的个数。这个数据对应于 Windows 平台的 Pages/Sec。 Page writes Pages Swap available 这些数据分别对应了 swap 文件的可用空间大小，可用空间比例，已经使用的比例和已经使用的大小。 Swap percent available Swap percent used Swap used Note
对于可用内存的理解，可以参照文档
-
处理器相关
计数器 说明 CPU DPC time 在 Linux 中很少提到 DPC Time, DPC 是在 Windows 平台中常用的一个术语，是中断处理程序将一些可以不在中断处理进程中的任务，以 DPC 的方式执行。在 Linux 中，这个数据应该是 SoftIRQ 的时间。应该是在 Interrupt 的一部分。 CPU IO wait Time 这个时间很容易被理解为 CPU 等待同步 IO 完成的时间。实际上， IO Wait Time 是，CPU Idle Time 的一个子集。他指的是当某个 CPU 处于空闲状态时，至少有一个任务在等待他的磁盘 IO 完成，进而可以在此 CPU 上继续运行。因此，较低的 IO wait Time 并不能代表理想的磁盘性能，我们必须结合 CPU 的数量，使用率，磁盘的读写性能，读写模式来具体分析。 CPU idle time CPU 在运行空闲进程的时间 CPU Interrupt time CPU 运行在 Interrupt 模式的时间，包括硬件中断和软件中断。 CPU nice time CPU 上运行 niced 进程所用到的时间。niced 进程指的是进程的 nice 级别（Priority）被改变的进程。 CPU percentage CPU 上运行非 Idle 线程的时间比例。 CPU privileged time 在非 Idle 时间内，用于运行 Kernel 模式进程的时间比例 CPU user time CPU 上运行非 niced 进程所用到的时间。 -
磁盘相关
计数器 说明 Disk queue length 磁盘队列长度。对于 Azure 标准存储账户中的磁盘，我们可以认为是 Spindle 是 1 的标准 IDE 磁盘。由于队列长度会影响磁盘 IO 完成的时间，如果 Disk Queue Length 持续高于 1，说明总是有磁盘 IO 在等待处理。需要结合 Disk Transfer Time 来判断当前的 IO 压力是否超过磁盘能力。 Disk read guest OS 每秒磁盘中数据读取的总量 Disk read time 完成每次读 IO 操作时需要的平均时间 Disk reads 每秒磁盘上的进行读操作的次数 Disk total bytes 每秒磁盘中数据传输的总量，包括读取和写入的数据总量。 Disk transfer time 完成每次 IO 操作是需要的平均时间，一般来说，对于生产系统，理想的 IO 操作需要在 10ms 以内完成。超过 10ms，需要对具体的 IO 进行分析并引起注意。如果 IO 完成时间总是在 30ms 甚至以上，磁盘的效能应该不能满足当前的 IO 需求。 Disk transfers 每秒磁盘上的进行读或写操作的次数，也就是经常提到的 IOPS。 Disk write guest OS 每秒磁盘中数据写入的总量 Disk write time 完成每次写 IO 操作时需要的平均时间 Disk writes 每秒磁盘上的进行写操作的次数 -
网络相关
计数器 说明 Network collisions 从系统启动开始发生的网络冲突数量。如果持续出现冲突值表示网络基础架构存在性能瓶颈，而并非服务器。在 Azure 平台上，不应该看到网络冲突的发生。 Network in guest OS 从系统启动开始计算的网络出口流量 Network out guest OS 从系统启动开始计算的网络入口流量 Network total bytes 从系统启动开始计算的网络传输数据总量 Packets received 从系统启动开始计算的接收到的数据包个数 Packets received errors 从系统启动开始计算的接收端数据包错误的个数 Packets sent 从系统启动开始计算的发送的数据包个数 Packets sent errors 从系统启动开始计算的发送端数据包错误的个数
以上是我们在 Azure 的管理门户中常用的性能技术器，在了解了这些计数器内容的基础上，我们可以设定警报，或是自动缩放功能。在下一篇文章中我们会具体了解这些数据是如何被收集并存放的。 立即访问http://market.azure.cn