企业官网建设流程全解析

Arthas Web Console 可视化界面指南：基于 HTTP API 构建的 Web 版 Arthas 诊断台

【免费下载链接】arthasAlibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas项目地址: https://gitcode.com/gh_mirrors/ar/arthas

Arthas Web Console 是 Arthas 官方仓库中一套基于 HTTP API 构建的可视化 Web 前端。它把dashboard、thread、tt、monitor、trace、stack、watch、profiler、options等 Arthas 命令封装成带图表、表格与交互式表单的图形界面，让开发者不必记忆命令行参数，即可在浏览器中完成线程分析、内存观测、方法追踪与配置修改。本文将以 web-ui/arthasWebConsole/README_ZH.md 为骨架，结合仓库源码（web-ui/arthasWebConsole目录下的 Vue3 + TypeScript 工程）深入讲解其功能模块、HTTP API 调用机制与开发构建方式，读完可掌握 Arthas Web Console 的使用技巧与二次开发思路。

一、项目定位：从 CLI 到可视化 Web 终端的进化

Arthas 原生提供 Telnet 与 WebSocket 两种交互终端（对应入口/index.html，即原版 Web terminal）。Arthas Web Console 则提供了一条完全不同的路径——基于 HTTP API 的可视化界面，其第二个入口为/ui/index.html（新版可视化界面）。

两者的核心区别在于通信方式：

• 原版 Web terminal：基于 WebSocket 长连接，逐字符交互，命令结果以文本流返回；
• Web Console：基于 HTTP API（详见 site/docs/doc/http-api.md），每次操作是一次 HTTP 请求，响应是结构化 JSON，前端据此渲染图表与表格。

从路由配置 routes.ts 可以看出，Web Console 将功能划分为四大区域：

每个功能页面都与 CLI 命令同名，具体命令语义可通过点击页面右上角的 Arthas 图标跳转到官方命令文档查阅。

二、快速使用指南

1. SessionID 的管理

HTTP API 的会话体系包含init_session、join_session、close_session、interrupt_job等动作。在 Web Console 中，大多数场景下无需手动关心 sessionID：点击右上角按钮即可快速获取（init_session）或销毁（close_session）sessionID。

值得说明的是：dashboard、monitor、tt等轮询类命令依赖 sessionID才能工作（异步执行结果需要 session 承载）；而thread、jad、ognl等即时命令不需要 sessionID。在 fetch.ts 的实现中，请求参数缺失时由 store 自动补齐：

• 请求对象中显式传入的值优先使用；
• 传入undefined时使用全局 store 中保存的默认值（即已初始化的 sessionID）；
• 属性完全不传时，自动赋值为空字符串。

也就是说，前端在发起请求时通过getRequest()统一注入sessionId、consumerId、requestId三个字段，用户层面几乎感知不到 session 的存在。

2. 刷新页面与 interrupt 按钮

• 遇到奇怪的问题，刷新网页是首选排障手段——所有状态都保存在前端内存中，刷新即可重置；
• 当界面上出现红色的interrupt按钮时，说明当前已进入轮询状态（dashboard与 real time 类页面最常见）。点击该按钮会向前端发送interrupt_job动作中断当前任务，停止轮询。

从 fetch.ts 的interruptJob()可以看到：它先置jobRunning = false，再以interrupt_job动作提交请求；轮询循环在检测到jobRunning为 false 后自动close()，从而优雅地停止pull_results循环。

三、dashboard：实时总览大盘

dashboard 页面基于 Arthas 的dashboard命令实现，展示形式如下：

结合 DashBoard.vue 的源码，其数据流是：

1. 挂载时先asyncInit()初始化 session，随后以async_exec动作提交dashboard命令，拿到返回的jobId；
2. 用pullResultsLoop开启长轮询循环，持续pull_results拉取命令结果；
3. 每次拿到type === "dashboard"的结果后，分别喂给三个渲染器。

页面包含三块核心可视化：

• 内存折线图：从memoryInfo.heap、memoryInfo.nonheap、memoryInfo.buffer_pool中提取数据，每块区域绘制max / total / used三条折线（无 max 时退化为两条），并叠加一条usage(%)使用率曲线，纵轴左侧为 MB，右侧为百分比；
• GC 柱状图：读取gcInfos，以柱状图同时展示collectionCount（左轴）与collectionTime（右轴，单位 ms）；
• 线程表格：展示threads数组，默认只显示前 3 个最忙的线程（pri初始值 3），可通过页面上的limit按钮配合-/+调整，数值越大展示的忙线程越多；表格列包括id、name、cpu、daemon、deltaTime、group、interrupted、priority、state、time。

此外，页面顶部以 badge 形式展示runtimeInfo中的 JVM 运行时信息（如 JVM 版本、运行时长、操作系统等，排除timestamp与uptime两个字段）。

四、real time：异步命令的可视化监控

real time 区域（/asynchronize）承载tt、monitor、stack、trace、watch、profiler等需要持续监听的命令，它们必须依赖 sessionID。与 dashboard 相同，这些页面通过async_exec提交命令、以pull_results长轮询持续拉取增量结果，并用折线图实时展示tt的 cost 与monitor的 RT 等耗时指标。

tt：方法调用追踪与回放

tt页面（Tt.vue）是目前功能最完整的异步页面，提供三类操作：

1. 追踪记录（all records）

点击 “all records” 按钮，前端执行tt -l一次性拉取全部已记录的时间片（TimeFragment），清空旧数据后填充表格。表格展示index、timestamp、className、methodName、cost、object、params、returnObj、throwExp等列，其中params以“参数名:参数值”的形式逐行列出，returnObj与throwExp以 pre/code 块展示原始内容。

2. 触发回放（invoke）

在表格中根据index找到目标记录后，点击该行的invoke按钮，前端执行tt -i ${index} -p重放那一次方法调用。回放结果（replayResult）与sizeLimit、replayNo一起展示在 “invoked result” 面板中，并支持对同一 index 再次 invoke。

3. 按条件搜索（search records）

搜索框使用Advice 对象语法构造条件，例如method.name=="print"即可精确匹配方法名为print的记录。前端将输入包装为tt -s '条件'执行；若匹配不到任何记录（timeFragmentList为空），会弹出 “not found” 错误提示。

cost 折线图：页面顶部使用 ECharts 折线图以index为横轴、cost(ms)为纵轴展示每次调用的耗时走势，并内置了dataZoom缩放（起始 50%、结束 100%）与 toolbox 数据视图功能，便于观察耗时突变。

五、immediacy：即发即回的即时命令

immediacy 区域（/synchronize）承载thread、jad、mbean、heapdump、vmtool、ognl、reset、retransform等一发送就有响应的命令，不需要 sessionID。这类命令前端以exec动作一次性提交，拿到结果即渲染，部分功能提供refresh 手动刷新按钮。

thread：线程详情与过滤

在 Thread.vue 中，页面刻意没有做自动轮询：thread 属于即时命令，若反复自动执行会污染history并增加后端压力，因此采用用户手动点击 “get threads”来获取当前线程快照。源码中实际拼接的命令为：

thread --all [-b --lockedMonitors --lockedSynchronizers] [-i <sample interval>] [-n <top>] [--state <value>]

• sample interval：采样间隔（默认 200ms），对应-i参数；
• top threads：控制展示前几个最忙的线程，对应-n参数，0 代表不限制，此时展示完整线程统计并按 CPU 使用率降序排序；
• is blocking：开启后追加-b --lockedMonitors --lockedSynchronizers，用于排查死锁阻塞线程；
• state：通过下拉框按线程状态过滤（WAITING / RUNNABLE / TIMED_WAITING / BLOCKED / all）。

页面顶部以计数徽章展示各线程状态的数量（NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED），中部是线程表格，底部为选中线程的stackTrace面板（点击行内 “get stackTrace” 按钮执行thread ${threadId}获取单线程堆栈）。

filter 过滤功能：支持按“列名:值”的语法对表格做客户端过滤，例如：

id:-1 // 过滤出所有 id = -1 的行

• 允许多个列同时过滤，目前仅支持=精确比较语义；
• name与group两列是包含匹配（支持多个子串取交集，可用[a,b]形式表达多值）；
• 其余列（如id、cpu、state）为精确匹配。

option：配置查看与修改

option 页面（/config/options，对应 Options.vue）执行options命令，将返回的全局配置（level、name、type、value、summary、description）渲染为可编辑表格：

• 点击某行的edit按钮弹出输入框，修改后执行options <key> <value>提交；
• 提交成功后，从返回结果的changeResult.afterValue同步前端值；失败则自动回退为原值；
• 表格按level升序、name字母序排序。

需要提醒：该页面不保证修改安全——它允许修改osName这类敏感的全局选项，仅适合有经验的排障场景，误改可能导致目标 JVM 行为异常。

六、console 与 terminal

• console（/console）：一般不会用到，它是调试 HTTP API 的裸终端，可以直接输入exec、async_exec等 action 观察原始请求/响应，方便排查 HTTP API 本身的问题。该页面已自动完成init_session，进入即可联调；
• terminal：提供入口直接跳转到基于 WebSocket 的原版 Web 终端（/index.html），适合仍习惯 CLI 交互的用户。

七、前端架构与 HTTP API 调用机制

1. 请求对象与三类动作

在 fetch.ts 中，所有请求统一构造为对/api的 POST 请求，body 形如：

{ "action": "exec", "command": "thread --all -i 200", "sessionId": "...", "consumerId": "...", "requestId": "..." }

结合 perRequestMachine.ts 中的守卫逻辑，请求动作被分为三类路由：

2. xstate 状态机驱动请求生命周期

请求不是简单地fetch，而是由 perRequestMachine.ts 这个xstate 状态机管理完整生命周期：idle → ready → objVal → (common | session | asyncReq) → success / failure。状态机负责三件事：

• 请求构造：根据输入（字符串命令或对象）判断应走同步、异步还是会话路径，并由fetchStore.getRequest()生成 Request 对象；
• 结果校验：cmdSucceeded守卫会检查响应state是否为SCHEDULED / SUCCEEDED、results中statusCode是否为 0、options修改结果的afterValue是否与命令一致（因为 Arthas 本身对options不抛错，前端需手动比对判错）；
• 错误展示：失败时通过publicStore弹出错误对话框（isErr + ErrMessage）。

3. 轮询循环与 session 保活

fetch.ts 实现了三类轮询循环：

• pullResultsLoop：轮询pull_results，默认间隔 1000ms，可被 interrupt 按钮全局打断；
• keepaliveSession：session 初始化后每60 秒自动执行一次pull_results维持会话活性（HTTP 消费者默认 5 分钟超时，避免因超时导致 session 失效）；
• nullLoop：空闲占位。

轮询循环有严格的使用约束——当使用pull_results轮询时，不要同时执行其他命令（例如sc class），否则可能污染轮询结果队列。这是 README 中明确标注的注意事项，也是baseSubmit在jobRunning为 true 时直接拒绝新请求的原因。

八、本地开发与构建

1. 技术栈与开发建议

• 前端技术栈：TypeScript + Vue 3 + TailwindCSS + daisyUI + xstate（详见 package.json），图表基于 ECharts，终端基于 xterm；
• 强烈推荐使用 VSCode 开发，并安装xstate 插件：可以图形化查看每个请求的状态机流转（idle → ready → 请求 → success/failure），排查请求生命周期问题非常直观；
• 状态管理使用 Pinia（fetchStore控制请求与轮询，publicStore控制弹窗与全局提示）。

2. 构建与产物

package.json 定义了三种构建模式，对应 vite.config.ts 中的配置：

开发时通过vite.config.ts将/api代理到VITE_ARTHAS_PROXY_IP:VITE_ARTHAS_PROXY_PORT（环境变量配置），实现本地开发时直连 Arthas HTTP API。构建产物先输出到dist目录，再通过 ant 任务复制到../target/static，随 Web 模块一起部署。

3. 已知注意事项与演进方向

• pull_results使用期间避免并发执行其他命令；
• 旧的状态机consoleMachine.ts正逐步被perRequestMachine.ts完全取代（路由与视图均已切换），@xstate/vue的旧用法与相关依赖后续也会清理；
• README 中标注的下一步计划包括：为无法量化的数据（目前用表格展示）设计更贴合的可视化方案，以及重构当前较松散的前端代码组织。

九、总结

Arthas Web Console 将 Arthas 强大的命令诊断能力封装为一套可视化、可交互、可轮询的浏览器界面：即时命令随发随回，异步命令以长轮询驱动图表实时刷新，session 生命周期由状态机与保活循环自动管理。对于希望以图形化方式使用 Arthas 的运维与开发者，直接访问/ui/index.html即可上手；对于希望二次开发的同学，web-ui/arthasWebConsole下按「视图（views）— 状态机（machines）— 请求仓库（stores）」分层的代码结构，配合 xstate 可视化调试，是理解整个 HTTP API 交互机制的绝佳样本。

【免费下载链接】arthasAlibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas项目地址: https://gitcode.com/gh_mirrors/ar/arthas