转载

对Weblogic JMS进行Debug和日志采集(4.17)

这篇文章主要是整理Oracle的官方文档 Troubleshooting WebLogic JMS

https://docs.oracle.com/cd/E13222_01/wls/docs103/jms_admin/troubleshoot.html

在我们在OSB消息集成中,采用JMS的Topic主题订阅模式,同时启用消息订阅的持久化,对于消息的Send分发则进行了WS服务适配,将其封装为WS的分发服务接口。即WS分发服务接口在接收到分发消息后,将消息直接送到JMS消息中间件中。然后对于为各个订阅方分配独立的ClientID和用户名,密码信息,只有对JMS的ProviderUrl进行了监听,则可以及时的收到JMS分发的消息信息。

可以看在,在采用该模式后,原来的同步分发服务,变成了异步两阶段的服务。第一阶段只完成消息分发到JMS,第二阶段根据订阅情况再进行消息分发。比如MDM系统分发单位信息给A,B,C,D四个订阅系统,MDM系统再将数据通过WS服务接口分发给给JMS消息中间件后即返回。而JMS消息中间件再去根据订阅情况,将消息逐一的推送到A,B,C,D四个系统。那么这个时候的问题就是如何去监控消息发送和消息接收日志的问题,包括如果去诊断在JMS消息分发中发现的问题。

实际上在Weblogic的JMS消息控制台,可以很容易看到消息的订阅和分发情况,也能够看到详细的消息报文。上面这篇文章重点还是在强调如何对JMS消息分发进行Debug,已经如何对JMS分发日志进行获取和采集。

Debugging JMS

注意对于JMS的Debug给了三种方法,具体为:

1.Enable Debugging Using the Command Line

-Dweblogic.debug.DebugJMSBackEnd=true 

-Dweblogic.log.StdoutSeverity="Debug"

2.Enable Debugging Using the WebLogic Server Administration Console

3.Enable Debugging Using the WebLogic Scripting Tool

注意第1种方法是静态方法,必须进行Server的重启。而对于第2,3两种方法则是动态方法,在JMS处于Running状态的时候也可以直接进行修改,并在修改后生效。

Message Life Cycle Logging

JMS logging is enabled by default when you create a JMS server, however, you must specifically enable it on message destinations in the JMS modules targeted to this JMS server (or on the JMS template used by destinations). 

The message life cycle is an external view of the events that a JMS message traverses through once it has been accepted by the JMS server, either through the JMS APIs or the JMS Message Management APIs . Message life cycle logging provides an administrator with easy access to information about the existence and status of JMS messages from the JMS server viewpoint. 

可以看到Oracle对于Weblogic JMS提供了消息全生命周期的Log日志记录能力。这块日志的获取可以通过JMS API接口或JMS管理API接口来完成。对于JMS消息的分发,可以记录的日志包括了消息生产,消息消费,消息移出,过期,超过重试次数,消费端建立,消费端销毁等,具体如下:

  • Produced – This event is logged when a message enters a JMS server via the WebLogic Server JMS API or the JMS Management API.
  • Consumed – This event is logged when a message leaves a JMS server via the WebLogic Server JMS API or the JMS Management API.
  • Removed – This event is logged when a message is manually deleted from a JMS server via the WebLogic Server JMS API or the JMS Management API.
  • Expired – This event is logged when a message reaches the expiration time stored on the JMS server. This event is logged only once per message even though a separate expiration event occurs for each topic subscriber who received the message.
  • Retry exceeded – This event is logged when a message has exceeded its redelivery retry limit. This event may be logged more than one time per message, as each topic subscriber has its own redelivery count.
  • Consumer created – This event is logged when a JMS consumer is created for a queue or a JMS durable subscriber is created for a topic.
  • Consumer destroyed – This event is logged when a JMS consumer is closed or a JMS durable subscriber is unsubscribed.

而这些里面最重要的就是Produced和Consumed两个消息接口的监控。

Message Log Location

USER_DOMAIN/servers/servername/logs/jmsServers/jms_server_name/jms.messages.log

Enabling JMS Message Logging

可以看到对于消息队列,消息主题,分布式消息主题等全部都可以启用消息Log日志记录。而实际上对消息日志的获取仍然可以通过JMX方式来获取,这里面涉及到JMSSystemResourceMBean and JMSRuntimeMBean MBeans两个类来管理JMS消息日志接口。在文章里面还提到,可以利用WebLogic Scripting Tool工具类配置JMS消息日志。

For more information see Overview of WebLogic Server Subsystem MBeans in Programming WebLogic Management Services with JMX

You can also use the WebLogic Scripting Tool to configure JMS message logging for a JMS servers and JMS system resources. For more information, see Using WLST to Manage JMS Servers and JMS System Module Resources.

JMS Message Log Content

对于消息日志的内容,主要包括了如下信息的日志记录。

  • Date – The date and time the message log record is generated.
  • Transaction identifier – The transaction identifier for the transaction with which the message is associated
  • WLS diagnostic context – A unique identifier for a request or unit of work flowing through the system. It is included in the JMS message log to provide a correlation between events belonging to the same request.
  • Raw millisecond value for “Date” – To aid in troubleshooting high-traffic applications, the date and time the message log record is generated is displayed in milliseconds.
  • Raw nanosecond value for “Date” – To aid in troubleshooting high-traffic applications, the date and time the message log record is generated is displayed in nanoseconds.
  • JMS message ID – The unique identifier assigned to the message.
  • JMS correlation ID – A user-defined identifier for the message, often used to correlate messages about the same subject.
  • JMS destination name – The fully-qualified name of the destination server for the message.
  • JMS message life cycle event name – The name of the message life cycle event that triggered the log entry.
  • JMS user name – The name of the user who (produced? consumed? received?) the message.
  • JMS message consumer identifier – This information is included in the log only when the message life cycle event being logged is the “Consumed” event, the “Consumer Created” event, or the “Consumer Destroyed” event. 
  • JMS message content – This field can be customized on a per destination basis. However, the message body will not be available.
  • JMS message selector – This information is included in the log only when the message life cycle event being logged is the “Consumer Created” event. The log will show the “Selector” argument from the JMS API.

这里面最重要的仍然是消息ID,消息接收发送方信息,时间,具体的消息内容等。而这些日志是我们需要采集并在JMS消息日志监控的时候使用的功能。

原文  http://blog.sina.com.cn/s/blog_493a84550102xcg1.html
正文到此结束
Loading...