应用性能管理-从操作系统做起

引自《网络世界》

      我们知道，IT人员其实非常痛恨升级到新的服务器或更换到新的软件体系架构之上，因为这会面临很多风险，同时也需要花费大量的时间和精力。APM能够精确地衡量系统运行环境，通过这些工具提供深层次的信息并应用分析技术，帮助企业节省需要更换系统的大量成本。

      随着应用的不断增多，用户需要建设具有应用感知的基础设施，IT人员承担不起使用重复的工具来处理应用性能的费用。APM必须成为基础设施的组成部分，它不能是一种事后的补救措施，或利用安装在基础设施上面的分离的产品来解决，从最基础的操作系统做起，是成功之路。

      应用性能管理（APM）能够为用户提供一种极有价值的预算规划或故障解决手段，但要想获得成功，用户必须从自己的操作系统开始着手。

      APM在某种程度上很像体育锻炼：每个人都知道自己需要它，但很少有人能够坚持下来，因为总是会有人因为高昂的成本和冗长的开发周期而打退堂鼓。

      今天，人人都讲求事半功倍，但是，只有我们能够在更近的距离上仔细观察APM，我们才会获得丰硕的回报。APM解决方案都由计数器支持（包括现有的计数器和客户定制的计数器）。APM可对各项参数进行监视，包括CPU占用率、内存消耗量以及网络吞吐量等。其中多数还包括一些类型的分析组件，用来解释计数器数据、重点标示和记录差异日志，以及触发报警等。分析后的APM数据才能被用来管理容量、解决故障问题、确保性能水平，甚至可以计划未来的增长等内容。

      今天的IT人员能够掌握丰富的各种工具和资源，并了解系统底层的运行情况究竟如何。在本文中，我们将探讨APM技术的现状，以及与其相关的三种主要操作系统平台：Microsoft Windows Server、Sun Solaris和Linux。每种操作系统在跟踪应用运行状态时所采用的方法和手段均有所不同，因此用户必须对各自的APM战略进行调整，从而适用选定的操作系统平台。

 

计数器无所不在

      任何APM解决方案的核心都是计数器。这些计数器都在系统最核心的部位工作，在运行环境内部最隐蔽的角落中监视着各种关键数据。无论是编入操作系统的核心还是位于虚拟机的类库中，计数器都可以实现对整个系统范围内的应用性能管理。

      计数器还可以让人们了解操作系统开发人员的许多思维方式。例如，Solaris操作系统提供了丰富的计数器功能，让用户能够探索Sun自有硬件的内部工作情况，而Windows也通过一个中心库（性能数据帮助，PDH DLL）提供了大量系统及应用计数器，即使是一般的编程人员也能对这些内容进行访问。

      目前，越来越多的APM开始采用基于浏览器的应用构架，这也为APM提供了一个新的层次：Web应用服务器。Web应用服务器强调的是代码的可移植性和平台的抽象性（通过上面提到过的虚拟机模型），因此Web应用服务器要求其自己的仪器设施尽可能不与主机操作系统相互依赖，因而使得APM变得更为复杂。

      随着复杂性的螺旋式上升和IT业界在管理并行APM架构时面临更大的挑战，各厂商都在努力寻求新的解决途径，使自己的解决方案能够将这些离散的资源整合在一起，而且不需要强迫客户寻求第三方的帮助。这种思路也正在迅速成为一个非常关键的APM卖点。

      那么，用户又如何衡量选用的APM解决方案呢？以下是应当考虑的三个要点：部署成本（时间和精力，当然还有金钱）、易用性以及APM功能。而且这三项因素必须放在一起，并与操作系统平台相互参照，才有可能形成最佳的解决方案。

 

Microsoft Windows Server系统：单一捆绑、垂直集成

      长期以来，将诸多功能捆绑在操作系统中已经成为微软产品的一项传统。APM当然也不例外。Windows Server平台本身具备非常丰富的计量计数功能。从NT Executive 的内核到最隐蔽的运行子系统（例如"缓存读取命中率"），每项组件和内容都有一个计数器。

      比计数器数量更为重要的是，微软允许其他开发人员使用这些功能。在.Net 框架之前的那些传统Windows应用中，微软提供了PDH库。这是一个单点式参考库，能够访问整个操作系统的计量计数器。事实上，几乎所有主要的子系统都有各自的表达项目，而且Windows开发人员可以非常轻松地扩展其自己的应用，并利用PDH接口来获得定制的计量内容。

      PDH也被图形化的PerfMon （性能监视器）应用使用，这一监视器应用是Windows操作系统核心的一部分，能够以图表和日志方式记录数据。

      随着.Net框架的出现，微软扩展了其无处不在的计量模型，将其引入了Web应用服务器的领域中。所有的框架操作，从CLR (通用语言运行环境) 虚拟机的JIT (Just in Time) 编译器到ASP .Net Web服务库，所有的组件都具备完整的计量仪表系统，并可供开发人员使用，其实现的途径既有传统的PDH库，又有更新的WMI (Windows管理工具)接口。

      此外，当微软的ETW (用于Windows的时间追踪) 解决方案于今年正式推出时，将能够追踪应用的执行路径，并了解其跨越本地和网络边界（但不包括Web服务边界）的情况，而且这种跟踪根本不用考虑其下层的开发模型究竟是什么。

      这种双向式的APM支持实现传统操作系统与当前新一代Web应用服务器资源之间的紧密集成，从而帮助微软赢得开发人员社团的支持与拥护。

 

Linux：多方努力、水平集成

      如果Windows Server系统代表的是单一厂商APM集成，那么Linux利用其特有的交换和分布式开发方式，代表的就是完全相反的一极：由DIY精神支撑起来的，但有时也有些混乱的虚拟背景。

      可以肯定的是，如果您真的需要虚拟APM解决方案，则肯定能够找到ISM的PerfMan for Linux 和IBM的Tivoli解决方案。但是，即使是这些大厂商的工具是在那些基本应用程序的基础上构建起来的，同样也融合了Linux社团的共同努力。

      例如，PerfMan是一种功能强大的商用计量跟踪和分析解决方案，利用sysstat编写而成。后者是一种用于Linux/proc虚拟文件系统的开放源代码命令行前端。同时，IBM的Linux性能计划在很大程度上是从OProfile演化而来的，这是一种开放源代码内核驱动/探测应用。

      与应用服务器和数据库类别（两者都是由一线厂商利用传统方式开发出来的，而且支持良好，价格高昂）不同的是，APM有很多都是由开放源代码社团开发出来的。如果只需要让Linux为自己的目的服务，那么它将是一个极好的选择，因为上面提到过的所有开放源代码工具都属于GNU的范畴。但如果需要的是在多层运行环境中的连贯性，那么Linux的吸引力就要大打折扣。

      大规模的Linux项目中，多数都要用到一种或多种第三方的Web应用服务器平台。因此，尽管厂商可以为其各自的环境提供丰富的APM工具，但这些工具仍然对操作系统底层的情况了解得少之又少。同样，操作系统一级的APM工具，如sysstat，又对Web应用服务器一层的情况知道得很少，因为它只知道那是一种可以使用/proc虚拟文件系统进行跟踪的进程。

 

Sun Solaris：中间路线的代表

      在一方面，Sun既是开放源代码的支持者：Java关键技术的拥有者、异构Web标准的倡导者和Linux的拥护者。在另一方面，Sun是典型的老牌大厂商：提供众多强大的功能，但其关键部分又是与专有的硬件平台密不可分的。

      例如，Sun在其操作系统平台中推出了功能强大的全新APM解决方案--Sun Solaris 9 Resource Manager。Resource Manager是任何IT规划者的梦想；它可以针对应用资源使用情况提供详细的反馈，允许系统管理员出于系统健康分析的目的审查运行时行为。在与Sun开发环境协同使用时，Resource Manager可以提供连贯的端对端APM解决方案集，适合Solaris和J2EE应用类型。

      但是，仍然有一个问题。两种产品最初时只能在Sun的Sparc处理器平台上使用，这意味着您不得不在公司的软件和硬件这两个方面投资，也只有这样才能发挥出APM的完整优势。不过好在从Solaris 9之后的版本中，Resource Manager跟着Solaris被移植到了x86平台上使用。

      同时，在评估Sun的APM策略时还需要考虑到那些不可见的专有系统关联。对于Sun来说，它既要努力使自己适应开放源代码领导者的角色，又要保持高利润大型硬件的优势，这对它来说无异于一项重大的挑战。

构建一套APM策略

      APM连贯性最强的平台也会在经济上具有极大的实际意义。微软在这方面无疑有优势，这要在很大程度上归功于微软在操作系统中捆绑额外功能的特殊偏好。

      但是基本的操作系统功能只是APM天平上的一部分。在许多情况下，用户已经拥有的平台情况比较复杂。例如许多用户都拥有大量的传统Unix计算机，而微软的以Windows为中心的模型就不会有多大的作为。所以，单一厂商解决方案在这种情况下竞争力自然就不会很强。

      当然，我们这次探讨的APM还主要是局限于单一操作系统这个层次，而更高层应用以及异构环境的用户占据大部分市场，这就需要大量的第三方APM工具以弥补这些不足。