Java 运行时监控第 1 部分 Java 系统运行时性能和可用性监控

Java运行时监控，第1部分:Java系统运行时性能和可用性监控简介当今的许多Java应用程序都依赖于一组复杂的分布式依赖关系和移动部件。很多外部因素都可能对应用程序的性能和可用性造成影响。这些影响基本上都无法完全消除或解决，且难以在预生成环境中准确模拟。Stuffhappens。但是，您可以创建并维护一个全面的系统来监控应用程序的整个生态系统，从而显著降低这些事件的严重性和持续时间。本系列文章给出了实现此类系统的一些模式和技巧。模式，以及我将使用的一些术语，都表示泛指。通过结合示例代码和插图，它们将帮助您理解应用程序性能监控的概念。这种理解强调解决方案的必要性，并能帮助您选择商业或开源的解决方案。您可以扩展和定制一个解决方案，或者根据需要将其作为设计解决方案的蓝图。第1部分：探究应用程序性能管理（APM）系统的属性描述系统监控的常见反面模式列举监控JVM性能的方法提供有效插装应用程序源代码的方法第2部分将重点介绍插装Java类及资源而无需修改原始源代码的方法。第3部分将论述监控JVM外部资源的方法，包括主机及其操作系统以及数据库和消息传递系统等远程服务。它还将总结并归纳其他的APM问题，如数据管理、数据虚拟化、报告和报警。APM系统：模式和反面模式为让大家正确入门，应当强调，虽然此处介绍的多数与Java相关的内容看上去与应用程序和代码性能分析的流程类似，但其实并非如此。性能分析是一个极具价值的生产前流程，它可以确认您的Java代码是否可扩展、高效、快速和足够出色。但是，根据stuffhappens公理，当您在生产中遇到无法说明的问题时，优秀的开发阶段代码性能分析可能无用武之地。我的意思是，在生产中实现性能分析的一些方面，并从运行中的应用程序收集一些相同的实时数据及其所有外部依赖关系。该数据由一系列遍及目标的定量测量指标组成，它们为整个系统的健康状况提供细粒度和详细的表示。此外，通过保留这些指标的历史库，您可以捕获准确的基线，以帮助您确认环境仍然健康，或查明特定缺陷的根源和规模。监控反面模式完全没有监控资源的应用程序微乎其微，但仍然需要考虑这些反面模式，它们经常出现在运行环境中：盲点：某些系统依赖关系未受监控，或者监控数据不可访问。运行中的数据库可以覆盖所有监控范围，但如果受支持的网络无法全面覆盖，则诊断小组在分析数据库性能和应用服务器症状时将无法看到网络中的故障。黑盒：核心应用程序或者它的某个依赖关系对于其内部可能不具有监控透明性。JVM是一个不折不扣的黑盒。举例来说，诊断小组正在调查JVM中的莫名延时问题，并且只拥有支持操作系统的统计数据（如CPU利用率和进程需要的内存大小），则他们可能无法诊断垃圾收集或线程同步问题。脱节和断开的监控系统：应用程序可以由大型共享数据中心托管，其中，依赖关系由一系列共享资源组成，比如说数据库、存储区网络（SAN）库、消息传递及中间件服务。组织有时高度孤立，各小组只负责管理自己的监控和APM系统（请参阅孤立监控的缺陷侧栏）。没有各依赖关系的整合视图，各组件所有者只能管中窥豹，只见一斑。图1对比了孤立和整合的APM系统：图1.孤立和整合APM系统的对比孤立监控的缺陷当系统视图无法反映整体情况时，便会出现孤立监控。最为复杂和难以诊断的问题通常涉及多个参与和相关组件。请考虑一个简单的例子，托管在Java应用服务器上的应用程序（所有者未知）实现了一个有故障的JDBC连接池类（泄漏连接）。当应用程序所有者查看管理接口时，他们声称自己的服务器与数据库保持了100个连接。相反，数据库管理员（DBA）查看数据库管理控制台却能看到相同的主机实际维持了120个连接，并且其数量正在迅速增加。在经过整合的APM系统中，创建一个显示这两种指标的曲线图应该说是微不足道的。当这两个数字彼此背离时，看到该图的任何人都可以立即清楚地看到真实数字，并能准确判断出问题所在。事后报告和相关性：为尝试解决孤立监控的问题，运营支持小组可以运行定期进程获取各来源的数据，将这些数据整合到一个地方，然后再生成汇总报表。这种方法有时效率低下且不切实际，因为它需要按照指定频率严格执行，而缺乏实时数据也会对诊断小组当场发现问题的能力产生负面影响。此外，事后聚合有时缺乏足够的粒度，从而导致重要模式隐藏在数据中不被发觉。举例来说，某个报告可能显示某特定服务调用昨天平均耗时200毫秒，但却隐藏了它在下午1:00到1:45间平均耗时3500毫秒。定期或随需应变的监控：由于某些工具强制占用较高的资源开销，因此不能（或不应）经常使用它们。结果，它们很少收集数据，或者只在检测到问题后才收集数据。因此，APM系统只能执行最低基线，而无法在问题恶化前提前报警，并且可能会自己加剧势态的严重性。非持久化监控：许多工具都提供了有用的性能和可用性指标实时显示功能，但它们并不支持持久化指标供长期或短期比较和分析的功能。常见的一种情况是，如果缺少历史上下文，则性能指标将毫无价值，因为没有判断指标优劣的基准。举例来说，当前的CPU利用率是45%。如果不知道历史利用率的情况，则不好判断当前CPU利用率负荷的轻重程度。但是，如果知道历史的典型值为百分之x，可接受的用户性能上限是百分之y，则情况就大有改观了。对生产前模型的依赖：假设所有潜在问题都可在生产部署之前从环境中清除，则完全依赖生产前监控和系统模型的实践经常会导致运行时监控不够全面。这些假设无法解决不可预测事件和依赖性故障，因此，诊断小组在遇到此类事件时将没有工具和数据可用。整合APM的实现并不排除监控和诊断工具，如DBA管理工具集、低级网络分析应用程序和数据中心管理解决方案。这些工具仍然是无价的资源，但如果它们依赖于整合视图的专有性，则难以克服孤立效果的影响。理想APM系统的属性与刚才讨论的反面模式相反，本系列文章介绍的理想APM系统拥有以下属性：渗透力：它监控所有应用程序组件和依赖关系。粒度化：它可以监控层次极低的函数。整合性：收集的所有指标将被发送到支持整合视图的同一逻辑APM中。恒定：一周7天，一天24小时不间断监控。高效：性能数据收集不会对监控目标造成不利影响。实时：可以实时显示、报告和警告监控的资源指标。历史：监控的资源指标将持久化存储在一个数据库中，因此可以查看、比较和报告历史数据。在深入研究此系统的实现细节之前，了解APM系统的一些基本概念是有帮助的。APM系统概念所有APM系统都能访问性能数据源并提供数据收集和跟踪实用工具。注意，这些是我自己选择的用于描述一般类别的通用术语。它们并非特定于任何APM系统，不同APM系统可以使用其他术语表示相同的概念。在本文的其余部分中，我所使用的术语定义如下。性能数据源性能数据源（PDS）是性能或可用性数据的来源，这些数据对于反映组件的相对健康状况非常有用。例如，JavaManagementExtensions(JMX)服务通常可以提供关于JVM健康状况的丰富数据。大多数关系数据库通过SQL接口发布性能数据。这两种PDS都是直接源的例子，即可以直接提供性能数据。相反，推断源测定有意和偶然操作，并且产生性能数据。例如，测试消息可以定期发送，并随后从JavaMessageService(JMS)服务器中取回，这个往返时间将作为该服务性能的推断测量。推断源（它的实例被称作综合事务）有时极为有用，因为它们可以通过遍历与实际活动相同的路径来有效测定多个组件或分层调用。综合事务还在监控连续性方面发挥着重要作用，当直接源不能胜任时，它们可以确认系统在相对空闲期的健康状况。收集和收集器收集是从PDS获取性能或可用性数据的流程。对于直接PDS，收集器通常实现一些API来访问该数据。要从网络路由器读取统计数据，收集器可以使用简单网络管理协议（SimpleNetworkManagementProtocol，SNMP）或Telnet。对于推断PDS，收集器用于执行和测定底层操作。跟踪和跟踪程序跟踪是收集器向核心APM系统交付测量数据的流程。许多商业和开源APM系统都提供了一些用于此目的的API。对于本文中的示例，我实现了一个通用的Java跟踪程序接口，将在下节详细讨论。通常，大多数APM系统将跟踪程序提交的数据组织到某种分类的层次结构中。图2展示了该数据捕获的一般流程：图2.收集、跟踪和APM系统图2还展示了APM系统提供的常用服务：实时显示：近乎实时显示选定指标的图表。报告：生成的指标活动报告。这通常包括一系列固定报告和自定义报告，并能导出数据供用户在别处使用。历史库：包含原始或汇总指标的历史数据库，从而能够查看特定时间范围内的图表和报告。报警：将收集指标确定的具体条件通知相关个体或组的功能。典型的报警方法是电子邮件和某种类型的自定义钩子接口，可以允许运营小组将事件传播给事件处理系统。公共跟踪API在APM的目标环境中的实现和应用提供了一些一致性。此外，自定义收集器的目的是让开发人员能够专心获取性能数据，而不必担心跟踪的问题。下一节将介绍解决此问题的APM跟踪接口。ITracer：跟踪程序接口Java语言可以很好地充当收集器的实现语言，因为：广泛的平台支持。Java收集器类可以在大多数目标平台上运行，而无需修改。这使监控架构可以在本地灵活地使用PDS合并收集器进程，而不需要使用远程收集。出色的性能（但是会随可用资源而变化）。健壮的并发和同步执行支持。支持一组丰富的通信协议。受第三方API的广泛支持，比如JDBC实现、SNMP和专用Java接口，因而能支持多种收集器库。受活跃开源社区的支持，它提供了额外的工具和接口，使语言能访问或获取大量来源的数据。但是，有一点需要注意，您的Java收集器必须能够与目标APM系统提供的跟踪API相结合。如果您的APM跟踪机制未提供Java接口，则它的一些模式将仍然适用。但是，如果目标PDS只基于Java（如JMX），而应用程序平台并不基于Java，则需要一个桥接接口（如IKVM）和一个Java-to-.NET编译器（请参阅参考资料）。当缺少官方标准时，不同APM产品提供的跟踪API也全然不同。因此，我通过实现一个通用的跟踪Java接口（名称为org.runtimemonitoring.tracing.ITracer）抽象了此问题。ITracer接口是针对专用跟踪API的一个通用包装器。此技巧将确保源代码库不会因版本或API提供程序而有所不同，并且还支持实现包装API中不可用的额外功能。本文中的大多数其余示例都实现了ITracer接口和它所支持的一般底层概念。图3是org.runtimemonitoring.tracing.ITracer接口的UML类图：图3.ITracer接口和工厂类跟踪类别和名称ITracer的基本前提是向中央APM系统提交一个度量和相关的名称。此活动由trace方法实现，该方法因提交的度量而有所不同。各trace方法都接受一个String[]name参数，其中包含复合名称的上下文组件，其结构特定于APM系统。复合名称向APM系统指示提交的名称空间和实际的指标名称；因此，复合名称中通常至少包括根类别和度量说明。底层ITracer实现应该知道如何通过传递的String[]构建复合名称。表1演示了复合命名约定的两个示例：表1.示例复合名称名称结构复合名称简单斜杠分隔Hosts/SalesDatabaseServer/CPUUtilization/CPU3JMXMBeanObjectNamecom.myco.datacenter.apm:type=Hosts,service=SalesDatabaseServer,group=CPUUtilization,instance=CPU3清单1是使用此API跟踪调用的简短示例：清单1.跟踪API调用示例1.ITracersimpleTracer=TracerFactory.getInstance(sprops);2.ITracerjmxTracer=TracerFactory.getInstance(jprops);3..4..5.sim