web平台安装程序_工商银行基于Arthas打造在线诊断平台的探索与实践

本文主要是介绍web平台安装程序_工商银行基于Arthas打造在线诊断平台的探索与实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者 | 刘慕雨

在信息系统建设方面，工商银行一直积极探索，以开放的姿态借鉴行业先进经验，旨在为客户提供更优质的金融服务和用户体验。随着分布式架构和云计算平台在工行的广泛应用，如何高效排查程序错误或性能瓶颈，是个棘手的问题。

为此，我们基于 Arthas 建设了在线诊断平台，在保护客户信息安全的原则基础上，对相关能力做了剪裁和整合，通过 Web 方式支持更复杂的交互场景，在实际线上问题分析中发挥关键作用。

工行在线诊断平台：

下面对工行在线诊断平台的建设做个阶段性总结，分享一下我们的建设经验、实际效果以及未来展望，也希望能给社区提供一个参考。

传统方式排查问题的痛点

对于后端工程师，一旦线上程序逻辑出错，问题排查如同破案，在分析研判时，问题现场的第一手信息是最珍贵的。开发人员很容易首先想到的就是阅读日志，从海量的日志中寻找蛛丝马迹，这就好比是对犯罪现场周边的视频监控录像逐一回看，非常辛苦。如果问题现场的日志记录缺失，就尝试在本地重现问题并调试解决，本地难以重现的，只能再加日志，再部署，再重现，然后再查日志，效率较低。对于复杂一些的比如程序性能问题，如何定位性能瓶颈，一不小心又要回到加日志、部署、查日志、再加日志的老路，不仅效率不高，也破坏了问题现场。

JDK 提供的工具如 jps、jmap、jstat、jstack、jconsole 等，可以为工程师提供一些帮助。Linux 操作系统的命令，如 top、free、pidstat、vmstat、iostat 等，也是排查问题尤其是性能调优必不可少的工具。但直接使用这些工具，对工程师的个人技术能力和经验要求较高。而且对企业来说，在生产环境直接通过命令行操作，是很敏感的行为。因此，如何在保证安全的基础上，又能像调试本地程序一样更便捷的排查分析，是个棘手的问题。

Arthas 的解决方案

2018 年我们在参加一次 Dubbo Meetup 上，听了关于使用开源的 Arthas 工具排查 Dubbo 问题的分享。研究发现，Arthas 通过 JVM 的 Attach 机制，在不影响服务连续性的情况下，实时连接到目标进程，便于工程师在线排查问题。此外，Arthas 的字节码增强框架，可以通过 Instrumentation 技术动态修改字节码(需要 Java 虚拟机实现支持 retransformClasses)，替换成新的 class，这就为在线调试提供了可能。

Arthas 原理图：

比如，使用 watch 命令，实时观测方法的调用情况；使用 jad 命令，把字节码反编辑成 java 代码；使用 redefine 命令，可以对代码做热更新，让开发人员告别不停“加日志、部署、查日志、再加日志”的套娃时代。在 Arthas 刚推出没多久，还提供了一个简单的 Web Console 功能，实际是一个以 Websocket 访问 Arthas 进程的方式，这也为我们后面建设在线诊断平台提供了思路。

落地使用上的困难

直接使用 Arthas 的命令行交互方式，不能满足金融级运维要求，在落地使用上存在一些实际的问题：

信息安全问题：Arthas 可以通过命令行方式，直接观测方法的入参、返回值，这就涉及到一些客户敏感信息，直接在生产环境使用命令行操作显然是不合适的。

学习成本问题：工具的安装使用存在一定的学习成本，尤其是对于新员工来说。

多人协作问题：当多个开发者对同一个目标进程进行诊断时，可能存在冲突，例如，一个同学正在 watch 某个方法，另一个同学把这个方法 redefine 了，那么第一个同学 watch 到的其实是别人替换后的代码的运行情况，这就像一个多线程访问共享资源的线程安全问题。再比如两个同学都在 attach 同一个进程，一个同学用完了，直接把 Arthas 进程 shutdown(关闭)，而另一个还在使用的同学就突然不能用了。

资源占用问题：如果开发者忘记关闭 Arthas，Arthas 进程会占用一定的系统资源(如内存、CPU)。当然，Arthas 本身对资源开销是有很多考虑的，比如 Arthas 使用自定义的类加载器加载自身的类，在关闭时将引用置空，这样在下一次垃圾回收的时候，自定义类加载器加载的类就会被回收，从而避免对原有工程的影响。因此，我们认为 Arthas 应该在排查问题时使用，而不应该当作常规监控工具一直运行。

环境不统一问题：在不同的 Java 虚拟机实现安装和使用 Arthas，可能会碰到一些奇怪的问题，比如用 Hotspot 虚拟机运行 Arthas 进程，而目标虚拟机是 J9 实现，attach 的时候可能会出错。另一方面，生产环境云上、云下节点规模庞大，网络访问权限是严格控制的，开发人员想远程连接目标进程，涉及到权限开通、版本管理、安装程序下发等问题。

技术方案

我们设计了一套轻巧的架构，让开发人员以 Web UI 的方式，便捷、直观的使用各类在线诊断能力。那么我们是怎么做的呢？

1. 整体架构

整体架构大致分成在线诊断平台、在线诊断网关(后简称网关)、在线诊断进程三部分，通过一个网关集群统一代理对云上、云下节点的访问，网关提供 Restful 接口给在线诊断平台(后简称平台)调用。一个接口可能组合了多个 Arthas 指令，也可能对指令的执行结果进行剪裁和修改，处理成 json 格式数据返回给平台做展示。

整体架构图：

1)在线诊断平台

在线诊断平台是开发人员进行在线诊断的入口，平台通过 Web UI 的方式提供一站式在线诊断能力，支持复杂的交互场景。除了提供出色的用户体验，平台还解决了安装卸载、多人协作、用户鉴权、连接保持、操作审计等问题。

安装卸载：根据用户在平台输入目标节点和进程信息，实现诊断程序的安装和卸载，具体将在下一节介绍。

多人协作：当多个用户同时诊断同一个进程时，对于存在冲突的功能，平台通过分布式锁实现互斥，保障同一时刻只有一个用户能使用，当然这么做的前提是平台在功能设计时考虑原子性。另外，当一个用户试图关闭一个其他用户正在使用的连接时，也会被拒绝。

用户鉴权：建立审批和黑白名单机制，基于 RBAC 模型，同时联动 CMDB，对操作人员的权限进行严格管控，普通开发者需要被授权才可使用，各类诊断功能的使用权限也和用户角色挂钩，权限控制强度从生产环境到开发环境逐渐减弱。

连接保持：Arthas 一些命令比如 dashboard，提供了实时监控目标进程整体运行情况的功能，默认每 5 秒刷新一次。对于这样的功能，平台的前端通过 websocket 与后端保持连接，后端内存中维护了一个目标对象和已连接用户的对照关系，如果多个用户同时监控某个目标对象，后端每次只会定时发送一次请求给网关。这么做的好处，是在保证了实时监控的同时，节约连接资源，避免了多人访问时，到目标服务器的不必要的重复连接。此外，为了防止用户忘记卸载诊断进程，对照关系也会同步到配置中心，当内存中某个目标对象对应的用户全部下线时，会触发一次检查，如果发现配置中心中的用户也已经全部下线，平台会自动发送 shutdown 请求给网关，卸载诊断进程。

操作审计：通过切面的方式，对用户的各类操作进行记录和存储，达到审计的目的。

2)在线诊断网关

网关的作用，一是统一打通了到行内云上、云下环境的火墙；二是由于我们当时使用的 Arthas 版本还不支持 Restful 接口(最新版本已支持)，返回报文都是文本的形式，网关侧在这里会对文本进行解析，处理成 json 格式的结构数据，方便平台侧做展示。归纳起来，网关的主要目的是统一代理对目标节点的访问，同时封装诊断能力，提供标准 json 结构数据的 Restful 接口给行内各平台访问。网关在封装诊断能力时，还会进行参数校验、超时管理、数据脱敏、文本处理等工作。

参数校验：网关需要对诊断命令的参数做合法性校验，比如tt命令要控制最大观测次数防止撑爆内存，保证使用安全。

超时管理：一些监听类的命令，比如watch命令，如果一直监听不到调用，需要设置超时时间，防止连接一直不被释放。

数据脱敏：对于涉及客户敏感信息的命令，网关会做数据脱敏，保障客户信息安全，部分关键业务的敏感数据，网关侧会做封闭禁止访问。

文本处理：网关向 Arthas 进程发送指令后，收到的报文是文本形式，为了便于平台侧展示，网关将非结构数据处理成结构数据，并对文本中的一些非关键数据进行剪裁。这里要注意因为 telnet 有个窗口大小的配置要适当调整，配置太小的话有可能导致文本不全。

3)在线诊断进程

也就是 Arthas 进程，需要考虑安装、启停、版本管理、网络隔离等问题，具体做法在下一节详细介绍。

2. 诊断过程详解

工程师第一次对目标服务器进行诊断时，涉及安装、启动、使用、卸载等一系列步骤，如下图所示：

1)诊断前准备

下图是我们的安装界面，当用户授权通过后，即可填写目标服务器信息开始安装。如果是传统虚拟机时，用户需输入虚拟机 ip 和目标进程关键字(如进程的 pid、进程的启动类名、进程的 jar 名称等)；如果是容器，还需提供容易 id：

2)开始安装

用户点击安装后，会触发一系列操作。首先在线诊断平台发送一个探活请求给网关，网关收到请求后相应的也发送一个空指令给目标节点。平台根据响应判断，如果探活成功，则发送诊断请求开始诊断；否则发送安装请求到行内指定的管理系统(传统虚拟机/容器，后续简称通道)。

3)获取安装介质

以传统虚拟机为例(如果是容器则把安装介质下发到宿主机)，通道去目标服务器指定目录查找诊断程序的版本文件，如果获取成功且版本是最新的，则通道直接执行启动脚本。否则，通道会通知目标服务器从公共的文件服务器上，下载最新版本的安装介质。

4)启动诊断程序

安装介质实际是一个压缩包，包括安装脚本、jar、版本文件等。安装介质首次下载到目标服务器后，通道对其解压并执行启动脚本。我们修改了 Arthas 的启动脚本，根据用户输入的进程关键字，找到目标进程，然后使用和目标进程相同的 jdk 版本，启动诊断程序。注意，启动时 Arthas 的 target-ip 参数被设置为网关地址，以隔离其他渠道访问，默认值 127.0.0.1 表示只能本地访问。

5)使用和卸载

诊断进程接收用户诊断指令，开始诊断。使用完用户可手工点击卸载，销毁诊断进程。

实际使用效果

这里举几个例子，看一下平台的实际使用效果。

1. 控制面板

基于 dashboard 命令，控制面板实时展示目标进程的整体运行情况，包括线程、jvm、操作系统等，每隔 10s 刷新一次，用户也可选择手动刷新。线程按 CPU 使用率取 TOP10，jvm 主要展示内存分布和 GC 情况：

点击查询更多可以查看详情，比如监控 jvm 的内存及垃圾回收情况：

2. 线程清单

线程清单页面按 CPU 使用率分页展示所有线程，支持按线程状态(如 RUNNABLE、BLOCKED)过滤，在控制面板页面点击查看更多，也可以直接跳到此页面：

点击某条记录，跳转到线程详情，展示线程堆栈，在堆栈中选中一个方法，则可以直接进行方法观测、方法追踪、方法追溯、方法监控、反编译等操作：

3. 方法监测

方法监测指的是对方法运行情况的监控和观测，具体包括下面几个功能。

1)方法观测

支持对选中的堆栈中的方法进行观测，也就是 watch 命令，这里以开发环境举例(开发环境不做数据脱敏)，可以实时捕获方法的输入、输出、异常堆栈、执行耗时等，并且支持指定观测次数、耗时限制等条件。比如我这里对 UserServiceImpl 类的 findUser 方法的调用情况进行观测：

当方法抛异常时展示堆栈：

2)方法追踪

方法追踪指的是追踪方法的调用栈，打印每个方法的执行耗时，基于 trace 命令实现，在排查性能问题时非常有用。看一下方法追踪的界面，直接高亮标记出调用栈上耗时最久的方法，也支持配置过滤规则，过滤一些不关心的方法(比如 java 底层代码)。在这个方法调用栈界面，又可以选中其中某个方法，进行观测、追溯、监控等操作，不同的诊断能力之间都是打通的：

3)方法追溯

有时需要追溯方法被谁调用了，则可以使用方法追溯。比如这里通过方法追溯可以看到 Dubbo 的 Filter 处理链：

4)方法监控

有时我们需要对某个方法一段时间的执行情况进行观测，这时可以使用方法监控功能。比如这里每隔 10 秒统计一次方法的执行次数、成功失败次数、平均耗时、失败率等指标：

4. 反编译

当我们需要确认 Java 虚拟机加载的代码情况时，比如你修改的代码是否生效，我们在本地经常使用一些反编译工具以达目的。jad 命令提供了在线反编译能力，我们基于 jad 以界面的形式展示 Java 虚拟机加载的实际代码，同时也会展示类加载器树、类的路径。比如这里对 findUser 方法的反编译情况(不指定方法名的话，则对整个类反编译)，可以看到这个类属于 springboot 项目，被 spring 的类加载器加载：

5. 其他能力

我们对其他的实用命令，也做了一些封装和定制，比如 sc、sm、redefine、tt 等，这里就不一一介绍。此外，我们也将实时诊断能力和内部监控运维系统相整合，在排查问题时，可以通过直接跳转的方式申请在线诊断权限，对目标进程做实时诊断。下图是行内全链路跟踪产品截图，支持直接对问题链路关联的节点进行诊断：

回顾与展望

简要回顾一下前面提到的几个困难和我们的解决方案：

学习成本问题：我们通过 Web UI 的方式降低学习成本，也提供了更复杂的交互场景和出色的用户体验。通过网关统一提供 Resful 接口提供结构数据，也更便于集成到企业内部其他运维平台。

多人协作问题：通过会话管理、互斥访问、自动卸载等手段，解决多人协作问题。

信息安全问题：通过用户鉴权、数据脱敏、操作审计、网络隔离等手段，解决信息安全问题。

资源占用问题：通过自动卸载、减少连接、自定义类加载器(Arthas自带)等手段，在充分性能测试基础上，保障资源占用可控。

环境不统一问题：通过搭建网关集群，统一代理对云上、云下环境的访问。采用一致的策略，统一管理云上、云下环境介质的版本、下发和安装。

当前，工行在线诊断平台已在实际线上问题分析中持续发挥关键作用，Arthas 也越来越得到社区的关注和开发者的认可。Arthas 官方在新版本中已经支持了 Restful 接口，提供结构数据，也支持了更丰富的诊断命令，这跟我们的建设思路不谋而合。未来，我们将继续积极参与社区建设，将工行的实践经验分享给大家。

Arthas 正在参与2020开源中国项目评选！

如果Arthas帮助您解决过问题，好用的话，请帮忙投Arthas一票。