java应用线上问题排查思路

常见问题分类

java应用线上一般会出现什么问题?一般可以分为业务上的问题,还有系统上的问题。常见的情况:

1、业务问题:

比如:找不到服务、业务异常报错、运行时异常报错

2、资源问题:

比如内存溢出、内存泄漏、CPU飙升、磁盘IO居高、磁盘空间不足、网络IO突然升高、线程资源不够。

这里主要是出现资源问题的分析。

资源的概念:

一个JAVA应用是通过JVM运行在操作系统上(当然有一些还部署在类似tomcat这种容器中)。所以涉及的资源本身有:

JVM的资源:堆栈内存、线程、创建的异步队列等相关资源

操作系统:CPU、内存、磁盘、网络、磁盘空间等指标

外部依赖:跟外部中间件相关的连接池、及外部中间件:如数据库、redis等

第三方依赖:依赖外部第三方的系统服务。

怎么发现资源问题:

1、主动发现:相关owner每天查看系统监控情况,主动发现了一些异常的现象。

2、拨测:通过定时对应用进行连通性测试,如果发现服务不可用时进行告警;一般这种主要针对依赖的第三方系统服务

3、监控系统告警:应用上线的时候,需要对这些资源进行监控,建立监控指标,如果超过指标时进行告警。比如应用响应时间在某个时间段上升了,资源层面cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等各个服务器指标异常,可能是某台的服务器出现了异常,但是业务还未受到大面积影响

4、人工发现:客户反馈

监控指标:

1、系统本身:cpu、内存、io、tcp连接数、disk空间、线程数,等指标

2、应用:GC次数、数据库连接池,常见日志Error比如OutOfMemoryError

3、中间件依赖:中间件的状态、中间件服务器的CPU、内存、磁盘等指标

4、数据库层面:慢sql日志,锁日志,RO延迟等等。

5、Redis:redis的状态、cpu、内存容量、磁盘容量

6、外部依赖:服务状态、cpu、内存、磁盘等

出现资源问题怎么处理:

1、紧急措施:

对于7*24小时的应用一般都需要快速恢复服务,留给排查的时间窗口其实不多,很可能需要最短时间内重启应用,所以需要快速保留现场,比如dump。

如果有多个运维的话,可以进行分组配合:(切流量抓快照、重启应用、线上分析、迅速限流)

2、快速分析:

怎么利用工具快速定位问题:

操作系统命令:free、top、netstat

常用的jvm命令:jstack、jmap、jstat

工具的使用:mat、gcviewer

在线运维工具:arthas

日志及监控:skywalking、elk

3、分析要点:

最慢:关注慢交易、慢sql等相关指标;可以通过skywalking或者其他监控工具发现

最多:关注线程数很多的交易,如果同个交易线程数特别多,那可能问题出现在线程方面;可以通过jstack的堆栈日志进行分析。

最高:占用CPU最高的线程,一般是通过top,top -Hp pid的方式,配合jstack日志进行分析。一般如果CPU占比不是GC线程,而是业务线程;那最有可能是当前的交易产生的问题。

最大:占用内存最多的对象或者线程,CPU是比较容易捕获的信息,内存对象一般需要dump,而且需要内存分析工具才能查看,所以最好能快速判断,然后进行dump日志,最后采用mat、或者gcviewer进行分析。VM启动参数最好也指定gc日志及出现内存溢出时生成dump文件。

4、事后处理:

1、限流:当定位到某个交易出现异常的时候,针对该交易进行限流,可以避免故障进行蔓延。

2、隔离:对于没办法快速优化、而又需要持续在线的服务,可以抽离出来单独部署,进行故障隔离。

3、优化:对功能分析进行优化,同时进行压测,避免重复问题出现。

5、预防措施:

日常巡检:

        线上很多突如其来的意外,往往都带着必然性。比如:功能迭代越来越复杂,接口越来越慢;线上的容量在快速增长是不是被忽视了,大客户的报表功能是否有做过压测,在线上有没有分析过sql性能等等。

        所以在日常对系统的健康情况需要不定时巡检,可以的话就做成自动化脚本。比如:慢接口的监控、慢sql的监控、redis大key的梳理、交易量增速的监控、数据库表数据量监控等。

 评审压测:

        开发过程中,需要对每个交易的设计方案进行评审,同时对交易的流量进行预估,对流量较大的交易在上线前需要进行压测。

线上常见的案例:

1、动态条件查询未做非空判断,load出全表数据,导致内存溢出,引起CPU占用100%并引发事故

2、生成树形结构数据时,结果parentID等于自己导致循环查数据

3、while(true)循环没有退出条件

4、慢sql引起数据库上升,其他sql挂起,系统短时不可用

5、外调第三方服务没有加超时时间,导致线程数爆掉

6、Redis节点容量不够导致业务异常

7、使用一些性能不好的API,比如POI的XLS,生成excel文件数据量过大时,很容易就CPU暴涨。

最后欢迎读者在评论区留下你们遇到过的线上问题及分析思路。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值