故障排查:别想甩锅给运维

前言介绍

我们的环境是用典型的nginx+java+mysql架构打造的一套后台管理系统,提供给内部员工使用;

故障描述

早上到公司,接收到反馈;说员工在昨晚12点使用后台管理系统提交数据时无法提交,且今早通过浏览器登录后台管理系统也无法登录;

先不管员工当时的具体情况,作为一个运维,先看自己服务器的状态; 同时,领导指明查看mysql数据库的状态是否正常(怀疑是数据库的问题)

排查过程

排查数据库

一顿操作,发现mysql没有异常;

故障排查:别想甩锅给运维_第1张图片

排查服务器

服务器安装了tsar,用于记录系统的状态参数; 这里通过tsar查看了load、cpu、mem、io、tcp、traffic(流量)

发现问题: 服务器从30日的15点00左右开始,一直到31日早8点,负载比平时高出很多;

cpu和load的参数截图:

故障排查:别想甩锅给运维_第2张图片

tcp和traffic(流量)的参数截图:
故障排查:别想甩锅给运维_第3张图片

mem和io的参数截图,因为没有异常波动,就不放截图了;

以上这种高负载装填一直持续到31日的早8点00左右;

推理结论

虽然没有找到后台管理系统无法登录的原因,但是排查到这种有着明显时间点的异常现象,收获还是比较大的;
现象总结:(重点)
1、服务器出现大量等待被执行的任务(在runq列可以看到,平时排队的任务数很少,后来剧增,说明出现线程阻塞,任务执行不下去,或者处理缓慢;)
2、user用户侧cpu相对之前使用率增大,但并没有达到100%的状态(验证了上一条,cpu处理任务繁忙)
3、load负载上升(内存变化不大,磁盘io正常;处理缓慢的原因并不是io和mem造成的,瓶颈不在于硬件,综合上一条,cpu遇到了计算密集型任务;)
4、tcp:主动连接和被动连接速率变化不大,但收到和发出的tcp报文数目减半;(处理数据包的能力减弱)

通过上述现象判断,问题可能出现在运行的程序上(java),因为种种迹象表明,瓶颈不在于系统,可能是在程序处理上,出现了问题,导致处理缓慢、卡顿、队列增加等;

tsar重点参数含义:

load-runq:在采样时刻,运行队列的任务的数目
cpu-user:用户侧cpu使用率(代表用户侧程序)
tcp-actice/pasive:主动打开的tcp连接数目/被动打开的tcp连接数目
tcp-iseg/outseg: 收到的tcp报文数目/发出的tcp报文数目
traffic-bytin: 入口流量byte/s
traffic-bytout: 出口流量byte/s
traffic-pktin: 入口pkt/s
traffic-pktout: 出口pkt/s

结果确认

由于问题时间点非常明显,5.30日15点到5.31日的早8点,所以围绕这个时间点进行排查即可; 果然,在告警群里(我们有自己的告警群,监控java程序日志的异常),这两个时间点是jar包发布变动的时间点,之后和开发确认后,开发进行了排查并解决,好了,作为一个运维,锅已经甩出去了。

故障排查:别想甩锅给运维_第4张图片

事实证明,由于开发人员更新java程序后,程序执行了大的任务,导致程序卡顿)

你可能感兴趣的:(运维,java,数据库)