服务器性能监控的温故知新
服务器层一般是来自多个供应商的硬件和来自多个来源软件的多样化宇宙。通常，解决服务器底层性能问题往往是困难的，或者出于安全原因，很难处理。即使碰巧发现了底层的性能“事件”，传统上测量和分析软硬件性能的工具也较少，而且往往是针对供应商的。因为真正跨平台工具包很少存在，所以没有标准的方法来准确地查看事件、记录事件以供以后分析，或者有效地解决问题。
追踪延迟时间
研究服务器环境性能的第一步是跟踪任何应用程序的事务延迟，从用户的请求事件到最终的屏幕绘制。下一步是绘制服务器拓扑图。为了做到这一点，很多方面都会受到质疑: 网络拓扑、数据库更新(锁)、磁盘阵列、进程调度、 CPU 性能、内存关联性和驱动程序/中断服务时间。然后，使用一组性能分析工具，沿着测量的事务延迟的完整路径研究软硬件环境。用户事务的每个部分应该能够显示出所经历的延迟。性能分析工具应该测量这些元素以及与它们相关的性能降低。
一般要详细研究与事务相关的用户线程以及解决用户读写所需的路径。在调优系统延迟时间的时候，需要遵循两个步骤: 首先，定义用户事务必须执行的每个步骤，以满足用户请求; 然后计算每个步骤的时间。虽然看起来很简单，但是在多节点环境中这可能相当困难。一个问题是找到一个准确的时间基准。NTP (网络时间协议)通常是最好的定时方式。在机器本地，CPU 的时间基础应该是足够的。每一步都必须尽可能准确地定义。每个步骤包括每个数据包的迁移、每个所处理的数据包的交换、每个磁盘设备的交互以及每个网络交互。必须在每个步骤中记录时间戳并保存以便分析。延迟研究中的这些时间戳将确定服务器环境的区域，以便使用性能工具进行检查。
服务器监控的内容
我们必须决定要监控的位置和内容，这可以从对系统事务延迟的研究中得到，还可以监控和分析为用户事务服务的每个组件，并尽可能快地完成每个记录。最后，有一个设备和过程的列表，然后必须找到适当的方法来测量感兴趣的内容。
简单地说，计算机有五类性能分析感兴趣的可测量数据对象: 全局属性、 CPU、网络接口、磁盘和进程。前四个描述了用户的 Unix 计算机的物理属性。全局属性来描述内存、分页和交换特性; 全局文件系统内存使用情况; 以及时间、正常运行时间和负载平均值等其他项。CPU 类别包含中断、交叉调用，以及设备读/写和进程迁移等。网络类别包括物理接口层及其组件，以及逻辑 TCP/IP 层，如套接字的使用等。磁盘类别包括物理磁盘设备、与 CPU 的互连以及通道等。所有这些的基础是磁盘阵列的拓扑结构，通常从 CPU 的角度来看是隐藏的。这四个类别描述了对硬件世界的看法。
最后一类是流程层，在这一层，会首先感受到对监控的大部分需求。例如，用户可能会抱怨响应时间太慢。无论 CPU 是处于热状态还是数据库运行速度都低于正常速度，事件的第一个发生点是关注处于瓶颈的进程。然后，问题就变成了在哪里，发生了什么，以及如何记录延迟事件的对象。
工具箱选择的依据
常用的性能工具是是有限的，例如大多数软件工程师都熟悉sar、 vmstat、 iostat 和 netstat等等，以及其他特定于供应商的工具。然而，一般来说，在一个并行的、线程安全的应用程序系统中，了解系统的平滑响应时间需要一个比传统工具集更全面的性能工具。
性能监控的首要问题是采样时间。大多数第三方工具面向服务器群，收集粗粒度性能数据用于容量规划和服务器负载的热点定位。在分布式环境中，对于测量应用性能的采样时间与容量规划所需的时间不同。成功的性能监控和分析需要细粒度的时序软件以及硬件工具。这些都较难找到。
那么问题就变成了什么是粗粒度，什么是细粒度呢？一般地，将粗粒度定义为在5至30秒或更长时间内采集和储存的采样，细粒度是指采样为百分之一秒至五秒。对于担心事务延迟的软件工程师来说，一秒或更短的时间是必要的。这些系统每秒可能有数以万计的事务，并且从输入包到达到用户数据传输可能需要10毫秒或更短的延迟。监控系统的唯一缺点是，如果决定将所有性能数据收集为日志格式并将其存储到磁盘中时，且监控系统可以支持如此细粒度采样时间的话，这种日志会很大。
服务器环境中的硬件问题集
有没有一个通用问题集呢？它围绕着在可能位于存储区域网络环境中的磁盘阵列上定义用户文件系统所涉及的硬件。在服务器层有几个解决这个难题的局部方法。在最简单的形式中，文件系统是跨磁盘阵列的多个物理磁盘资产定义的。从主机上可以看到文件系统的磁盘有三种方式: 从主机到磁盘阵列的互连; 磁盘阵列本身; 以及作为物理单元呈现给主机系统的磁盘片。对于主机而言，我们可以看到物理元素，可以使用作为一个盘片集合的元素。该元素通常是物理磁盘单元的路径，但有些系统使用多路径驱动程序使问题变得复杂化。
大多数工具可以查看整个文件系统或单个磁盘，但很少有工具可以显示文件系统的性能和用于构建该文件系统的元素。这是至关重要的，因为性能降低可能发生在整个链路的任何环节。SAN环境中可能存在通道故障、退化或交换问题。根据问题的类型，任何元素都会受到不同的影响。
对于磁盘来说，最有用的计量器是平均服务时间。通道路径上的间歇性故障可能是由于错位的 SCSI 连接器、扭曲的光纤电缆或者偶然关闭的缓存。它们通常表现为由服务时间度量的磁盘长延迟。真正的问题是查找文件系统中执行不良的物理元素，并隔离导致延迟的条件。
用户可以编写脚本，以帮助提高在性能工具中定义磁盘单元集合的能力。基本上，这些脚本允许对字节的读/写进行时间序列测量，并允许对元设备及其物理磁盘元素进行服务时间测量。进一步，用户可以选择一个盘片的所有单个元素，查看读/写和服务时间，并以时间序列格式显示数据，这样就可以轻松地发现性能异常，可以快速地将用户指向缓存阵列、通道、 SAN 环境、交换机、共享磁盘阵列资源等。此外，盘片集和元设备的定义可以允许用户对 CPU和网络接口执行类似的操作。然后，用户可以在字段中捕获这样的事件，将其记录下来，并在 GUI 中读取日志，从而显示的服务器实时状态。
例如，在数据库延迟中，问题可能在用户的事务中，也可能是特定数据库交互不及时，或者特定的逻辑文件系统及其物理元素不能按要求执行。一个更全面的性能工具包应该可以找到有问题的硬件或阵列配置错误。
服务器环境中的进程问题
再以数据库更新线程为例，其中的数据库线程与其他几百个重量级和轻量级线程一起在实时数据库中运行。像许多应用程序一样，每个工作日都有大约一个活动高峰时段。线程检查数据库状态和传入数据，以便为服务器层上的其他数据库环境制定数据库更新。这个线程是数据库服务器上计算特定类别数据的几百个线程之一。这个线程中可能有三个生成更新的源，第一个更新源是当前的数据库状态；第二个来源是实时更新，通过一套前端计算机从外部来源接收的；第三个更新来源包括对若干用户事务处理机及其本地数据库的检查。
第一个关注点是在持续的峰值活动期间从这个线程的更新消费者之一注册的。当这个线程变慢时，用户数据库线程的性能会下降。虽然有几个数据库服务器，但只有启用这个流程的服务器存在性能问题，需要分析受影响服务器和未受影响服务器的磁盘阵列性能。
首先，检测磁盘阵列的统计数据，在性能较差的服务器上会存在更多的缓存损失。然后，研究接触该文件系统的线程的 i/o 速率。软件按照设计的方式运行，每次更新都会将体现到磁盘上。当系统变得繁忙时，检查活动增加，直到磁盘阵列缓存中有太多脏页。一旦磁盘阵列缓存被淹没，许多其他进程就会放慢速度。随着整个数据库环境的演变，全局数据库检查点和重新同步变得更加健壮，从而消除了应用程序中对本地每个进程进行检查的一些需求。
适用于所有服务器环境的工具包
一个功能全面的工具包必须满足工程师在当今操作的许多不同的环境。大多数商业安装通常是分离的子网，工程师与物理机器是分离的。甚至到现在，很少有工具能够提供保持所有这些机器正常运行所需的性能指标，也没有一套通用的工具来管理和排除多个云服务器的故障。
一般地，工具包中的主要组件是 CLI 风格的执行文件，它可以在任何服务器上远程运行。计算机的所有指标都被记录以便进行延迟分析。问题往往是在最意想不到的时候显现出来，随机的或者只有当某些条件得到满足的时候才显现出来。24小时不间断地在计算机前实时处理许多问题是不现实的。日志记录工具可以捕获系统崩溃，在特定时间进行调度，或者在满足某些用户设置的条件时对机器活动进行快照。这些日志可以被积累起来并在某个地方进行编排，以便支持重点分析。因此，所有参与者都可以对服务器事故的衡量标准有相同的看法。每个参与者都可以读取服务器事件的相同日志文件，能够从日志文件“播放”记录的服务器性能。故障排除程序可以暂停、回退、快进和循环日志中的区域，以便快速关注有问题的区域。
性能工具包的另一个组件应该是一个分析工具，帮助工程师在采样数据中找到与任何用户定义的基线不一致的东西。可以定义一个规则引擎，该引擎可以侦听计算机并在某些参数超出范围时报告。
小结
人工智能风格的分析将使我们更接近实时的确定问题，分析器应该能够检测硬件或软件与用户可设置阈值的差异，扫描进程数据，并确定导致事件的进程。例如，检测并扫描 I/O热点，以确定某些用户应用程序线程当时正在进行I/O活动。然后可以直接对那些执行I/O调用的线程执行操作，它应该是一个可以自动化的过程。工具包可以使用人工智能捕获软件定位事件并捕获关于事件的所有需要的数据。当我们使用这样一个高度可调的性能分析器来增加服务器的日志记录时，就将能够在正确的时间收集日志。有了这种多平台互操作性，如果拥有了一组标准化的工具，才可以快速有效地解决性能问题。