基于arthas解决业务系统服务异常问题
现象
应用基于spring cloud + k8s 部署，接口的暴露基于了nodeport+openresty，同时为了保证业务的稳定接口添加了upstream 的重试机制
出现的问题是，当网关重新部署的时候服务可以使用一段时间，但是当业务系统量比较大的时候，过一段时间会出现服务不可用的问题
排错猜测
初步感觉是因为服务层接口故障问题，而且通过openresty 的日志看到upstream 有read timeout 的问题，过一段时间之后spring cloud gateway
暴露的服务基本就不能访问了，重新进行容器的创建就又短暂的可以了，初步感觉是接口故障(有可能是个别服务的问题)
基于arthas排错
因为入口都是走的gateway，而且我们的容器已经都集成了arthas 所以直接进入k8s pod 查看jvm 信息，首先查看了线程总的信息，很不好的是
关于spring boot 内嵌网络io 线程全是block（也是好的情况，至少确定了是gateway 的问题，不是openresty 的问题），然后我们重点查看下block
线程的信息，thread ,然后我们可以自下向上或者直接自上而下查看，结果通过查看到的信息是是log4j 连接的问题，结合我们的业务场景
是有可能的，因为我们依赖了graylog, 默认要求都是要走udp协议的，应该不会出现问题的，所以查看了下gatewy 记录日志的代码，结果是
走的tcp，tcp 协议就很明显了，很容易造成网络io 阻塞，解决方法很简单就是修改为udp的，但是合理的tcp也不应该会造成这么严重的问题，结果
通过排查日志组件的服务器，发现结果主机的iowit 很严重（排除挖矿以及可能病毒侵入情况）经过咨询原来虚拟化底层的存储出现了一些故障，造成存储
io影响比较严重
当前解决方法
调整为udp协议或者禁用写入graylog 系统（使用udp 更好）
说明
以上是基于arhtas 快速解决线上业务问题的一个实践，希望对大家有用
