IBM MQ 故障诊断（一）

说明：本文主要是针对运维人员的手册。前面部分主要是应用三板斧的方式，后面的步骤可能会发散和具体深入一些。不过也不是严格的划分，读者就当看一遍杂文的方式来看待此文吧。

一，队列管理器的启停

QMGR的启停是故障诊断中遇到最多的需求之一。

启动队列管理器: strmqm QmgrName 注：如果是启动默认的队列管理器，可以不带其名字

停止队列管理器：

endmqm QmgrName 受控停止

endmqm –i QmgrName 立即停止

指定队列管理器以立即关闭结束。在立即关闭中，队列管理器在当前正在处理的所有 MQI 调用完成后停止。命令启动后发出的任何 MQI 请求都会失败。当队列管理器下次启动时，任何未完成的工作单元都会回滚。控制权在队列管理器结束后返回。

endmqm –p QmgrName 强制停止

指定队列管理器以抢先关闭结束。在抢先关闭中，队列管理器可能会在不等待应用程序断开连接或 MQI 调用完成的情况下停止。这种行为会给您的应用程序带来不可预知的结果。因此，只有在其他endmqm 命令停止队列管理器失败后才使用这种类型的关闭。

99%的情况都不要用kill -9 <pid>的方式去停止MQ,极端情况下可以选择重启OS的方式来重启MQ.

查看队列管理器运行状态：dspmq –m QmgrName 或者直接dspmq

二，MQ检查及故障判断（发给客户的checklist）

序号	问题	备注
1	确定影响范围。 -是测试还是生产环境。 -受影响的人数，应用数，范围。	判断问题的验证程度
2	询问系统架构。 -应用是如果连接过来的，是使用什么开发的。 -队列管理器在哪个服务器上，是否使用双向通道。 -是否连接人行或者票交所等上层机构。	了解系统架构
3	症状询问。 -MQ有什么明显的错误没有？包括应用报错，MQ日志，其他地方发现的报错。 -是新上线系统吗？如果不是MQ以前正常吗？ -最近（一天，最近一周）有MQ相关的变更没有？（MQ自身，相关的应用，或者任何其他相关，例如系统，网络（包括网络设备，网络策略，断网等），硬件，上层机构） -问题发生有时间规律没有？是否可以重现？ -系统资源有什么问题没有？ -其它可用的信息有吗？或者什么可疑的信息？	了解问题概括
4	一定，一定确认好问题发生的时间。尽可能精确到秒级别，因为故障发生后可能带来联动的错误，到时候有其他现象，其他错误日志会干扰我们的故障诊断的准确性。 -第一次故障发生在什么时间点。具体到哪天，几时，几分，几秒。 -第二次发生的时间点。	时间确定
5	-查看QMGR日志错误。若队列管理器名称已知，并且处于运行状态，错误日志位于： /var/mqm/qmgrs/errors 若队列管理器不处于运行状态，则错误日志位于： /var/mqm/qmgrs/@SYSTEM/errors 若错误与系统有关，则错误日志位于： /var/mqm/log 若错误与MQ客户端程序有关，则错误日志位于客户机的根目录下： /var/mqm/log 查看FFST诊断日志文件 /var/mqm/errors -查看应用错误日志 -OS相关的日志查看，或者网络人员查看相关的网络设备错误。	日志查看
6	-存储（存储故障，磁盘空间） -系统资源检查（CPU,网络，I/O,文件权限，文件丢失，操作系统日志检查，...） -网络日志检查（防火墙，负载均衡器等）	资源层面的检查
7	故障前是否有做过什么操作：网络调整、设备调整、主机参数调整、配置文件修改，应用的变更，人为误操作的可能性等。	高风险操作
8	MQ认证相关的属性是否配置合理或者关闭MQ认证？	认证相关的配置是否合理
9	-查看MQ相关的组件是否正常工作。 -例如QMGR, 队列，监听，通道，通道序列号。 -队列深度需要查看 -通道状态需要查看 -死信队列需要查看	状态查询
10	分析日志报错例如分析QMGR里的日志报错，常见的有： -通道异常关闭。 -通道无法连接到对端。 -消息无法发送。 -认证失败。 -达到最大队列深度。 -达到通道最大通道数限制。 -消息序列号错误。AMQ9526	分析MQ错误信息
11	测试 -通过再次发生测试消息的方式验证MQ是否正常工作。 -telnet -通道PING命令(PING CHANNEL(channel_name))	验证是否正常工作
12	-是否需要先恢复在查故障？ -常规方式不能恢复，是否有workaround -是否有灾备恢复方案 -是否需要重新搭建	Workaround计划
13	-已经采取了哪些action? -排查已经采取的动作对业务系统的影响；如果动作无效，建议回退修改。	确认和判断修复动作的影响。减少对业务环境的二次伤害。
14	-重启MQ。重启队列管理器，重启OS系统等。 -重启应用。与MQ相关的客户端应用等。 -重启MQ对端-例如人行等。 -重置序列号。 -MQ连接认证，通道认证是否关闭。	建议快速恢复方案
15	建议involve应用运维或者开发人员、中间件运维人员，系统运维人员，存储运维人员，网络运维人员，上层机构（如人行，票交所等）	整体排查

三，运维人员诊断注意事项

上面的第二章节运维人员也需要仔细排查。另外对于我们专业MQ运维人员，还需要注意本章节的内容。

3.1 准确描述现象

很多时候我们第一时间都是远程的在帮助客户处理问题，或者听其他同事口述问题给我们听。这经常会有一个沟通误差，或者叫失效。第一是对方不一定真的了解问题，第二，他们也可能不会说出对自己不利的信息。所以我们一定要多问问题，多看现象，多看日志等。也就是说在确认问题本质这块一定要多花时间。

这跟医生看病非常类似，虽然很花时间，但前期的诊断和检查是非常必要的；如果一个医生光听病人口述一下就马上开处方，有很大的可能性会误诊。

3.2 常见恢复建议

-重启MQ。重启队列管理器，重启OS系统等。

-重启应用。与MQ相关的客户端应用等。

-重启MQ对端-例如人行等。

-重置序列号。

-MQ连接认证，通道认证是否关闭。

-启动灾备系统。

-新搭建一样的环境。

是否需要提CASE给原厂？底层代码及bug问题的解决办法之一。

四，FDC文件分析

从第四章开始就是具体的一些故障诊断的技术点的分析。

FDC (First Failure Data Capture) 文件自动截取发生问题时 MQ 及系统环境的快照，是诊断 MQ 问题的关键文档。文件路径一般在 /var/mqm/errors
命名格式： AMQnnnnn.mm .FDC
nnnnn : 发生问题的进程 ID 。mm: 从 0 开始。如果文件已经存在，自动加 1 ，直到文件名唯一。
FDC 内容：文件头/函数栈/追踪历史（ Trace History)/组件信息/环境变量。

可以通过ffstsummary命令来查看FDC文件，也可以直接打开查看文件前部分内容。

然后去IBM官网查询相应错误代码对应的错误原因以及解决办法。

五，查看死信队列

前提条件是队列管理器创建了死信队列。如果没有就忽略死信队列的查看。

定义一个死性队列QDEAD
DEFINE QLOCAL ('QDEAD') DEFPSIST (YES) MAXDEPTH(100) REPLACE

给队列管理器设置指定的死信队列，当消息无法到达指定的Queue中时，会被放入死信队列QDEAD。

报错：

AMQ9544：Messages not put to destination queue...and attempts were made to put them to a dead-letter queue

查看deadq的命令：

查看死信队列内容；

/opt/mqm/samp/bin/amqsbcg

amqsbcg <DLQ Name> QMgrName > /var/temp/dlqmsg.txt

示例：

查明消息放到死信队列的原因。
在消息数据部分，查看第一行： DLH 。
注意 9 12 字节数值。
十六进制： 0000 07F3.
对于 UNIX 除了 Linux on x86 Intel) 使用命令“ mqrc ”找出数值
000007F3 所代表的含义。
mqrc 0x000007f3
2035 0x000007f3 MQRC_NOT_AUTHORIZED

MQ 提供了自动处理死信队列中消息的方法，可以使用命令 runmqdlq 设置。
http://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm
.mq.adm.doc/q005540_.htm

六，qm.ini参数优化选项

qm.ini文件默认在队列管理器的路径下面创建，部分优化参数我们可以通过修改此文件来达到目的。

-----------------------------------------------------------------------------------------

#* Module Name: qm.ini *#

#* Type : IBM MQ queue manager configuration file *#

# Function : Define the configuration of a single queue manager *#

#* *#

#*******************************************************************#

#* Notes : *#

#* 1) This file defines the configuration of the queue manager *#

#* *#

#*******************************************************************#

ExitPath:

ExitsDefaultPath=/var/mqm/exits

ExitsDefaultPath64=/var/mqm/exits64

Service:

Name=AuthorizationService

EntryPoints=14

ServiceComponent:

Service=AuthorizationService

Name=MQSeries.UNIX.auth.service

Module=amqzfu

ComponentDataSize=0

Log:

LogPrimaryFiles=3

LogSecondaryFiles=2

LogFilePages=4096

LogType=CIRCULAR

LogBufferPages=0 1

LogPath=/var/mqm/log/xxxx/

XAResourceManager:

Name=DB2 Resource Manager Bank

SwitchFile=/usr/bin/db2swit

XAOpenString=MQBankDB

XACloseString=

ThreadOfControl=THREAD

Channels:

MaxChannels=2000

MaxActiveChannels=1000

MQIBindType=STANDARD

AdoptNewMCA=ALL

PipeLineLength=2

TCP:

SndBuffSize=0

RcvBuffSize=0

RcvSndBuffSize=0

RcvRcvBuffSize=0

ClntSndBuffSize=0

ClntRcvBuffSize=0

SvrSndBuffSize=0

SvrRcvBuffSize=0

TCP:

KeepAlive=Yes

SvrSndBuffSize=20000 ; Size in bytes of the TCP/IP send buffer for each; channel instance. Default is 32768.
SvrRcvBuffSize=20000 ; Size in bytes of the TCP/IP receive buffer for each ; channel instance. Default is 32768.
Connect_Timeout=10000 ; Number of seconds before an attempt to connect the ; channel instance times out. Default is zero (no timeout).

QMErrorLog:

ErrorLogSize=262144

ExcludeMessage=7234

SuppressMessage=9001,9002,9202

SuppressInterval=30

ApiExitLocal:

Name=ClientApplicationAPIchecker

Sequence=3

Function=EntryPoint

Module=/usr/Dev/ClientAppChecker

Data=<ip address>

TuningParameters:

ImplSyncOpenOutput=2

-----------------------------------------------------------------------------------------------

七，网络问题

7.1 常见的有闪断，防火墙中断连接。

7.2 如何确认是网络问题？查看MQ日志，通多PING CHANNEL命令，Telnet命令，消息发送测试等验证。同时也需要网络运维人员协助。

7.3 中断多久影响？短暂（例如5秒）的理论上不会影响，不过不排除极少数的特殊情况。长时间的中断会对消息发送造成影响。

MQ的运行基本不会有问题。从MQ的原理，以及实验测试验证如此。通过对防火墙开启，断网等测试，MQ都未受到影响。但是在极少数的生产环境中，有遇到断网之前创建的通道连接失效的问题，一般重试消息发送或者重启QMGR可以解决。

这种网络闪断的问题，一般来说最可能受影响的是MQ的通道。下面我们针对这块进行讨论：

MQ有相关参数设置：

MQ基线里我们一般都会要求配置qm.ini相关参数:

KeepAlive=Yes

#这个参数表示操作系统的TCP/IP参数设置对WebSphere MQ生效, 下面的②，③点我们会从操作系统对TCP/IP连接的机制，以及MQ自己的机制来分析。

AdoptNewMCA=ALL

MQ自身检测机制。

例如MQ通过自带的Heartbeat机制来检测通道是否仍然“活着”。心跳间隔（HBINT）用来控制发送端通道检查接收端是否处于活动状态的频率。默认值为 300。因此在MQ心跳机制下，有问题的TCP连接也会被处理。

操作系统。

例如Linux操作系统，基线的建议TCP/IP参数设置为：

net.ipv4.tcp_keepalive_time = 300

net.ipv4.tcp_keepalive_intvl = 25

net.ipv4.tcp_keepalive_probes = 4

net.ipv4.tcp_retries2=3

说明操作系统会对超过300秒的TCP连接进行探测，检查它是否处于还存活着；检查的间隔为25秒，次数为4次。因此5秒的网络闪断是不会引起操作系统去关闭TCP连接，释放资源。即使极端情况下TCP/IP的socket连接被破坏，重试机制也能将有问题的连接关闭。

Adopt MCA策略机制

AdoptNewMCA=ALL

这个参数表示，如果 IBM MQ 接收到启动通道的请求，但发现该通道的一个实例已经在运行，或者有问题，那么在某些情况下，必须先停止现有的通道实例，然后才能启动新的通道实例。AdoptNewMCA 属性允许您控制可以以这种方式结束的通道类型。ALL代表所有的通道类型。

因此这种方式也可以防止有问题的通道存在。

但是如果是长时间的网络中断，就可能会导致MQ通道出问题，一般在mq日志里会报错。例如：

详细参考链接：某运营商系统MQ消息中间件连接中断故障_ITPUB博客

遇到这类问题，这时两端的重启是一个有效的快速恢复的手段。

八，通道序列号不一致问题

这也是我们经常会遇到的问题之一。

正常情况下，无论是重新启动队列管理器还是重新启动计算机，通道序列号都不会因此而变化，因而不需要进行复位操作。但是，当在通信双方的一方机器上重新安装MQ或者删除重新建立通道，或者手动对通道的一方进行复位，尽管通道仍然可以正常启动，但是当传送数据时，通信双方会因通道序列号不匹配而出错。在通道错误日志文件(/MQ安装目录/qmgrs/队列管理器名/errors/AMQERR01.LOG)中会出现AMQ9526错误，类似如下格式：
---------------------------------------------------------
AMQ9526: 通道 'SDR.TEST' 的消息序号出错。
说明：
本地和远程队列管理器对下一个消息序号不一致。当希望消息序号 1 时，发送了序号为 6 的消息。
操作：
确定该不一致的原因。有可能同步信息已损坏, 或已被逆序恢复成先前的版本。如果问题不能解决, 可用 RESET CHANNEL 命令在通道的发送端人工复位此序号。
---------------------------------------------------------
出现这种情况时，解决办法是：
用MQSC命令RESET CHANNEL(通道名)进行复位。
例如上述例子中，既可以在通道的发送方运行命令：
RESET CHL(SDR.TEST)
也可以在通道的接收方运行命令：
RESET CHL(SDR.TEST) SEQNUM(6)

RESET CHANNEL命令说明
该命令可以用于除SVRCONN 和 CLNTCONN 外的所有通道类型。但是，如果该命令用于发送或服务器通道，则除发送或服务器通道被复位外，另一端（接收或请求器通道）也会在下一次初始化时被同时复位。如果该命令被用于接收方或请求器方，另一方不会被自动复位。
如何检查远程机器上的MQSeries通道侦听程序是否在运行，在使用MQSeries进行通讯时，通讯双方需要先启动通道侦听程序，但是，当通讯出现故障时，如何知道对方的侦听程序已经在运行成为一个问题。

总的说来，通道不一致：

1，MQ有自愈能力，但具体要话多少时间不确定；也不能保障100%成功。

2，收到重置双方通道序列号为同一数值是更快的办法。例如重置为0，或者1000.

九，MQ认证问题

CONNAUTH

使用 CONNAUTH，可以将队列管理器配置为使用提供的用户 ID 和密码来检查应用程序是否有权访问资源。

CHLAUTH

通道认证记录用于保护用于连接到队列管理器的 MQ 通道。

在银行内部的MQ（MQ7.5及以上版本）生产环境中，我们都建议禁止认证相关的功能。

要想MQ不使用认证连接，连接认证和通道认证都建议禁止。

下面是一个关闭的示例：

修改通道授权为关闭状态
ALTER QMGR CHLAUTH(DISABLED)
通过以下命令行指令解决，将连接认证选项中的SYSTEM.DEFAULT.AUTHINFO.IDPWOS的相关属性配置为OPTIONAL：
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
或者直接将连接认证选项置为空，将其完全关闭，指令如下：
ALTER QMGR CONNAUTH(' ') 注：单引号内有空格
在执行完上述两条命令中的任一条后，都需要刷新连接认证的缓存，指令如下：
REFRESH SECURITY TYPE(CONNAUTH)

添加已在队列管理器系统和特权 mqm 组到您的服务器连接通道的 MCAUSER 字段。
修改SYSTEM.AUTO.SVRCONN通道的MCAUSER值为mqm.
ALTER CHL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('mqm')

十，MQ trace
MQ trace记录程序中发生的一系列操作。支持所有队列管理器进程，及 MQ 客户端的追踪。追踪文件是二进制，需要格式化才可读。Windows 平台除外。
一般情况下不做trace诊断，除非问题反复发生无法解决的情况下。

启动、停止、格式化命令：
strmqtrc
endmqtrc
dspmqtrc
生成 IBM MQ 追踪文件
https://www.ibm.com/support/pages/generating-ibm-mq-trace-linux-and-unix