OpenResty XRay 是 OpenResty Inc. 推出的动态追踪诊断产品，用来分析正在运行的应用，找出性能问题、行为异常和安全漏洞。它不修改目标进程的代码，也不注入任何东西，靠采样把 CPU 时间、内存、磁盘 I/O 和网络延迟摊到具体的函数与代码行上。它主要跑在 Linux 服务器和容器环境里，不依赖桌面客户端。26.11.1 这个版本在 11 月初发布，改动大多集中在 AI 诊断的可核对性上，顺带把观察范围推进到了无服务器容器环境。

结论后面多了个「凭什么」

以前用 AI 助手读完一份诊断报告，最别扭的地方在于它给得很干脆，你却没处追问。报告说某个 worker 进程的 CPU 高，你想知道是 Lua 层还是 C 库，得自己回去翻火焰图；翻完再想问一句这个函数在另一个调用上下文里是不是同样表现，只能把图截下来贴给通用聊天工具，上下文全丢了。

26.11.1 把这条路打通了。控制台允许围绕同一份诊断发现继续提问，提问时会带上当时的进程和主机资源使用情况，所以追问不是重开一轮对话，而是在原有证据上往下挖。更实用的是从 AI 报告能直接跳到对应的火焰图调用路径，点过去看到的还是同一批采样数据，同一个函数在不同调用上下文里的表现可以对照着看。AI 回复和任务报告里还多了图表与建议追问，等于把下一步该看什么写在结论旁边。

它会自己写一个分析器

固定分析器覆盖不到的问题，这个版本交给 AI 现场补。诊断过程中如果现有工具量不到关键指标，系统会按需求自动编写并验证新的分析器，把这块空白填上。对使用者来说，省掉的是提需求等排期那一段。

另一处扩展落在部署形态上。26.11.1 首次把分析能力伸到 AWS ECS Fargate，不过官方把话说得很清楚：当前只支持部分手动发起的进程级分析，不是对 Fargate 应用的全面覆盖。打算在无服务器容器里排查问题的人，先确认自己的场景落在哪一档。

待机实例只解决有备份，没解决自动切

自主部署版这次能配置待机实例了，为维护和故障恢复留一套备用环境，已有的数据库配置会保留下来。听起来像高可用，实际边界卡在切换那一步：主备切换仍然要人工协调。运维该把它当成缩短恢复准备时间的工具，配套的切换流程和演练一样不能少。

开销低，才敢让它常驻

动态追踪工具能不能留在生产环境，从来不看功能表，看的是它自己吃掉多少资源。OpenResty XRay 的做法是按需采样，用户不发起分析时 Agent 不开工，开销为零；分析器跑起来也只做低频采样。官方公布的实测里，追踪 PHP 应用时最大吞吐量从 369 请求每秒掉到 355，降幅 3.7%，平均请求延时从 5.36 毫秒变成 5.58 毫秒，多了 0.22 毫秒。追 Rust 应用的请求延时增加 1.12 微秒，Python 应用在密集追踪模式下 CPU 只涨了约 1.5%，Go 应用在生产环境配置下 CPU 增加 1%。

这套东西由 OpenResty 开发的 Y 语言驱动，底下按环境对接 Stap+、eBPF+、GDB 和 ODB 等不同运行时。覆盖面铺得很开，LuaJIT、Python、PHP、Go、Java、Erlang、Perl、Ruby、Rust 都在支持范围内，Redis 这类数据库系统也能分析；系统层覆盖 Ubuntu、Debian、Fedora、RHEL、CentOS、openSUSE、AlmaLinux、Amazon Linux、Rocky Linux 等发行版，Docker 与 Kubernetes 里的应用可以跨容器边界观察。生产环境常常没有调试符号，它用机器学习算法重建符号，被 Strip 过的二进制同样能分析。

版本号背后是一次立场调整

26.11.1 还顺带修了一批稳定性问题。汇总报告的刷新和重新生成更快，刷新失败时上一份可用报告仍然保留；录制回放分析在停止、重试、恢复时不容易中断；「全部运行」之后部分工具没有重新执行的问题被修掉了；历史 CPU、内存、磁盘指标的存储占用降低，而保留期和刷新频率不变；资源指标读取更准，便于拿它对照 AI 给出的判断。自主部署版的安装、升级和镜像构建可靠性也提升了，由证书校验、镜像下载和长时间构建导致的失败少了一些。

官方对 26.11.1 的定位写得很直白：本版本让 AI 诊断不止于给出结论，结论可以继续追问，也可以回到火焰图和资源数据中逐一核对。

把这些改动放在一起看，方向很清楚。AI 给结论这件事已经不稀奇，难的是让人敢按结论动手。让结论可以追问、可以回到火焰图核对、可以交给它自己补分析器去验证，本质上都是在补证据链。对天天守着线上服务的人来说，一个能被质疑的诊断结论，比一个听起来很确定的结论有用得多。