不得不知道的25个中间件监控指标

一般Java中间件监控技术分为2种：JMX与ByteCode，在HP的方案中，SiteScope完全基于JMX技术，通过对MBean状态的获取来了解J2EE容器内部性能指标（Counter），可以方便整合JNDIJDBC JTS及其它技术，特别是能够使用JNDI的查询发现机制以及协议，JNDI本身提供了一种服务的查询和发现机制，并且所有的这些Services都可以通过JMX 来实现管理（在SiteScope中主要以Counter来提供）。

而HP Diagnostics，综合了JVMTI和bytecode技术，在JVM运行期间把相关的bytecode精确的注入到当前JVM所载入class字节合适的地方，不修改原class文件，从而达到监控JVM的目的。通过预配置jar文件，在被监控Class被JVM执行之前，通过JVMTI来拦截被载入的Class，分析其bytecode指令，对符合的bytecode指令附件，插入收集bytecode指令，计算时间戳并通过一些基于标签的统计，报告给DiagnosticsServer，从而诊断各种类型的性能问题，包括服务缓慢、具体方法、SQL、内存以外的错误、线程问题等等。

2者最大的差别在于是否需要做嵌入式部署，是否需要适用于诊断场景，是否要做细颗粒的采集，是否关联运算等；

但无论如何，在何种情形下，针对不同的Java容器（如Tomcat\JBoss\WebLogic\WAS等），影响其性能及可用性的因素到底有哪些？有哪些指标需要得到重点的照顾？

本文主要从以上角度列举最重要的7大类25个指标，旨在综合不同的监控方法，来实现最佳的中间件管理实践。

1.1   JVM监控

在应用程序的运行期间，可在JVM 堆的内存中分配对象并在对象空闲时进行垃圾收集。如果对象繁忙，其将在内存中徘徊且占用可重复使用的空间。由于堆中充满游离对象，因此没有足够的空间执行新的分配，这将导致更频繁的垃圾收集频率。从而导致应用程序性能下降，在极端的情况下，游离对象（Unpinned）可引起内存溢出。

 

1.1.1  堆使用

堆的使用率，需要区分堆增长为突然增长还是缓慢增长，是否出现锯齿形回收，主要用于诊断OutOfMemoryError 的堆使用。

1.1.2  垃圾收集

此监控适用于在 SunJVM 中旧有堆分区上执行的垃圾收集，通常是指主要垃圾收集。在主要垃圾收集期间，将挂起会对应用程序性能造成负面影响的活动线程。总而言之，要尽量减低垃圾收集的次数。

 

此监控可通过追踪与旧有垃圾收集器(GC) 相关的开销百分比来监控主要垃圾收集。

1.1.3  死锁线程

在多线程环境中，将会出现两个或更多应用程序线程等待相关项目的情况。例如，在如下情况下会造成线程死锁：

如果线程 1 和线程 2 均需要对象 A 和B，并且线程 1 获得对象 A 锁同时线程2 获得对象 B 锁，则随后两个线程将形成死锁。线程 1 将不会放弃其在对象 A 上的锁，并且将继续等待直到对象B 可用。同样，线程 2 将不会放弃其在对象 B 上的锁，并且将继续等待直到对象A 可用。每个线程都拥有对方用以完成其操作所需的对象。

1.1.4  内存泄露监测

此监控可用于监控特定服务器/类别组指定请求类型的历史对象数量。该监控可监控最少对象数量是否呈增长趋势，从而判断是否有可能出现内存泄漏。根据对指定数量的时间间隔和所选间隔大小的观察来判断趋势的走向,如过去时刻特定类型对象创建的数量、回收的数量、存活的数量等。

1.2   线程池监控

使用执行线程池，WebLogic可处理并发请求。如果线程池已满，则响应时间将会减少。WebLogic8.x 和更低版本可通过一个或多个与线程池相关的执行队列应用线程功能。WebLogic9.x 已使用单个自动优化线程池代替执行队列的概念，并与优先化线程请求的工作管理器实现结合。

 

1.2.1  线程池使用

监控池使用率和默认执行队列（或等同队列）以及自定义执行队列中的请求数量。

 

1.2.2  超时线程或挂起线程

多见于 WebLogic9.0 或更高版本。如果某个请求占用一个或多个线程的时间过长，则WebLogic 将报告这些线程已被占用。已被占用的线程可强制返回线程池。超时线程是一种保存时间超过配置超时设置（在HP  Diagnostics中，缺省超时时间为600 秒）的线程。

在WAS中，WebSphere 6.x 可维护已声明挂起的大量线程组。悬挂的线程均存在问题，原因是此类线程在超时及被清空之前，无法处理外来请求。因此，同样需要检查挂起线程的变化。

 

1.2.3  线程池状态

多见于 WebLogic 版本9.0 或更高版本。可通过JMX监控ThreadPoolRuntimeMBean.HealthState 来获取自动优化线程池的状态。

 

1.3   数据库连接监控

Java 应用程序通过 Java 数据库连接 (Java DatabaseConnectivity, JDBC) API 实现与数据库的交互。创建数据库连接是一项费用昂贵的操作，所以应用服务器将在启动时创建连接并存储该连接供应用程序使用。

 

1.3.1  连接池泄露

创建数据库连接的费用高昂，而不是创建其所需新连接的费用高昂，原因是WebLogic 可维护数据库连接池。如果应用程序在使用数据库连接后未将其完全关闭，则该连接不能返回池�C此种情况称为“泄露”。泄露的数据库连接将严重影响到应用程序的性能。

1.3.2  预编译语句缓存命中率

若应用程序频繁地重新使用SQL 语句，则最好使用 JDBC PreparedStatement而非 Statement，这样就无需在每次调用时由数据库或数据库驱动程序编辑该语句。可在预备语句缓存中维护PreparedStatements 和CallableStatements（用于调用存储的程序）语句。当应用程序需要执行SQL 语句时，可从缓存中恢复已编辑的版本。

 

在数据库游标固定的前提下，如果预备语句缓存过小，缓存中具有的值将全部丢失。此监控通过评估尝试恢复实例的遗漏百分比，来监控预备语句缓存的性能。

 

1.3.3  连接失败

如果数据源试图刷新其数据库连接且重新连接数据库失败，则中间件会将此报告为重新连接失败。当数据库不可用或连接至数据库的网络中断时，可能会出现连接失败。无论如何，这表示存在一个有待研究的严重问题。需要监控可用于监控数据库连接池，并观察失败的重新连接。

 

1.3.4  连接池使用

此监控通过评估池使用率和请求连接的数量来监控数据库连接池的性能。

 

1.4   交易监控

应用程序通常可在事务环境中执行具体的业务操作。Java事务，同样类似于数据库 ACID（原子性、一致性、隔离性、持久性）事务相似，其中的事务均可成功完成以及提交或失败并回滚。一般需要评估Java Transaction API  的健康状态并检查回滚的性质和出现率。

 

1.4.1  JTA状态

可以通过JMX监控 JTARuntimeMBean.HealthState 来监控 Java Transaction API (JTA) 的 WebLogic 执行状态。

1.4.2  应用回滚

应用程序回滚可能是对不适当输入的正确回应或能够表示某些失败的类型。此种回滚可能来自业务方面也有可能来自应用程序错误，需要关注监控应用程序回滚数量在事务总数中所占的百分比，常常会说明一个严重的程序错误或者不良设计。

1.4.3  超时回滚

若由于事务超出时间限制而导致失败，则其将因为超时回滚(Timeout Rollback) 而执行回滚操作。当回滚发生时，将需要增加超时时间（如适用）或确定事务耗时完成的原因，因此需要监控事务超时回滚的数量。

 

 

1.5   JMS 监控

JMS 服务器定义了两种类型的目的地：主题和队列。主题用于出版/订阅模式，而队列用于点到点通信模式。WebLogic 在 JMS 服务器上存储主题和队列消息，直到这些消息得到确认和处理。

 

默认情况下，WebLogic不对 JMS 服务器中任何时候存储的消息数量或字节量做出任何强制限制。根据通信使用用途的不同，可能会采取强制限制或业务流程会指定进行强制限制。若存在强制限制，则当服务器已满时WebLogic 将使消息在 JMS 服务器外部等待。

 

1.5.1  等待字节

默认情况下，WebLogic允许 JMS 服务器（设置字节阈值为 -1）中存在的字节数不受限制，但是如果更改该缺省值以限制服务器中的字节数，则随后将存在字节在服务器外等待处理的风险。待决字节不是服务器消息的组成部分并等待处理的字节，这些是由于限制已超出而服务器无法容纳的字节，因此需要关注此选项，检验是否存在字节阈值设置过低？

 

1.5.2  等待消息

默认情况下，WebLogic允许 JMS 服务器（设置消息阈值为 -1）中存在的消息数不受限制，但是如果更改该缺省值以限制服务器中的消息数，则随后将出现服务器外消息等待待处理的风险。若触发此监控，则应判断是消息阈值设置过低还是其为预期行为。

 

1.5.3  JMS状态

针对WebLogic,可以通过JMX监控 JMSServerRuntimeMBean.HealthState 来监控 WebLogic JMS 服务器的状态。

1.6   应用程序监控

1.6.1  部署应用的状态

此监控可用于检查应用程序实例中的所有模块是否已启动。

 

1.6.2  应用请求异常

一般指Diagnostics针对Exception的捕捉，可以设置为20-30分钟运行一次。还可核对在上一个20-30分钟周期内异常退出的百分比是否超出预定义的阈值。

 

1.6.3  应用请求超时

默认情况下，会预定义请求的超时时间，当应用请求超过该时间时，即认为超时，一般Diagnostics可以设置每20-30分钟运行一次。该监控还可核对在上一个20-30分钟周期内未完成调用的百分比是否超出预定义的阈值。

1.6.4  请求响应时间

此监控监控请求的执行时间,如完成 GET 或 POST 请求时间。然后，判断每个请求是否为昂贵请求。

 

1.7   EJB监控

1.7.1  实体Bean池命中率

WebLogic 可维护匿名实体 Bean 池。匿名实体 Bean 可用作下列用途：

 

1    执行与 Bean 创建和查询相关的操作。

 

2    当从数据库中载入 Bean 数据时对其进行存储。

 

实体 Bean 池命中率低说明应用程序服务器需要不断创建已可用的 Bean 实例，这将对性能造成负面影响。一般通过评估命中率来监控实体Bean 池的性能。

 

1.7.2  消息驱动型Bean池遗漏率

WebLogic 可维护消息驱动型 Bean池，因此当应用程序需要消息驱动型 Bean 时，它便可使用源于此池的 Bean 而无需创建新的实例。如果此池过小，则在处理消息前，该消息可能需要等待Bean 实例返回至池中。若已触发此监控，则应考虑不断增加消息驱动型池的大小。一般通过评估尝试恢复实例的遗漏百分比，来监控消息驱动型Bean 池的性能。

 

1.7.3  状态性会话Bean池遗漏率

当应用程序创建新的状态性会话Bean，而未在内存中创建对象时，应用程序服务器可恢复状态性会话Bean 池中的可用实例来存储数据。如果此池过小且无可用的实例，则应用程序服务器将创建新的实例，这将对性能造成负面影响。一般通过评估尝试恢复实例的遗漏百分比，来监控状态性会话Bean 池的性能。

 

1.7.4  无状态会话Bean池遗漏率

WebLogic 可维护无状态会话 Bean池，所以当应用程序需要无状态会话 Bean 时，它便可使用源于此池的 Bean 而无需创建新的实例。默认情况下，池的大小应以可存储适当数量的执行线程数为佳，以此避免性能问题。若调整此池的大小，则可能会出现池故障，这表示被迫等待可用Bean 实例的请求需返回至池中。若已触发此监控，则应考虑不断增加池的大小。一般通过评估尝试恢复实例的遗漏百分比，来监控无状态会话Bean 池的性能。