Java

传统的 Java 压测诊断流程通常是这样的：打开监控大盘、发现异常、SSH 进跳板机、kubectl exec 进 Pod、attach Arthas、手工敲命令、拼结论。这个流程的问题不是步骤多，而是每一步都依赖人工，压测窗口很短，诊断常常跟不上问题出现的节奏。 Arthas MCP 把这件事往前推了一步——让 AI Agent 可以直接调用 Arthas 的诊断工具，把"人工执行诊断命令"这件事自动化掉。 但在远端 K8s 场景下，开始动手才会发现：真正的挑战不在 MCP 的几个参数配置，而在于如何构建一条从本地 Agent 穿透到 Pod 内部的安全链路。 本文的答案是：把链路复杂度封装在连接层，让 Agent 始终看到一个稳定的 localhost 地址。 远端 K8s 的核心障碍 在本地环境里，Arthas MCP 的接入几乎没有门槛——启动 Arthas、指定 httpPort 和 mcpEndpoint，Agent 直接连。 但在远端 K8s 里，有三件事会让这条路走不通： 网络隔离：Pod 处于 K8s 内网，本地无法直接访问 Pod IP。 安全边界：把 Arthas HTTP 端口通过 LoadBalancer 或公网 Ingress 暴露出来，等于把高权限诊断入口开放给外部，风险极高。 动态性：Pod 名称和 IP 随时可能变化，Agent 侧配置无法写死。 所以问题的本质是：如何用一套对 K8s 改动最小、安全边界清晰的方式，把 Pod 内部的 Arthas MCP 端口安全地带到本地。 ...

上一篇我已经把核心结论讲清楚了： 远端 K8s 里的 Arthas MCP，不应该直接暴露给本地 Agent，而应该通过 SSH + kubectl port-forward，在本地制造一个安全、稳定、看起来像本地的 MCP 地址。 但光有这个结论还不够。 因为只要你真的开始用，就会立刻遇到一堆工程层问题： 每次都手工敲一堆命令，太容易出错 Pod 名称会变 压测前要快速切换实例 链路断了之后，很难判断是 SSH 问题、kubectl 问题，还是 Arthas 根本没起来 本地 Agent 需要的不只是“知道原理”，而是一个稳定可复用的本地 MCP 地址 所以这一篇不再讲抽象架构，而是专注一件事： 如何把本地 Agent → 远端 K8s Pod 内 Arthas MCP 的接入流程，做成一键脚本，并真正用于压测实战。 本文配套脚本： ~/.openclaw/workspace/scripts/connect-arthas-mcp.sh 一、脚本到底解决了什么问题 先看没有脚本时，你通常要做哪些事。 手工方式 登录远端 master / bastion 找到目标 namespace 和 Pod 执行 kubectl port-forward pod/<pod> 8563:8563 在本地再执行 ssh -L 18563:127.0.0.1:8563 user@host 手工 curl 检查 /mcp 再复制一段 MCP 配置到本地客户端 这套流程最大的问题不是“步骤多”，而是： ...

Arthas 最近放出了 MCP Server 能力。这个变化的意义，不只是“Arthas 多了一个新入口”，而是： Java 诊断能力，第一次可以被本地 Agent 以标准工具协议直接调用。 以前我们做性能测试，常见流程是这样的： 压测工具把流量打上去 我们盯着监控看 CPU、RT、GC 发现异常后，再 SSH 到机器里 attach Arthas 手工跑 thread、dashboard、trace、watch 最后把零散信息拼成结论 这个流程不是不能用，但它有两个问题： 慢：压测窗口很短，手工分析经常跟不上问题出现的节奏 碎：数据、判断和命令是割裂的，很难形成可复用流程 Arthas MCP 把这件事往前推进了一步：AI Agent 可以直接把 Arthas 当工具调用。 于是问题就变成了： 如果我的 Java 服务跑在远端 K8s 集群里，本地 Agent 怎么安全地连上远端 Arthas MCP，并在压测时参与分析？ 这篇文章我想把这件事讲透，重点回答四个问题： Arthas MCP 到底解决了什么问题 远端 K8s 场景下，链路应该怎么设计 最推荐的接入方式是什么 我如何把这件事做成一键脚本，并真正用于压测分析 一、Arthas MCP 到底是什么 根据 Arthas 官方文档，Arthas MCP Server 是 Arthas 的实验性模块，实现了基于 MCP（Model Context Protocol） 的服务端能力，通过 HTTP / Netty + JSON-RPC 2.0 对外暴露工具接口。 ...