Java运行时监控，第3部分: 监控应用程序生态系统的性能与可用性(2) - 编程入门网
| MQ Server -->
<bean id="LocalJBossCollector"
class="org.runtimemonitoring.spring.collectors.jmx.JMXCollector"
init-method="springStart">
<property name="server" ref="LocalRMIAdaptor" />
<property name="scheduler" ref="CollectionScheduler" />
<property name="logErrors" value="true" />
<property name="tracingNameSpace" value="JMS,Local" />
<property name="objectName"
value="org.runtime.jms:name=JMSQueueMonitor,type=JMXCollector" />
<property name="frequency" value="10000" />
<property name="initialDelay" value="10" />
<property name="jmxCollections" ref="StandardJBossJMSProfile"/>
</bean>
图 18 显示了用 JMXCollector 监控的 JBossMQ 服务器的 JMS 队列的 APM 树： 图 18. JBossMQ 队列的 JMX 监控的 APM 树
Java运行时监控，第3部分: 监控应用程序生态系统的性能与可用性(2)(7)时间:2011-02-13 IBM Nicholas Whitehead用队列浏览器监控 JMS 队列 如果缺少足够用于监控 JMS 队列的管理 API 的话，可以使用 javax.jms.QueueBrowser。队列浏览器的行为与 javax.jms.QueueReceiver 的行为类似，不同的是获取的信息不会从队列中移除，而且在被浏览器检索之后仍然可以发送。队列深度通常都是一种重要的指标。据观察在很多消息传递系统中，消息生产者要多于消息消费者。这种严重的不平衡从代理队列中消息的数量可以看出来。因此，如果无法用其他的方式访问队列深度的话，那么最后一招就是使用队列浏览器了。该技巧有很多的缺点。为了计数队列中的消息数，队列浏览器一定要检索队列中的每一条信息（然后删除它们）。这样做的效率是很低的，而且要耗费比使用管理 API 多得多的收集时间 — 而且可能在 JMS 服务器的资源上开销更高。队列浏览的另一个问题是，对于繁忙的系统来说，计数在浏览完成的时候很可能就已经是错误的了。虽说如此，要是为了监控的话，近似值还是可以接受的；更何况在高负载的系统中，即便是对队列深度在给定瞬间的高精确度的度量在下一个瞬间也会是无用的了。 队列浏览有一个好处：在浏览队列的信息的过程中，可以确定最老的消息的年龄。这是一个很难获取的指标，即便是使用最好的 JMS 管理 API 也很难获取，而且在某些情况下，它可能是一个至关重要的监控点。思考一下用于传输重要信息的 JMS 队列。消息生产者和消息消费者有着明显的区别，而流量的模式是这样的：对队列深度执行一次标准的轮询通常显示一到两条信息。通常情况下，导致这个问题的原因是存在一定的延迟，而轮询的频率却是一分钟，队列中的消息不同于轮询到轮询间的消息。它们相同么？它们可能不是相同的消息，在这种情况下，上述的情况就是很正常的。但也可能是消息生产者和消息消费者同时遭遇失败，因此队列中被观察的这对消息在每个轮询中是相同的消息。在这种场景中，在监控队列深度的同时监控最老的消息的年龄就会使情况变得很清晰了：正常情况下，消息的年龄要少于几秒，但如果生产者和消费者同时失败的话，从 APM 出现明显的数据只会占用两个轮询周期间的时间。 这个功能在 Spring 收集器的 org.runtimemonitoring.spring.collectors.jmx.JMSBrowserCollector 中有所展示。它的另外两个配置属性有 javax.jms.ConnectionFactory，它与 JMSCollector 类似 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
