记一起tuxedo中间件服务阻塞故障案例
Posted IT那活儿
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了记一起tuxedo中间件服务阻塞故障案例相关的知识，希望对你有一定的参考价值。
某日某系统前端统计分析发现，当天前端调用tuxedo中间件多个服务出现调用时间增长较多，并间歇性出现“服务调用出错.”情况，问题出现时间点短暂无规律，问题持续下去会逐步拉低业务成功率，触及考核。
问题排查难点：1）问题未触发服务排队告警；2）问题出现时间点短暂无规律，不好捕获问题现场。
一、问题首次出现
情况说明：如问题背景所述，维护人员着手排查。
1、由于tuxedo中间件服务按照地市进行分区，不同地市根据路由信息，通过ESB访问对应区域tuxedo中间件，因此第一时间协调ESB协查服务调用超时记录，确认问题所在区域。
2、经ESB核查发现超时服务情况主要在集中在A区域获取有效tuxedo域信息后，我侧有针对的核查tuxedo系统ULOG日志，发现中间件确实存在对应的应用服务请求阻塞的日志报错信息。
3、排查告警发现未触发告警原因如下：
核查服务排队监控脚本发现，服务队列监控阀值为100，每4四分钟执行一次。服务排队时服务队列未达到阀值，或监控脚本执行时间未出现排队现象。
4、优化监控采集粒度以及告警阈值，待下一次异常时刻捕获现场：
调整阀值为30，每分钟采集一次；
同时针对异常服务部署了truss捕获脚本，当触发告警后第一时间执行truss捕获有效信息。
二、问题再次出现
情况说明：第二次凌晨0点10分问题再次出现，同时促发短信告警。
1、 这次我侧提前部署了脚本truss服务进程，抓取到了本次服务异常调用全过程。分析truss输出文件发现服务在 write 1 写操作中，耗时达42秒。
2、Pfiles pid可以看出write 1系服务向中间件主机本地写业务日志
3、比对正常时间段，此本地写日志操作骤耗时均在0.0001~0.0002s左右：
对比怀疑异常时间段中间件主机I/O异常，导致服务调用超时。为确保此次抓取异常非偶然现象，之后进行了第二次抓取，现象与分析结果与上述一致。
4、通知主机端核查接口tuxedo A对应主机I/O是否存在异常。
经主机核查发现主机存在一条存储链路不稳定，并对不稳定链路临时做disabled处理，避免再次影响业务。
5、最终主机侧问题处理后，续持续跟踪观察，故障得到解决。
故障相对简单，重在排查思路。针对此类间歇性、偶发性、异常时间很短的故障，首先我们需要确保监控告警能够第一时间捕获异常，如果未触发告警，需第一时间分析、调整告警策略；针对故障时间非常短的情况，需要考虑预置捕获任务，确保能够捕获现场，否则从收到告警到登上服务器，可能故障已经结束了，导致还是没有排查方向；针对tuxedo服务调用故障，要熟练使用truss、trace等相关命令，捕获服务进程对系统调用、接收的信号和进程造成的机器故障的跟踪。
以上是关于记一起tuxedo中间件服务阻塞故障案例的主要内容，如果未能解决你的问题，请参考以下文章