Java 运行时监控第 3 部分 监控应用程序生态系统的性能与可用性

Java运行时监控，第3部分:监控应用程序生态系统的性能与可用性在本系列（共三篇文章）的第1部分和第2部分中，我介绍了监控Java应用程序的技巧和模式，在这两部分中我把重点放在了JVM和应用程序类上。在这最后一期中，我将介绍从应用程序的依赖项（诸如底层操作系统、网络或者应用程序的后端数据库）收集性能与可用性数据的技巧。在文章结尾我将论述管理收集数据的模式以及报告和可视化数据的方法。基于Spring的收集器在第2部分中，我实现了一个用于管理监控服务的基本的基于Spring的组件模型。该模型的基本原理及益处有：使用基于XML的配置，使得管理大量用于配置更复杂性能数据收集器的参数集变得更加容易。采用关注点分离的结构，这样就可以使用更简单的组件，这些组件之间的相互交互可以通过注入Spring的依赖项来实现。Spring给简单的收集bean提供了一个生命周期，该周期由初始化、启动和停止操作组成，还提供了将Java管理扩展（JavaManagementExtension，JMX）管理接口公开给bean的选项，这样就可以在运行时进行控制、监控和故障排除。下面我将在本文的每个小节中介绍有关基于Spring的收集器的更多细节。监控主机和操作系统Java应用程序总是运行于底层硬件和支持JVM的操作系统之上。一个全面的监控基础设施中最关键的组成就是从硬件和OS—通常是通过OS收集—那里收集性能、健康状况和可用性指标的能力。本节就涵盖了一些通过在第1部分中介绍的ITracer类获取这类数据并一直跟踪到应用程序性能管理系统（applicationperformancemanagement，APM）的技巧。典型的OS性能指标下面这份摘要列出了典型指标，这些指标跨域操作系统的多个部分相关。虽然数据收集的细节迥异，而且数据的解释也必须在给定的OS上下文中进行，但是这些指标在大多数标准主机上基本都是等效的：CPU使用：表示特定主机上的CPU的占用情况。单位通常为百分比的使用率，在较低的级别将CPU忙碌时间表示为消逝的时钟时间的某个特定时期的百分比。主机可以有多个CPU，而CPU又可以包含多个内核，但多个内核通常都被OS抽象出来代表一个CPU。例如，一个带有两个双核CPU的主机会被说成有四个CPU。指标通常可以按照每个CPU收集或者作为总资源利用率收集，后者表示所有处理器的总体使用情况。到底是要分别监控每一个CPU还是监控总体CPU，通常要取决于软件的本质及其内部架构。标准的多线程Java应用程序通常默认平衡所有CPU上的负载，所以监控总体较合适。但在某些情况下，个别OS进程是“特定于”特定CPU的，这时总体指标可能无法捕获到适当级别的粒度。CPU的使用通常被拆分成四个范畴：o系统：执行系统的或者OS内核级的活动耗费的处理器时间o用户：执行用户活动耗费的处理器时间oI/O等待：处于空闲状态等待完成某个I/O请求耗费的处理器时间o空闲：暗指没有进行任何处理器活动另外两个相关指标为运行队列长度（即等候CPU时间的请求的待处理事项）和上下文转换（即将处理器时间分配从一个进程转换到另一个进程的实例）。内存：最简单的内存指标为可用或使用中的物理内存的百分比。其他需要考虑的有虚拟内存、内存分配率和重新分配率以及表明内存有哪些区域被使用的更细粒度的指标。磁盘与I/O：磁盘指标为每一个逻辑或物理磁盘设备的可用或使用中的磁盘空间的简单（但是至关重要的）报告，还有这些设备的读取和写入速率。网络：指网络接口上的数据传输速率和错误发生率，它通常被分为高级的网络协议范畴，如TCP和IP。进程与进程组：可以说前面所述的指标都是特定主机的总活动。它们也可以划分为相同的指标，但是代表个别进程或相关进程组的消耗或活动。监控进程对资源的使用情况有助于解释主机上的每一个应用程序或者服务消耗的资源比例。有些应用程序只可以实例化一个进程；在其他情况下，一个诸如Apache2WebServer这样的服务可以实例化代表一个逻辑服务的一群进程。代理与无代理不同的OS有着不同的性能数据获取机制。我将呈现的收集数据的方式很多，但是在监控领域您可能经常要区别的是基于代理的和无代理的监控。也就是说在某些情况下，无需在目标主机上安装其他特定的软件也可以收集数据。但显然监控通常都会涉及到某种代理，因为监控总是需要一个接口，数据要通过它来读取。所以这里真正区别的是是使用通常出现在给定OS中的代理—诸如Linux®服务器上的SSH—还是安装其他专用于监控和使收集的数据对外部收集器可用的软件。两种方法都涉及到如下的权衡标准：代理需要安装其他的软件并可能需要应用定期的维护补丁。在带有大量主机的环境中，管理软件工作不利于使用代理。如果代理实际上是与应用程序相同的进程的一部分的话，哪怕它是一个单独的进程，代理进程的故障也将会蒙蔽监控。虽然主机本身仍在运行且健康状况良好，但是APM一定会因为无法到达代理而假定主机已停机。安装在主机上的代理可能要比无代理远程监控器的数据收集能力和事件监听能力强得多。而且，报告总体指标可能需要收集好几个原始底层指标，远程收集这些指标的效率会很低。而本地的代理则能够快速地收集数据，再合计数据，然后将合计的数据提供给远程监控器。归根结底，最佳的解决方案可能就是既实现无代理的监控又实现基于代理的监控：本地代理负责收集大多数指标，而远程监控器负责检查诸如服务器的运行情况和本地代理的状态这样的基本内容。代理也可以有不同的选项。自治代理按照自己的计划收集数据，反之，响应代理按请求递送数据。此外，有些代理只将数据提供给请求程序，而有些则直接或间接地跟踪数据一直到APM系统。接下来我将呈现监控带有Linux和UNIX®OS的主机的技巧。监控Linux和UNIX主机监控代理可以用来实现专门的本机库以从Linux和UNIXOS收集性能数据。但是Linux和大多数UNIX变体都有很多内置数据收集工具，这些工具使得数据可以通过称为/proc的虚拟文件系统进行访问。该文件看起来像是普通文件系统目录里面的普通文本文件，但其实它们是常驻内存型数据结构，是通过文本文件抽取的。由于这种数据可以很容易地通过大量标准命令行的实用工具或自定义的工具来读取和解析，所以这些文件较易于使用，而且它们的输出既可以是通用的也可以是专用的。而且它们的性能也非常好，因为本质上它们是直接来源于内存的数据。常见的用于从/proc中抽取性能数据的工具是ps、sar、iostat和vmstat（参见参考资料查阅有关这些工具的参考文献）。因此，一个有效地监控Linux和UNIX主机的方法就是执行shell命令并解析响应。类似的监控器可以用于很多种Linux和UNIX实现；虽然它们之间都有着些许差异，但是，使用一种可以完全重用收集过程的方式格式化数据是很简单的。相反，专用的本机库可能要根据每一个Linux和UNIX发行版而进行重编码或重构（但它们正在读取的/proc数据有可能相同）。而编写专用于监控某一特定情况或可以标准化返回数据的格式这样的自定义shell命令很容易，并且开销较低。现在我将展示几种调用shell命令和跟踪返回数据的方法。Shell命令的执行要在一个Linux主机上执行数据收集监控，就一定要调用一个shell。它可以是bash、csh、ksh或其他任何允许调用目标脚本或命令并可以检索输出的、受支持的shell。最通常的选择包括：本地shell：如果目标主机上运行着JVM的话，那么线程可以通过调用java.lang.Process来访问这种shell。远程Telnet或rsh：这两个服务都允许调用shell和shell命令，但由于它们的安全性相对较低，所以很少使用它们。它们在大多数现代发行版上的默认状态为禁用。安全Shell（SSH）：SSH是最为常用的远程shell。它提供了对Linuxshell的完全访问，而且被公认是安全的。在文中基于Shell的例子里，我将主要使用该机制。大多数OS都提供SSH服务，包括所有UNIX系列、Microsoft®Windows®、OS/400及z/OS。图1展示了本地shell与远程shell的基本差异：图1.本地shell与远程shell要用服务器启动一个无人值守的对话需要进行一些设置。首先必须要创建一个由私钥和公钥组成的SSH密匙对。然后将公钥置于目标服务器，私钥置于远程监控服务器——数据收集器可以在此获取该私钥。完成上述操作之后，数据收集器便能够提供私钥及其密码短语（passphrase），并能够访问目标服务器上的安全远程shell了。使用了密匙对之后，目标帐户的密码就是多余的了，根本不需要它。具体设置步骤如下：1.确保目标主机在本地的已知主机的文件中有入口。这个文件列出了已知IP地址或名称以及为每一个已知IP地址或名称验证的相关SSH公钥。在用户级别，该文件通常为用户主目录中的~/.ssh/known_hosts文件。2.用监控帐户（例如，monitoruser）连接到目标服务器。3.在主目录中创建一个名为.ssh的子目录。4.将目录改为e.ssh目录并发布ssh-keygen-tdsa命令。该命令提示密钥名和密码短语。然后会生成两个叫做monitoruser_dsa（私钥）和monitoruser._dsa.pub（公钥）的文件。5.将私钥复制到一个安全的可访问的位置，数据收集器将从这个位置运行。6.用catmonitoruser_dsa.pubauthorized_keys命令将私钥内容追加到.ssh目录中名为authorized_keys的文件中。清单1展示了我刚才所描述的过程：清单1.创建一个SSH密匙对whitehen@whitehen-desktop:~$mkdir.sshwhitehen@whitehen-desktop:~$cd.sshwhitehen@whitehen-desktop:~/.ssh$ssh-keygen-tdsaGeneratingpublic/privatedsakeypair.Enterfileinwhichtosavethekey(/home/whitehen/.ssh/id_dsa):whitehen_dsaEnterpassphrase(emptyfornopassphrase):Entersamepassphraseagain:Youridentificationhasbeensavedinwhitehen_dsa.Yourpublickeyhasbeensavedinwhitehen_dsa.pub.Thekeyfingerprintis:46:cd:d4:e4:b1:28:d0:41:f3:ea:3b:8a:74:cb:57:e5whitehen@whitehen-desktopwhitehen@whitehen-desktop:~/.ssh$catwhitehen_dsa.pubauthorized_keyswhitehen@whitehen-desktop:~/.ssh$现在数据收集器已经能够使用SSH连接到目标Linux主机，该SSH连接名为whitehen-desktop，它运行着UbuntuLinux。这个例子的数据收集器将使用一个名为org.runtimemonitoring.spring.collectors.shell.ShellCollector的通用收集器类来实现。该类的一个实例将以UbuntuDesktopRemoteShellCollector这个名称部署在一个Spring上下文中。但要完成整个过程还需要一些其他的依赖项：需要有一个调度器来每分钟调用一次收集器。该调度器由java.util.concurrent.ScheduledThreadPoolExeutor的一个实例来实现，它既可以提供一个有计划的回调机制，又可以提供一个线程池。这个调度器将以CollectionScheduler这个名称部署于Spring。SSHshell实现对服务器调用命令并返回结果。这个可以通过org.r