作者|刘慕雨中国工商银行软件开发中心云计算实验室
在信息系统建设方面，工商银行一直积极探索，以开放的姿态借鉴行业先进经验，旨在为客户提供更优质的金融服务和用户体验。随着分布式架构和云计算平台在工行的广泛应用，如何高效排查程序错误或性能瓶颈，是个棘手的问题。
工行在线诊断平台：
对于后端工程师，一旦线上程序逻辑出错，问题排查如同破案，在分析研判时，问题现场的第一手信息是最珍贵的。开发人员很容易首先想到的就是阅读日志，从海量的日志中寻找蛛丝马迹，这就好比是对犯罪现场周边的视频监控录像逐一回看，非常辛苦。如果问题现场的日志记录缺失，就尝试在本地重现问题并调试解决，本地难以重现的，只能再加日志，再部署，再重现，然后再查日志，效率较低。对于复杂一些的比如程序性能问题，如何定位性能瓶颈，一不小心又要回到加日志、部署、查日志、再加日志的老路，不仅效率不高，也破坏了问题现场。
JDK提供的工具如jps、jmap、jstat、jstack、jconsole等，可以为工程师提供一些帮助。Linux操作系统的命令，如top、free、pidstat、vmstat、iostat等，也是排查问题尤其是性能调优必不可少的工具。但直接使用这些工具，对工程师的个人技术能力和经验要求较高。而且对企业来说，在生产环境直接通过命令行操作，是很敏感的行为。因此，如何在保证安全的基础上，又能像调试本地程序一样更便捷的排查分析，是个棘手的问题。
Arthas原理图：
比如，使用watch命令，实时观测方法的调用情况；使用jad命令，把字节码反编辑成java代码；使用redefine命令，可以对代码做热更新，让开发人员告别不停“加日志、部署、查日志、再加日志”的套娃时代。在Arthas刚推出没多久，还提供了一个简单的WebConsole功能，实际是一个以Websocket访问Arthas进程的方式，这也为我们后面建设在线诊断平台提供了思路。
直接使用Arthas的命令行交互方式，不能满足金融级运维要求，在落地使用上存在一些实际的问题：
我们设计了一套轻巧的架构，让开发人员以WebUI的方式，便捷、直观的使用各类在线诊断能力。那么我们是怎么做的呢？
整体架构大致分成在线诊断平台、在线诊断网关（后简称网关）、在线诊断进程三部分，通过一个网关集群统一代理对云上、云下节点的访问，网关提供Restful接口给在线诊断平台（后简称平台）调用。一个接口可能组合了多个Arthas指令，也可能对指令的执行结果进行剪裁和修改，处理成json格式数据返回给平台做展示。
整体架构图：
在线诊断平台是开发人员进行在线诊断的入口，平台通过WebUI的方式提供一站式在线诊断能力，支持复杂的交互场景。除了提供出色的用户体验，平台还解决了安装卸载、多人协作、用户鉴权、连接保持、操作审计等问题。
网关的作用，一是统一打通了到行内云上、云下环境的火墙；二是由于我们当时使用的Arthas版本还不支持Restful接口（最新版本已支持），返回报文都是文本的形式，网关侧在这里会对文本进行解析，处理成json格式的结构数据，方便平台侧做展示。归纳起来，网关的主要目的是统一代理对目标节点的访问，同时封装诊断能力，提供标准json结构数据的Restful接口给行内各平台访问。网关在封装诊断能力时，还会进行参数校验、超时管理、数据脱敏、文本处理等工作。
也就是Arthas进程，需要考虑安装、启停、版本管理、网络隔离等问题，具体做法在下一节详细介绍。
工程师第一次对目标服务器进行诊断时，涉及安装、启动、使用、卸载等一系列步骤，如下图所示：
用户点击安装后，会触发一系列操作。首先在线诊断平台发送一个探活请求给网关，网关收到请求后相应的也发送一个空指令给目标节点。平台根据响应判断，如果探活成功，则发送诊断请求开始诊断；否则发送安装请求到行内指定的管理系统（传统虚拟机/容器，后续简称通道）。
以传统虚拟机为例（如果是容器则把安装介质下发到宿主机），通道去目标服务器指定目录查找诊断程序的版本文件，如果获取成功且版本是最新的，则通道直接执行启动脚本。否则，通道会通知目标服务器从公共的文件服务器上，下载最新版本的安装介质。
安装介质实际是一个压缩包，包括安装脚本、jar、版本文件等。安装介质首次下载到目标服务器后，通道对其解压并执行启动脚本。我们修改了Arthas的启动脚本，根据用户输入的进程关键字，找到目标进程，然后使用和目标进程相同的jdk版本，启动诊断程序。注意，启动时Arthas的target-ip参数被设置为网关地址，以隔离其他渠道访问，默认值127.0.0.1表示只能本地访问。
诊断进程接收用户诊断指令，开始诊断。使用完用户可手工点击卸载，销毁诊断进程。
这里举几个例子，看一下平台的实际使用效果。
基于dashboard命令，控制面板实时展示目标进程的整体运行情况，包括线程、jvm、操作系统等，每隔10s刷新一次，用户也可选择手动刷新。线程按CPU使用率取TOP10，jvm主要展示内存分布和GC情况：
点击查询更多可以查看详情，比如监控jvm的内存及垃圾回收情况：
线程清单页面按CPU使用率分页展示所有线程，支持按线程状态（如RUNNABLE、BLOCKED）过滤，在控制面板页面点击查看更多，也可以直接跳到此页面：
点击某条记录，跳转到线程详情，展示线程堆栈，在堆栈中选中一个方法，则可以直接进行方法观测、方法追踪、方法追溯、方法监控、反编译等操作：
方法监测指的是对方法运行情况的监控和观测，具体包括下面几个功能。
支持对选中的堆栈中的方法进行观测，也就是watch命令，这里以开发环境举例（开发环境不做数据脱敏），可以实时捕获方法的输入、输出、异常堆栈、执行耗时等，并且支持指定观测次数、耗时限制等条件。比如我这里对UserServiceImpl类的findUser方法的调用情况进行观测：
当方法抛异常时展示堆栈：
方法追踪指的是追踪方法的调用栈，打印每个方法的执行耗时，基于trace命令实现，在排查性能问题时非常有用。看一下方法追踪的界面，直接高亮标记出调用栈上耗时最久的方法，也支持配置过滤规则，过滤一些不关心的方法（比如java底层代码）。在这个方法调用栈界面，又可以选中其中某个方法，进行观测、追溯、监控等操作，不同的诊断能力之间都是打通的：
有时需要追溯方法被谁调用了，则可以使用方法追溯。比如这里通过方法追溯可以看到Dubbo的Filter处理链：
当我们需要确认Java虚拟机加载的代码情况时，比如你修改的代码是否生效，我们在本地经常使用一些反编译工具以达目的。jad命令提供了在线反编译能力，我们基于jad以界面的形式展示Java虚拟机加载的实际代码，同时也会展示类加载器树、类的路径。比如这里对findUser方法的反编译情况（不指定方法名的话，则对整个类反编译），可以看到这个类属于springboot项目，被spring的类加载器加载：
我们对其他的实用命令，也做了一些封装和定制，比如sc、sm、redefine、tt等，这里就不一一介绍。此外，我们也将实时诊断能力和内部监控运维系统相整合，在排查问题时，可以通过直接跳转的方式申请在线诊断权限，对目标进程做实时诊断。下图是行内全链路跟踪产品截图，支持直接对问题链路关联的节点进行诊断：