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

前言介绍

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

故障描述

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

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

排查过程

排查数据库

一顿操作，发现mysql没有异常；

排查服务器

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

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

cpu和load的参数截图：

tcp和traffic（流量）的参数截图：

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包发布变动的时间点，之后和开发确认后，开发进行了排查并解决，好了，作为一个运维，锅已经甩出去了。

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