本文档的宗旨是为了帮助大家在一些常见类型的故障处理流程中，如何去快速的定位问题来提供一些帮助流程，已帮助大家去快速的定位和解决故障问题。 手册的总结来源于一些 已经发生的故障，发现在很多时候，大家不知道如何去排查；或者在排查的过程中跑偏，导致故障处理时间较长，故障恢复较慢；还有一些个人在排查问题中一些经验之谈。
万能解决方案 如果线上服务有异常，第一步，先找到依赖的服务是否有发布，如果有，第一时间先回滚发布，因为90%的故障都是因为发布引起的；如没恢复，再进行下面的排查
注意： 这个时候，最好不要立马去线上服务器查看有哪些异常，这个时候很容易被带到跑偏；为什么呢？ 因为线上的异常日志很有可能是被导致的结果，而不是发生的原因
第一步，在监控上排查是否有频繁的 gc ，重点关注full gc的监控，看是否有异常；如果有频繁的gc操作，则说明是你的应用中有大内存操作，并且还不能被回收；
通过之前的经验来看，出现这类问题，大概率是因为代码中有人上传大文件或者上传的Excel中行数特别多(实际文件大小没多大)；或者是有人在系统中导出大文件，且没有用流式处理
如果服务已经挂了，这一条就忽略吧；（否则可以通过 sudo -u tomcat /home/w/java/default/bin/jmap -dump:format=b,file=heap.hprof PID 来先dump一份内存信息，先保留下现场，用来后面做分析使用）；然后可以尝试重启服务，让服务先起来，让故障恢复。sudo /home/w/tools/bin/restart_tomcat.sh 项目名称如何确认是哪块的内存有问题呢？ . 排查数据库的监控和slow sql，看是否有大查询 . 排查dubbo consumer 的监控，看是否大量的下游调用或者慢接口 . 排查dubbo provider 的监控，看看是否有别人再搞你 . 排查mq的监控，看是否有异常的mq消息过来 . 如果发现有大量请求，可以通过查看网卡流量的监控来帮助你确认是否是因为流量波动导致的故障通过上面的排查，如果有问题，恭喜你，你已经有了一个怀疑的方向，但是别高兴的太早，因为你怀疑的方向也可能 是结果，而不是原因；继续往下排查第二步，看IO（这个时候，确认下机器的IO相关的监控，如果IO的读写 和平时没什么区别，那基本上上面的排查可以确认了，找到对应的点去改吧）
如果有大量的写操作，有可能是你的应用在 进行写大文件操作 或者 日志打印不合理，导致了大量的日志等待被刷到硬盘；进而导致你的应用被阻塞了如果有大量的读操作，这种在我们的应用中基本不会出现，一般是在文件服务器会出现；但是如果命中了第三步的情况，也是有可能的第三步，查看swap监控
如果没有发现频繁的full gc现象，且有一定的IO流量的情况下，然后swap占用较多；基本可以确认是有人在服务器执行 grep+less 或者vim 等类似的操作；第一步，查看sql异常的监控，看是否有错误的sql 第二步，查看sql执行时间和slow sql 的监控，确认是否有慢sql或者大查询 第三步，查看数据的connection并发数，确认是否有sql排队情况 第四步，查看query或者update的reject监控，确实是否数据库没有分配权限或者数据库故障
我们应用中的logback配置，最好把fd的wtraceId打印出来，方便排查问题
如果是http接口，通过 request.log 来找到 status != 0的接口，找到异常case，通过wtrace来追踪（zgrep -v “\”status\”:0” request.log）如果是dubbo接口，通过dubbo-access-provider.log 来找 FAILED 的接口，找到异常case，通过wtrace来追踪（zgrep “FAILED” dubbo-access-provider.log）快递定位慢dubbo(500ms可选)cat dubbo-access-provider.log | sed ‘s/elapsed\[//’ | sed ‘s/]//g’ | awk ‘{if( $12>500) print $3,$12 }’
查看堆栈, 定位占用CPU很高的代码行. 1.切换到 sudo -u*** -i 2.切换到目录 : cd /home/w/tools/cm/ 3.确保 : slow_stack.sh 的文件前几行的目录正确
JAVA_HOME=/home/w/java/default WEB_HOME=/home/w/www
查看该服务的占用CPU高的前10个堆栈. 4.sudo ./slow_stack.sh 项目名称 10
