Java 运行时监控之 1 ：Java 系统运行时性能和可用性监控

当今的许多 Java 应用程序都依赖于一组复杂的分布式依赖关系和移动部件。很多外部因素都可能对应用程序的性能和可用性造成影响。这些影响基本上都无法完全消除或解决，且难以在预生成环境中准确模拟。Stuff happens。但是，您可以创建并维护一个全面的系统来监控应用程序的整个生态系统，从而显著降低这些事件的严重性和持续时间。

本系列文章给出了实现此类系统的一些模式和技巧。模式，以及我将使用的一些术语，都表示泛指。通过结合示例代码和插图，它们将帮助您理解应用程序性能监控的概念。这种理解强调解决方案的必要性，并能帮助您选择商业或开源的解决方案。您可以扩展和定制一个解决方案，或者根据需要将其作为设计解决方案的蓝图。

第 1 部分：

• 探究应用程序性能管理（APM）系统的属性
• 描述系统监控的常见反面模式
• 列举监控 JVM 性能的方法
• 提供有效插装应用程序源代码的方法

第 2 部分将重点介绍插装 Java 类及资源而无需修改原始源代码的方法。第 3 部分将论述监控 JVM 外部资源的方法，包括主机及其操作系统以及数据库和消息传递系统等远程服务。它还将总结并归纳其他的 APM 问题，如数据管理、数据虚拟化、报告和报警。

回页首

APM 系统：模式和反面模式

为让大家正确入门，应当强调，虽然此处介绍的多数与 Java 相关的内容看上去与应用程序和代码性能分析的流程类似，但其实并非 如此。性能分析是一个极具价值的生产前流程，它可以确认您的 Java 代码是否可扩展、高效、快速和足够出色。但是，根据 stuff happens 公理，当您在生产中遇到无法说明的问题时，优秀的开发阶段代码性能分析可能无用武之地。

我的意思是，在生产中实现性能分析的一些方面，并从运行中的应用程序收集一些相同的实时数据及其所有外部依赖关系。该数据由一系列遍及目标的定量测量指标组成，它们为整个系统的健康状况提供细粒度和详细的表示。此外，通过保留这些指标的历史库，您可以捕获准确的基线，以帮助您确认环境仍然健康，或查明特定缺陷的根源和规模。

监控反面模式

完全没有监控资源的应用程序微乎其微，但仍然需要考虑这些反面模式，它们经常出现在运行环境中：

孤立监控的缺陷 当系统视图无法反映整体情况时，便会出现孤立 监控。最为复杂和难以诊断的问题通常涉及多个参与和相关组件。请考虑一个简单的例子，托管在 Java 应用服务器上的应用程序（所有者未知）实现了一个有故障的 JDBC 连接池类（泄漏连接）。 当应用程序所有者查看管理接口时，他们声称自己的服务器与数据库保持了 100 个连接。相反，数据库管理员（DBA）查看数据库管理控制台却能看到相同的主机实际维持了 120 个连接，并且其数量正在迅速增加。在经过整合的 APM 系统中，创建一个显示这两种指标的曲线图应该说是微不足道的。当这两个数字彼此背离时，看到该图的任何人都可以立即清楚地看到真实数字，并能准确判断出问题所在。

• 盲点：某些系统依赖关系未受监控，或者监控数据不可访问。运行中的数据库可以覆盖所有监控范围，但如果受支持的网络无法全面覆盖，则诊断小组在分析数据库性能和应用服务器症状时将无法看到网络中的故障。
  
  
• 黑盒：核心应用程序或者它的某个依赖关系对于其内部可能不具有监控透明性。JVM 是一个不折不扣的黑盒。举例来说，诊断小组正在调查 JVM 中的莫名延时问题，并且只拥有支持操作系统的统计数据（如 CPU 利用率和进程需要的内存大小），则他们可能无法诊断垃圾收集或线程同步问题。
  
  

• 脱节和断开的监控系统：应用程序可以由大型共享数据中心托管，其中，依赖关系由一系列共享资源组成，比如说数据库、存储区网络（SAN）库、消息传递及中间件服务。组织有时高度孤立，各小组只负责管理自己的监控和 APM 系统（请参阅 孤立监控的缺陷 侧栏）。没有各依赖关系的整合视图，各组件所有者只能管中窥豹，只见一斑。

  图 1 对比了孤立和整合的 APM 系统：

本文转自IBM Developerworks中国

      请点击此处查看全文