Java IBM Websphere MQ监控

Java IBM Websphere MQ监控,java,performance,websphere,monitoring,ibm-mq,Java,Performance,Websphere,Monitoring,Ibm Mq,我一直在尝试从IBM WebSphere MQ中获取一些性能统计数据,以便使用Spring Source的Hyperic HQ进行监控 我关注一些本地队列的消息入队和出队率以及队列深度,以确保消息被传递到本地应用程序并被本地应用程序使用 最初尝试使用WMI和windows性能计数器检索数据,但在我们的一台服务器上,计数器似乎不适用于任何本地队列(只是临时队列负载),而在另一台服务器上,计数器可用,但并不总是通过WMI正确返回值 我尝试了PCF(使用MQIA\u MSG\u DEQ\u COUNT

我一直在尝试从IBM WebSphere MQ中获取一些性能统计数据,以便使用Spring Source的Hyperic HQ进行监控

我关注一些本地队列的消息入队和出队率以及队列深度,以确保消息被传递到本地应用程序并被本地应用程序使用

最初尝试使用WMI和windows性能计数器检索数据,但在我们的一台服务器上,计数器似乎不适用于任何本地队列(只是临时队列负载),而在另一台服务器上,计数器可用,但并不总是通过WMI正确返回值

我尝试了PCF(使用
MQIA\u MSG\u DEQ\u COUNT
),它不会提供请求的计数器。MQSC(使用
DISPLAY QUEUE
&
DISPLAY QSTATUS
)似乎不支持排队率-仅提供最后一条消息的获取/放置日期和时间


任何人都知道如何使WMI和性能计数器正常工作,或者使用WMI的替代方案来提供我需要的统计信息吗?

关于
MQIA\u MSG\u DEQ\u COUNT
,您应该知道返回此属性的
RESET\u QUEUE\u statistics
命令就是我喜欢称之为WMQ的量子物理性质“因为观察值的行为会重置值。如果您是唯一查询该值的人,并且只有一个查询线程,那么这是很好的。但是如果您同时进行多个查询,则每次查询时都会将计数器重置为零,每个查询都会踩到另一个查询的数字。这方面使得
RESET\u QUEUE\u STATISTICS
对实时调试的使用有限,不适合可靠的统计数据收集

另一种方法是使用MQ的记帐和统计功能。为了让QMgr生成记帐和统计信息,必须在QMgr或在每个队列的基础上启用它们。有关如何启用它们的说明,请参见手册部分

请注意,统计信息会报告给事件队列,并且必须获取和解析。有关解析事件消息的文档参考在小节中。有一个名为的源代码格式的示例程序,显示了如何获取和格式化统计信息。还提供了编译版本,以提供此类消息的可读列表

一旦您在感兴趣的队列上启用了统计信息并有了解析消息的方法,只需将解析器指向适当的事件队列并收集统计信息。显示可用统计信息的amqsmon输出示例如下:

   RecordType: QueueStatistics
   QueueManager: 'saturn.queue.manager'
   IntervalStartDate: '2005-04-30'
   IntervalStartTime: '15.09.02'
   IntervalEndDate: '2005-04-30'
   IntervalEndTime: '15.39.02'
   CommandLevel: 600
   ObjectCount: 3
   QueueStatistics:
     QueueName: 'LOCALQ'
     CreateDate: '2005-03-08'
     CreateTime: '17.07.02'
     QueueType: Predefined
     QueueDefinitionType: Local
     QMinDepth: 0
     QMaxDepth: 18
     AverageQueueTime: [29827281, 0]
     PutCount: [26, 0]
     PutFailCount: 0
     Put1Count: [0, 0]
     Put1FailCount: 0
     PutBytes: [88, 0]
     GetCount: [18, 0]
     GetBytes: [52, 0]
     GetFailCount: 0
     BrowseCount: [0, 0]
     BrowseBytes: [0, 0]
     BrowseFailCount: 1
     NonQueuedMsgCount: 0
     ExpiredMsgCount: 0
     PurgedMsgCount: 0

手册中题为“足够适当”的部分提供了这一示例和其他示例。

谢谢rob,这是我考虑过的备选方案之一。我最终使用了一个支持包(MS0B),它为Java提供了一组PCF类,我已经将这些类集成到hyperic插件中。然后,在为所需队列启用队列监控后,im请求最后一条消息,以便有时间检查消息是否正在传递并从队列中拉出,而这正是im目前真正感兴趣的。我不确定启用队列统计可能会导致何种性能开销。感谢您提供重置队列统计信息+呵呵“WMQ的量子物理属性”。PhilMessage Expiration是消息传递的“Schroedinger's Cat”属性—在获取它之前,它可以存在于两种状态中。