Java运行时监控，第1部分: Java运行时性能和可用性监控

    摘要：运行时性能监控对于实现和维护性能优异的系统至关重要。本文是系列文章的第 1 部分（共 3 部分），Nicholas Whitehead 将阐述如何有效地对 ？ 性能执行低级粒度的监控。您生成的数据可以很好的反映系统操作的内在状态，并揭示影响环境稳定性及性能的约束和因素。

    简介

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

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

    第 1 部分：

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

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

    APM 系统：模式和反面模式

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

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

监控反面模式

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

盲点：某些系统依赖关系未受监控，或者监控数据不可访问。运行中的数据库可以覆盖所有监控范围，但如果受支持的网络无法全面覆盖，则诊断小组在分析数据库性能和应用症状时将无法看到网络中的故障。

黑盒：核心应用程序或者它的某个依赖关系对于其内部可能不具有监控透明性。JVM 是一个不折不扣的黑盒。举例来说，诊断小组正在调查 JVM 中的莫名延时问题，并且只拥有支持操作系统的统计数据（如 CPU 利用率和进程需要的内存大小），则他们可能无法诊断垃圾收集或线程同步问题。

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

    孤立监控的缺陷

    当系统视图无法反映整体情况时，便会出现孤立 监控。最为复杂和难以诊断的问题通常涉及多个参与和相关组件。请考虑一个简单的例子，托管在 Java 应用上的应用程序（所有者未知）实现了一个有故障的 JDBC 连接池类（泄漏连接）。

    当应用程序所有者查看管理接口时，他们声称自己的服务器与数据库保持了 100 个连接。相反，数据库管理员（DBA）查看数据库管理控制台却能看到相同的主机实际维持了 120 个连接，并且其数量正在迅速增加。在经过整合的 APM 系统中，创建一个显示这两种指标的曲线图应该说是微不足道的。当这两个数字彼此背离时，看到该图的任何人都可以立即清楚地看到真实数字，并能准确判断出问题所在。

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

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

 

 

事后报告和相关性：为尝试解决孤立监控的问题，运营支持小组可以运行定期进程获取各来源的数据，将这些数据整合到一个地方，然后再生成汇总报表。这种方法有时效率低下且不切实际，因为它需要按照指定频率严格执行，而缺乏实时数据也会对诊断小组当场发现问题的能力产生负面影响。此外，事后聚合有时缺乏足够的粒度，从而导致重要模式隐藏在数据中不被发觉。举例来说，某个报告可能显示某特定服务调用昨天平均耗时 200 毫秒，但却隐藏了它在下午 1:00 到 1:45 间平均耗时 3500 毫秒。

定期或随需应变的监控：由于某些工具强制占用较高的资源开销，因此不能（或不应）经常使用它们。结果，它们很少收集数据，或者只在检测到问题后才收集数据。因此，APM 系统只能执行最低基线，而无法在问题恶化前提前报警，并且可能会自己加剧势态的严重性。

非持久化监控：许多工具都提供了有用的性能和可用性指标实时显示功能，但它们并不支持持久化指标供长期或短期比较和分析的功能。常见的一种情况是，如果缺少历史上下文，则性能指标将毫无价值，因为没有判断指标优劣的基准。举例来说，当前的 CPU 利用率是 45%。如果不知道历史利用率的情况，则不好判断当前 CPU 利用率负荷的轻重程度。但是，如果知道历史的典型值为百分之 x，可接受的用户性能上限是百分之 y，则情况就大有改观了。

对生产前模型的依赖：假设所有潜在问题都可在生产部署之前从环境中清除，则完全依赖生产前监控和系统模型的实践经常会导致运行时监控不够全面。这些假设无法解决不可预测事件和依赖性故障，因此，诊断小组在遇到此类事件时将没有工具和数据可用。

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

理想 APM 系统的属性

    与刚才讨论的反面模式相反，本系列文章介绍的理想 APM 系统拥有以下属性：

• 渗透力：它监控所有应用程序组件和依赖关系。
• 粒度化：它可以监控层次极低的函数。
• 整合性：收集的所有指标将被发送到支持整合视图的同一逻辑 APM 中。
• 恒定：一周 7 天，一天 24 小时不间断监控。
• 高效：性能数据收集不会对监控目标造成不利影响。
• 实时：可以实时显示、报告和警告监控的资源指标。
• 历史：监控的资源指标将持久化在一个数据库中，因此可以查看、比较和报告历史数据。

    在深入研究此系统的实现细节之前，了解 APM 系统的一些基本概念是有帮助的。

[1]           ...

【责编:Chuan】

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