Java运行时监控，第2 部分: 编译后插装和性能监控

    摘要：本系列包括三部分，介绍有关 ™ 应用程序的运行时监控知识，第 1 部分 重点介绍了 JVM 的健康状况和插装源代码以捕获性能指标的方法。本篇为第二部分，介绍了在无需改变原始源代码的情况下来插装 类和构造的技巧。

    简介

    正如您在本系列（共三篇文章）的第1部分中所了解到的，监控Java 应用程序的可用性和性能及其生产中的依赖性，这对于确保问题检测和加速问题诊断和修复至关重要。需要进行监视的类的源代码级插装具有 第 1 部分 所论述过的那些优势，但是这种方法通常都不可取或者不切实际。例如，很多您所感兴趣的监控点可能位于第三方组件中，而第三方组件的源代码您是不得而知的。在第 2 部分中，我着重介绍了无需修改原始源代码而插装 Java 类和资源的方法。

    可选择的在源代码外编排插装的方法有：

• 截取
• 类包装
• 字节码插装

    本文使用了第1 部分中呈现的ITracer 接口来实现性能数据跟踪，依次举例阐明了这些技巧。

    通过截取进行 Java 插装

截取 的基本前提是通过一个截取构造和收集传入的入站与出站调用信息，对特定的调用模式进行转换。一个基本的截取程序的实现会：

1. 获取对入站调用请求的当前时间。
2. 取回出站响应的当前时间。
3. 将运行时间作为两次度量的增量计算出来。
4. 将调用的运行时间提交给应用程序性能管理（APM）系统。

图 1 展示了该流程：

图 1. 性能数据收集截取程序的基本流程

清晰的界限 变更管理的爱好者可能会对通过源代码实现变更和通过配置实现变更之间的差异持有争议。诚然，“代码”、XML 和 “脚本” 之间的界限变得有些模糊了。但是下面两个变更之间还存在明显的界限： 需要改变源代码的变更，接着还要编译、打包，有时还会涉及到一系列看起来无休止的预部署过程 对（未改变的）二进制代码外部的资源所作的变更 这两种变更之间最主要的差异是实现前滚（roll-forward）和后滚（roll-back）的简单性。在某些情况下，这种差异可能在理论上说不通，或者可能低估了某些环境的复杂度或变更过程的严格性。

    很多诸如 Java Platform 和 Enterprise Edition（Java EE）这样的 Java 框架都包括对截取栈的核心支持，服务的调用可以在截取栈中通过一系列预处理和后处理组件来进行传递。有了这些栈就可以很好地将插装注入到执行路径中，这样做的好处有二：第一，无需修改目标类的源代码；第二，只要将截取程序类插入到 JVM 的类路径中并修改组件的部署描述符，这样就把插装截取程序插入到了执行流程中。

截取的核心指标

    截取程序所收集的一个典型的指标就是运行时间。其他的指标同样适合截取模式。我将介绍支持这些指标的 ITracer 接口的两个新的方面，所以在这里我要转下话题，先简要论述一下这些指标。

使用截取程序时需要收集的典型指标有：

• 运行时间：完成一个执行的平均时钟时间。
• 每个时间间隔内的调用：调用目标的次数。
• 每个时间间隔内的响应：目标响应调用的次数。
• 每个时间间隔内的异常l：目标调用导致异常的次数。
• 并发性：并发执行目标的线程数。

    还有两个 ThreadMXBean 指标可以选择，但它们的作用有限，而且收集成本会高一些：

• 运行 CPU 时间：这是线程在执行期间消耗的 CPU 时间，以纳秒为单位。CPU 的利用情况在起初时似乎有用，但其实也就是作为一种趋势模式，其他的用处不大。或者，如果收集成本特别高的话，可以计算线程在执行时占用 CPU 资源的百分比的近似值。
  
  
• 阻塞/等待计数和时间：等待表示由具体线程调度导致的同步或者等待。阻塞常见于执行等待资源时，如响应来自远程数据库的 Java 数据库连接（Java Database Connectivity，JDBC）调用（至于这些指标的用处，请参见本文的 JDBC 插装 部分）。

[1]         

【责编:Chuan】

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