工商银行打造在线诊断平台的探索与实践

标签: 工商银行 在线 诊断 | 发表时间:2020-10-19 23:03 | 作者:阿里巴巴云原生
出处:http://weekly.dockone.io



作者 | 刘慕雨 中国工商银行软件开发中心云计算实验室

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

为此,我们基于 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 有奖征文正在进行中!

为了让更多开发者开始用上 Arthas 这个 Java 诊断神器,今年 3 月 26 日,Arthas 社区联合 JetBrains 推出  Arthas 有奖征文活动聊聊这些年你和 Arthas 之间的那些事儿。活动已进行至第五期,点击链接即可参与: http://alibabacloud.mikecrm.com/9khcRrs,欢迎大家踊跃投稿,参与即有可能获奖!

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

相关 [工商银行 在线 诊断] 推荐:

工商银行打造在线诊断平台的探索与实践

- - DockOne.io
作者 | 刘慕雨 中国工商银行软件开发中心云计算实验室. 在信息系统建设方面,工商银行一直积极探索,以开放的姿态借鉴行业先进经验,旨在为客户提供更优质的金融服务和用户体验. 随着分布式架构和云计算平台在工行的广泛应用,如何高效排查程序错误或性能瓶颈,是个棘手的问题. 为此,我们基于 Arthas 建设了在线诊断平台,在保护客户信息安全的原则基础上,对相关能力做了剪裁和整合,通过 Web 方式支持更复杂的交互场景,在实际线上问题分析中发挥关键作用.

大型系统在线问题诊断与定位

- - 掘金 架构
本文是武汉 gopher meetup 的分享内容整理而成,分享内容在 “无人值守” 的两篇和其它社区分享中亦有提及. (也就是说你看过那两篇,这个可以不用看了). 混口饭吃也是不容易,既然有问题了,我们还是要解决的. 要先看看有没有现成的思路可以借鉴. Google 在 这篇论文里提到过其内部的线上 profile 流程:.

工商银行神秘技术故障引发恐慌

- - Solidot
中国最大国有银行工商银行的柜面取款、ATM、网银等服务周日中断近一个小时,引发了客户恐慌和诸多猜测,其中包括黑客攻击,以及银行为紧缩银根而有意为之. 国家电视台CCTV声称工行技术故障导致服务中断45分钟. 工商银行则通过官方微博表示,计算机系统从上午10:38开始升级,造成部分业务受到影响,到11:23所有服务已经全部恢复.

工商银行MySQL数据库架构解密

- -
点击▲关注 “IT168企业级”给公众号置顶. 作者:林承军   编辑:爱可生. 摘要:本文根据DTCC数据库大会分享内容整理而成,将介绍工行 IT 架构转型中传统 OLTP 数据库架构面临的挑战和诉求,构建基于 MySQL 分布式企业级解决方案实践历程,包括技术选择、高可用设计、两地三中心容灾、运维管理、资源使用效率等方面的思考和实践经验,同时也介绍了工行转型的成效以及对后续工作的一些思考.

中国工商银行DevOps工具链建设之路

- - DockOne.io
【编者的话】新技术发展迅猛,金融产品和服务模式创新加快,快速增长的产品需求与有限研发资源之间的矛盾长期存在. 如何提高研发效能,快速上线业务需求,支撑业务创新发展,是金融机构产品研发部门面临的挑战. 传统银行的产品、架构体系庞大复杂,对研发效能提升带来更大挑战,无论流程改进还是工具支撑,都需兼顾现有系统的安全稳定运行.

中国工商银行银行卡被盗用后,处理过程实录

- Nickcheng - 博客园-Duiker's Blog
最近发现自己工商银行的银行卡消磁了,所以去工商银行的换张卡,结果发生了一连串杯具. 换完卡,查询了一下余额,发现少了几千块,打印详单吧,确认是被盗用了,联系工行,打110报警,结果步步都是个坎,看来老百姓别没事麻烦这些大爷. 续1:在工行详单中通常会打印出所在的地区号和网点号,但是对于普通老百姓来说,给出的这些数字,你想了解到底是在那个地方被盗刷了,您就得打95588这个电话了,发生问题的两笔业务的地区号分别是4600和4000,查询后确认分别是北京和深圳.

如何诊断CDN故障

- - 火丁笔记
某项目使用CDN做文件下载服务,最近不时有网友反馈下载出错,因为CDN是第三方提供的,且节点众多,所以诊断起来有点麻烦,必须想想招儿. 首当其冲的问题是如何确认CDN有哪些节点. 幸运的是通过 阿里测提供的服务,我们能拿到这个IP列表,当然这个IP列表不可能百分百完整,不过应该包含了大部分的节点,有兴趣的可以参考 百度的JQuery CDN例子.

JVM诊断调优CheatSheet

- - ImportNew
使用top去获取进程cpu使用率;使用/proc文件查看进程所占内存. 查看类的一些信息,如字节码的版本号、常量池等. 查看进程的gc情况. jstat -gcutil [pid] (显示总体情况). jstat -gc [pid] 1000 10(每隔1秒刷新一次 一共10次). 查看jvm内存使用状况.

初步诊断你的 GC

- - IT瘾-dev
本文是好友阿飞写的,并且经过作者同意发的原创. 阿飞Javaer,转载请注明原创出处,谢谢. JVM的GC机制让Java程序员省去了自己垃圾回收的烦恼,大大提高了生产效率. 但是正因为JVM垃圾回收机制足够优秀,导致很多Java程序员对JVM这个黑盒了解甚少,很多人没有去了解它,很多人也没机会去了解它.

使用pt-stalk诊断MySQL问题

- - haohtml's blog
在MySQL服务器出现短暂(5~30秒)的性能波动的时候,一般的性能监控工具都很难抓住故障现场,也就很难收集对应较细粒度的诊断信息. 另外,如果这种波动出现的频率很低,例如几天才一次,我们也很难人为的抓住现场,收集数据. 这正是pt-stalk所解决的问题. pt-stalk是 Percona-Toolkit的一部分(其前身是 Aspersa的一部分).