简介：
　　当今的许多 Java 应用程序都依赖于一组复杂的分布式依赖关系和移动部件。很多外部因素都可能对应用程序的性能和可用性造成影响。这些影响基本上都无法完全消除或解决，且难以在预生成环境中准确模拟。Stuff happens。但是，您可以创建并维护一个全面的系统来监控应用程序的整个生态系统，从而显著降低这些事件的严重性和持续时间。
　　本系列文章给出了实现此类系统的一些模式和技巧。模式，以及我将使用的一些术语，都表示泛指。通过结合示例代码和插图，它们将帮助您理解应用程序性能监控的概念。这种理解强调解决方案的必要性，并能帮助您选择商业或开源的解决方案。您可以扩展和定制一个解决方案，或者根据需要将其作为设计解决方案的蓝图。

　　第 1 部分：

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

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

　　APM系统：模式和反面模式

• 盲点：某些系统依赖关系未受监控，或者监控数据不可访问。运行中的数据库可以覆盖所有监控范围，但如果受支持的网络无法全面覆盖，则诊断小组在分析数据库性能和应用服务器症状时将无法看到网络中的故障。
• 黑盒：核心应用程序或者它的某个依赖关系对于其内部可能不具有监控透明性。JVM 是一个不折不扣的黑盒。举例来说，诊断小组正在调查 JVM 中的莫名延时问题，并且只拥有支持操作系统的统计数据（如 CPU 利用率和进程需要的内存大小），则他们可能无法诊断垃圾收集或线程同步问题。
• 脱节和断开的监控系统：应用程序可以由大型共享数据中心托管，其中，依赖关系由一系列共享资源组成，比如说数据库、存储区网络（SAN）库、消息传递及中间件服务。组织有时高度孤立，各小组只负责管理自己的监控和 APM 系统没有各依赖关系的整合视图，各组件所有者只能管中窥豹，只见一斑。

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

• 事后报告和相关性：为尝试解决孤立监控的问题，运营支持小组可以运行定期进程获取各来源的数据，将这些数据整合到一个地方，然后再生成汇总报表。这种方法有时效率低下且不切实际，因为它需要按照指定频率严格执行，而缺乏实时数据也会对诊断小组当场发现问题的能力产生负面影响。此外，事后聚合有时缺乏足够的粒度，从而导致重要模式隐藏在数据中不被发觉。举例来说，某个报告可能显示某特定服务调用昨天平均耗时 200 毫秒，但却隐藏了它在下午 1:00 到 1:45 间平均耗时 3500 毫秒。
• 定期或随需应变的监控：由于某些工具强制占用较高的资源开销，因此不能（或不应）经常使用它们。结果，它们很少收集数据，或者只在检测到问题后才收集数据。因此，APM 系统只能执行最低基线，而无法在问题恶化前提前报警，并且可能会自己加剧势态的严重性。
• 非持久化监控：许多工具都提供了有用的性能和可用性指标实时显示功能，但它们并不支持持久化指标供长期或短期比较和分析的功能。常见的一种情况是，如果缺少历史上下文，则性能指标将毫无价值，因为没有判断指标优劣的基准。举例来说，当前的 CPU 利用率是 45%。如果不知道历史利用率的情况，则不好判断当前 CPU 利用率负荷的轻重程度。但是，如果知道历史的典型值为百分之x，可接受的用户性能上限是百分之y，则情况就大有改观了。
• 对生产前模型的依赖：假设所有潜在问题都可在生产部署之前从环境中清除，则完全依赖生产前监控和系统模型的实践经常会导致运行时监控不够全面。这些假设无法解决不可预测事件和依赖性故障，因此，诊断小组在遇到此类事件时将没有工具和数据可用。

　　整合 APM 的实现并不排除监控和诊断工具，如 DBA 管理工具集、低级网络分析应用程序和数据中心管理解决方案。这些工具仍然是无价的资源，但如果它们依赖于整合视图的专有性，则难以克服孤立效果的影响。