Java运行时监控，第3部分: 监控应用

    本文为 ™ 应用程序运行时监控 系列 的第三部分，也是最后一部分，主要介绍在监视应用程序支持和依赖服务的性能和可用性时应使用哪些策略与技巧。所谓支持和依赖服务包括底层主机操作系统、运行数据库以及通信基础设施。文章结尾针对性能数据管理问题以及数据的报告和可视化做了论述。

    在本系列（共三篇文章）的 第 1 部分 和 第 2 部分 中，我介绍了监控 应用程序的技巧和模式，在这两部分中我把重点放在了 JVM 和应用程序类上。在这最后一期中，我将介绍从应用程序的依赖项（诸如底层操作系统、网络或者应用程序的后端数据库）收集性能与可用性数据的技巧。在文章结尾我将论述管理收集数据的模式以及报告和可视化数据的方法。

    基于 Spring 的收集器

    在 第 2 部分 中，我实现了一个用于管理监控服务的基本的基于 Spring 的组件模型。该模型的基本原理及益处有：

    使用基于 XML 的配置，使得管理大量用于配置更复杂性能数据收集器的参数集变得更加容易。

    采用关注点分离 的结构，这样就可以使用更简单的组件，这些组件之间的相互交互可以通过注入 Spring 的依赖项来实现。

    Spring 给简单的收集 bean 提供了一个生命周期，该周期由初始化、启动 和停止 操作组成，还提供了将 Java 管理扩展（Java Management Extension，JMX）管理接口公开给 bean 的选项，这样就可以在运行时进行控制、监控和故障排除。

    下面我将在本文的每个小节中介绍有关基于 Spring 的收集器的更多细节。

监控主机和操作系统

    Java 应用程序总是运行于底层硬件和支持 JVM 的操作系统之上。一个全面的监控基础设施中最关键的组成就是从硬件和 OS — 通常是通过 OS 收集 — 那里收集性能、健康状况和可用性指标的能力。本节就涵盖了一些通过在 第 1 部分 中介绍的 ITracer 类获取这类数据并一直跟踪到应用程序性能管理系统（application performance management，APM）的技巧。

典型的 OS 性能指标

    下面这份摘要列出了典型指标，这些指标跨域操作系统的多个部分相关。虽然数据收集的细节迥异，而且数据的解释也必须在给定的 OS 上下文中进行，但是这些指标在大多数标准主机上基本都是等效的：

• CPU 使用：表示特定主机上的 CPU 的占用情况。单位通常为百分比的使用率，在较低的级别将 CPU 忙碌时间表示为消逝的时钟时间的某个特定时期的百分比。主机可以有多个 CPU，而 CPU 又可以包含多个内核，但多个内核通常都被 OS 抽象出来代表一个 CPU。例如，一个带有两个双核 CPU 的主机会被说成有四个 CPU。指标通常可以按照每个 CPU 收集或者作为总资源利用率收集，后者表示所有处理器的总体使用情况。到底是要分别监控每一个 CPU 还是监控总体 CPU，通常要取决于软件的本质及其内部架构。标准的多线程 Java 应用程序通常默认平衡所有 CPU 上的负载，所以监控总体较合适。但在某些情况下，个别 OS 进程是 “特定于” 特定 CPU 的，这时总体指标可能无法捕获到适当级别的粒度。

  CPU 的使用通常被拆分成四个范畴：

  • 系统：执行系统的或者 OS 内核级的活动耗费的处理器时间
  • 用户：执行用户活动耗费的处理器时间
  • I/O 等待：处于空闲状态等待完成某个 I/O 请求耗费的处理器时间
  • 空闲：暗指没有进行任何处理器活动
  另外两个相关指标为运行队列长度（即等候 CPU 时间的请求的待处理事项）和上下文转换（即将处理器时间分配从一个进程转换到另一个进程的实例）。
  
  
• 内存：最简单的内存指标为可用或使用中的物理内存的百分比。其他需要考虑的有虚拟内存、内存分配率和重新分配率以及表明内存有哪些区域被使用的更细粒度的指标。
  
  
• 磁盘与 I/O：磁盘指标为每一个逻辑或物理磁盘设备的可用或使用中的磁盘空间的简单（但是至关重要的）报告，还有这些设备的读取和写入速率。
  
  
• 网络：指网络接口上的数据传输速率和错误发生率，它通常被分为高级的网络范畴，如 TCP 和 IP。
  
  
• 进程与进程组：可以说前面所述的指标都是特定主机的总活动。它们也可以划分为相同的指标，但是代表个别进程或相关进程组的消耗或活动。监控进程对资源的使用情况有助于解释主机上的每一个应用程序或者服务消耗的资源比例。有些应用程序只可以实例化一个进程；在其他情况下，一个诸如 Apache 2 Web Server 这样的服务可以实例化代表一个逻辑服务的一群进程。

代理与无代理

    不同的 OS 有着不同的性能数据获取机制。我将呈现的收集数据的方式很多，但是在监控领域您可能经常要区别的是基于代理的 和无代理的 监控。也就是说在某些情况下，无需在目标主机上安装其他特定的软件也可以收集数据。但显然监控通常都会涉及到某种代理，因为监控总是需要一个接口，数据要通过它来读取。所以这里真正区别的是是使用通常出现在给定 OS 中的代理 — 诸如 Linux® 上的 SSH — 还是安装其他专用于监控和使收集的数据对外部收集器可用的软件。两种方法都涉及到如下的权衡标准：

• 代理需要安装其他的软件并可能需要应用定期的维护补丁。在带有大量主机的环境中，管理软件工作不利于使用代理。
  
  
• 如果代理实际上是与应用程序相同的进程的一部分的话，哪怕它是一个单独的进程，代理进程的故障也将会蒙蔽监控。虽然主机本身仍在运行且健康状况良好，但是 APM 一定会因为无法到达代理而假定主机已停机。
  
  
• 安装在主机上的代理可能要比无代理远程监控器的数据收集能力和事件监听能力强得多。而且，报告总体指标可能需要收集好几个原始底层指标，远程收集这些指标的效率会很低。而本地的代理则能够快速地收集数据，再合计数据，然后将合计的数据提供给远程监控器。

    归根结底，最佳的解决方案可能就是既实现无代理的监控又实现基于代理的监控：本地代理负责收集大多数指标，而远程监控器负责检查诸如的运行情况和本地代理的状态这样的基本内容。

    代理也可以有不同的选项。自治 代理按照自己的计划收集数据，反之，响应 代理按请求递送数据。此外，有些代理只将数据提供给请求程序，而有些则直接或间接地跟踪数据一直到 APM 系统。

    接下来我将呈现监控带有 Linux 和 UNIX® OS 的主机的技巧。

[1]           ...

【责编:Chuan】

--------------------next---------------------