IBM MQ 故障诊断(一)

Source

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

一,队列管理器的启停

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命令

验证是否正常工作
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问题的解决办法之一。