线上问题定位分析解决

·  阅读 1669

定位问题的先决条件

需要有详细的日志记录,提前告警的监控平台,事发现场保留

日志 :业务日志,中间件日志
监控 :CPU、内存、磁盘、网络,类加载、GC、线程等
快照 :-XX:+HeapDumpOnOutOfMemoryError 和 -XX:HeapDumpPath

分析问题,解决问题的思路

经验+直觉,快速定位 > 逐一排查,传输链路 > 寻找规律 不要轻易怀疑监控。考虑资源。优先保证系统能正常运行。保留现场,事后排查定位问题。

逐一排查,传输链路,通过日志或工具逐一排查

  1. 内部原因,是否是客户端或者前端问题,程序发布后的Bug,回滚后可以立即解决
  2. 外部原因,比如服务,第三方服务,主机、组件的问题。
    1. 服务:错误日志邮件提醒或elk快速定位问题,查看gc日志
    2. 第三方服务:单独调用测试,联系第三方加急解决
    3. 主机: CPU相关问题,可以使用 top、vmstat、pidstat、ps 等工具排查; 内存相关问题,可以使用 free、top、ps、vmstat、cachestat、sar 等工具排查;IO 相关问题,可以使用 lsof、iostat、pidstat、sar、iotop、df、du 等工具排查;网络相关问题,可以使用 ifconfig、ip、nslookup、dig、ping、tcpdump、iptables等工具排查。
    4. 组件:查看日志输出,使用命令查看运行情况
  3. 因为系统资源不够造成系统假死的问题,通常需要先通过重启和扩容解决问题,之后再进行分析,系统资源不够,一般体现在 CPU 使用高、 内存泄漏或OOM 的问题、IO问题、网络相关问题这四个方面

分析问题的方法

jps -v 查看java进程
jinfo -flags pid 查看运行参数
jstat -gc 8544 5000 100,将每隔5s采样一次pid为8544的gc,输出100次

jmap -dump:live,format=b,file=dump.hprof 29170 
#生成虚拟机的内存转储快照 注意线上可能会触发线上gc
jmap -heap 29170
jmap -histo:live 29170 | more
jmap -permstat 29170

jstack -l 29170 |more 显示虚拟机的线程快照

df -h # 磁盘 
free -m / -h # 内存
top cpu  # cpu          

复制代码

线上cpu100%报警(找出最耗时CPU进程-线程-堆栈-代码)

方法1:原生工具,慢
top -c #显示完整信息  P:cpu使用排序 M:内存使用排序
top -Hp 10765 ,#显示一个进程的线程运行信息列表  -H 显示线程信息,-p指定pid & P
printf "%x\n" 1080416进制   2f71
jstack 12084 | grep '0x2f71' -C5 --color 查看堆栈,找到线程在干嘛

方法2:
使用提前准备好的sh脚本,可以一条命名查看当前出事的线程代码,快,推荐
sh show-busy-java-threads.sh > a.txt #查询java耗时线程前5个
sh show-busy-java-threads.sh -p > a.txt #查询指定进程

方法3:
使用arthas,工具内置很多功能,比如可以查看源码,判断是否发布成功,可以用来排查疑难问题
curl -O https://alibaba.github.io/arthas/arthas-boot.jar
java -jar arthas-boot.jar
dashboard
thread -8
jad com.xx.xx.xx.xxximp 查看线上类代码
watch com.xx.xx.xx.xxximp doTask '{params}' '#cost>100' -x 2 
#观察会慢在什么入参上,监控耗时超过100毫秒的 doTask方法的入参,并且输出入参,展开2层入参参数
ognl #查询某静态字段的值

定位到堆栈就可以定位到出问题代码的行号,然后找对应的发布分支代码该行号即可
复制代码

线上内存OOM

某Java服务(假设PID=12084)出现了OOM,最常见的原因为:
1. 有可能是内存分配确实过小,而正常业务使用了大量内存
2. 某一个对象被频繁申请,却没有释放,内存不断泄漏,导致内存耗尽未调用close(),dispose()释放资源,例如:文件io,网络io
3. 某一个资源被频繁申请,系统资源耗尽,例如:不断创建线程(没有用线程池),不断发起网络连接等
总结:本身资源不够,申请资源太多,资源耗尽

分析工具:
jvisualvm(直方图),MAT(优先,直方图,跟踪内存使用的引用关系),JProfiler

线下分析:
服务挂掉之后有保留文件:直接下载dump文件导入mat分析
java -jar -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=

线上分析:
1. 确认是不是内存本身就分配过小
jmap -heap 12084

2. 找到最耗内存的对象
jmap -histo:live 12084 | head -n 10  #该命令会强制执行一次fgc

jmap -dump:format=b,file=/opt/dump.hprof {pid} #以二进制输出档当前内存的堆情况,
然后可以导入MAT等工具进行
tar –czf dump.tar.gz dump.hprof

3. 确认进程创建的线程数,以及网络连接数,如果资源耗尽,也可能出现OOM
ll /proc/17306/fd | wc -l
ll /proc/17306/task | wc -l
复制代码

如何防止线上问题发生

数据库:上线一个定时监控和杀掉慢SQL的脚本。这个脚本每分钟执行一次,检测上一分钟内,有没有执行时间超过一分钟(这个阈值可以根据实际情况调整)的慢SQL,如果有大事务自己觉得该阈值的合理性,如果发现,直接杀掉这个会话

cpu或者内存的使用率上做报警,大于90%的时候可以dump和jstack一次,甚至jstat也可以做,然后95%的时候也同样执行一次,甚至98或者99的时候也可以做一次,这样不仅可以保留现场,同时还可以对比

完善的服务报错日志监控,可选elfk+日志监控或sentry

完善的流程机制。完善的主机,中间件监控报警机制

遇到过的线上问题以及解决思路

Zuul 网关不响应任何请求,zuul假死

App打不开,请求超时,访问数据库超时,数据库cpu飙升有规律,在某个时间点才飙升,去调度中心找该时间断的的定时任务,排查是异步转账开多了线程导致的

工具汇总

参考

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改