JXInsight 5.7 支持基于活动的计量解决方案及针对 Java 应用的 JMX 集成

最新版的应用程序性能监测和问题诊断方案软件JXInsight，支持基于活动的计量方案以及针对Java 应用的JMX 集成。最近， JInspired 开发团队发布了 JXInsight 5.7 版本（绰号“Excel”）。

基于活动的成本核算（又称作业成本法，Activity-based costing—— ABC ）模型识别、分类企业应用中的活动，然后根据每种资源实际消耗的总量，将活动成本分摊到所有的产品和服务。JXInsight Probes（探测器）提供了基于活动的成本核算方案，根据资源消耗情况将成本分摊到应用、服务和组件。Probes 运行时组件计量应用、服务及组件的资源使用情况，以帮助 IT 服务管理部门将性能和成本两个管理领域的 KPI（关键性能指标）合二为一成单一的管理模型。

JXInsight 基于活动的成本核算解决方案包括了以下性能监测和管理特性。

• 动态分组标签：
  标签（tags）可基于执行上下文建立一个附加的成本中心层次（cost center hierarchy）。执行上下文能更好地反映出执行流的动态方面，比如：应用程序、用户、业务交易、Web 页的名字等等。打标签是软件与当前执行的应用级上下文通信的一种方法，它随后可以被 Probes 运行时的多种扩展所使用。它允许服务管理团队对客户（组织、部门或用户）对于共享资源的计量使用进行收费，同时还能从一个系统视角汇集账单。
• 客户资源计量表：
  系统管理员可以根据已有资源计量数据创建他们自己定制的计量表。这个特性允许一个管理员明确地把特定组（成本中心）的计量资源使用与有着直接或间接成本依赖的其他组（成本中心）关联起来。因此结算时可依据对相关其他各组的计量，完成特定组（成本中心）的成本分解分析。
• 计量策略：
  Probes 运行时组件允许不同的计量策略，以创建一个自适应的成本管理解决方案。这一新版本包含了 3 个新的计量策略：Busy、BusyThread 和 HighMemory。Busy 策略下，当一个线程或被管理流程在某一指定周期内 CPU 使用率一直处于高位时对活动进行计量。HighMemory 策略下，当堆内存使用率长时间处于高位时对活动进行计量。

这一新版 JXInsight 还支持 JMX 集成，包括新的探测器管理提供者扩展 management Bean（GroupMBean 和 MeteringMBean），它们被注册于一个本地 MBeanServer 中，用于每个计量探测器组和所创建的关联资源计量。对 JMX 的支持还包括与 Oracle Coherence 集成，这是通过一个新的与 Oracle Coherence 管理集成扩展探测器相关的 MBeans 实现的。这个被管理 bean 被注册到 Oracle Coherence grid-wide 管理和监测（JMX）框架，使其能够从每个网格结点监测每个测量或组。

该最新版还包括了以下新特性：

• 支持 Java 6：
  JXInsight 现在提供了对 Java 6 运行时的支持，它使用了一个新的 JVMTI 代理替代了 Java SE 5 运行时环境上的 JVMPI 代理。 Java 1.4 运行时在这一版中目前仍被支持，尽管这是最后一个支持 1.4 的版本。
• Java 日志记录集成：
  新的日志探测器提供者扩展可以被激活并配置以发布一个 LogRecord ，用于读取超过特定阀值（每个计量表的每个日志等级都做定义）的每个资源计量表读数。这在集成已有遗留系统监测工具时很有用处，这些工具提供了对日志文件的连续扫描功能以产生警告并监测事故。
• Azul 系统资源计量表
  提供对 Azul 系统计算用具的支持，通过一个特定的探测器仪表集成扩展包。这一集成在计算用具内部进行本地资源计量，不像其它概要方案，还需要与 Azul 客户端 / 代理 JVM 进行网络通信。
• JRuby-to-Ruby 探测器扩展：
  JXInsight 5.7 提供了跨 JVM 语言资源计量和计费方案的 JRuby 扩展。计量数据可以跨 Java 和 Ruby 执行边界被汇集并追踪，这是通过新的 JRuby-to-Ruby 探测器扩展实现的。

最新版的 JXInsight 还提供了一个可以移植到其它语言、运行时环境、以及平台上的 API。对应用来说，其面向方面运行时的内存需求量已经降低了，而且对于探测器计量快照，内存需求量和文件存储尺寸也降低了。

对于 JXInsight 5.7 还有第二个更新，其已于上周早些时候发布了。这一更新引入了两个新的探测器提供者：不可重入（non-reentrant）和并发（concurrent）。nonreentrant 探测器提供者滤除了指定探测器的递归执行（调用）。并发探测器可以帮助识别一个可能存在瓶颈的请求处理管道中的执行点。

JXInsight 是 JInspired 可扩展软件性能工程（ XPE ）的一部分，它是跨应用生命周期提供资源计量运行环境的一个解决方案。XPE 为软件性能管理引入了一个方法以及一个服务交付框架，该框架可以指导将人及产品结合并集成到软件性能工程流程中去。

InfoQ 就项目当前特性和未来计划采访了 JXInsight 的产品架构师 William Louth。对于新的“基于活动的成本核算”特性背后的主要推动因素是什么， William Louth 这样回答：

当我设计这个探测器运行时的时候，我下决心要支持无限数量的资源计量表——不仅限于时钟时间（clock time）或 CPU 时间，这是大多数应用性能管理或概要工具的标准方法。设计中的这一灵活性使得软件执行可以按照业务管理软件的方式被计量，这是通过对一个或多个未知的基于活动（线程 + 上下文）的计数器的度量（KPI）来进行的。需要注意的是，我们报告的是细粒度的关键性能指标——执行的上下文。系统级的报告只能满足健康监测和一些程度的能力计划，尤其在大多是软件没有经过充分的性能测试或系统活动分析的时候。

随着云计算的到来，我们很快意识到这种对资源使用的计量还有另外一个重要的管理角度——成本核算。我们已经对每个被监测的软件活动的资源使用情况进行了跟踪，我们需要的是引入成本模型的方法，从服务管理角度和成本管理角度来进行应用监测。必要的支持已经有了——资源计量表是基于成本的，而且派生自一个或多个运行时激活的基础资源计量表。随后，我们引入了对多成本计量表的支持，允许客户监测云计算成本，同时让一个或多个附加的成本核算模型来管控模式或操作的成本管理。

在一个基于 SLA 的服务监测和管理工作方面，ABC 如何对 SOA 架构师及开发者提供帮助？

随着对许多大公司的云计算和绿色计算项目了解的逐步深入、兴趣日益浓厚，许多面向服务架构被要求提供适当的机制去追溯软件活动资源消费。服务组成的软件执行计算“活动”消耗了资源——因此控制“活动”就可以从源头控制成本。 IT 之外采纳 ABC 的一个最大障碍是，判断哪些活动正在被执行以及如何消耗资源是很花费时间的。对于基于 SOA 的应用和服务，这种分类已经被搜集出来了——所有要做的就是能够通过资源使用、根据由服务自身执行的众多活动之一来动态地分配成本。

在新特性及功能增强方面，JXInsight 项目未来的计划是什么？

我们计划在未来几个月里发布两个主版本。第一个版本计划于 2009 年第一季度发布，将解决系统监测模型和软件监测模型分离的问题，这些问题是在当前的应用管理和监测产品里发现的。为达到在系统监测与软件监测之间无缝切换这一目标，我们将要发布一个新的开放 API——Metrics，将支持 metrics 动态注册，与如系统时间计数器这样的底层计量绑定。我们现在的产品中已经提供了一些方面的内容，但是其主要是静态的而且是基于配置的，尽管我们已经针对大多数流行平台都作了映射。在这一主版本中，大多数 metrics 运行时都将动态化，并且能够从非 Java 系统（即 Oracle 数据库）通过一个 proxy 代理提供 metrics。

我们的第二个版本计划在 2009 年第二季度发布，它将引入一个革命性的新方法，通过动态的和可扩展的可视化符号语言来进行仪表盘设计。该符号语言将被用来展现和整理系统及软件状态，以及展现和整理用于未来自动问题侦测的行为模式。

查看英文原文： JXInsight 5.7 Supports Activity Based Metering Solution and JMX Integration for Java Applications