SSH

上一篇我已经把核心结论讲清楚了： 远端 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 对外暴露工具接口。 ...