现象

应用基于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 快速解决线上业务问题的一个实践，希望对大家有用