OpenResty XRay AI 助手:讓每一份分析資料都能開口說話
OpenResty XRay AI 助手是內建在 OpenResty XRay 控制檯中的 AI 解讀引擎:它直接讀取動態追蹤採集的真實執行時資料,自動解讀火焰圖、取樣結果和分析報告,並給出結論與下一步行動建議。 目前處於 Beta 階段,向所有使用者開放。
讀懂一份火焰圖需要經驗,把它解釋給別人聽需要時間。在很多團隊裡,能看懂 OpenResty XRay 分析報告的往往只有一兩個人。線上 CPU 飆高,報告五分鐘就出來了,但"報告說明了甚麼、接下來該做甚麼",還是要等那位最資深的工程師有空。
AI 助手就是為了消滅這個瓶頸而生的。它直接站在 OpenResty XRay 採集到的真實執行時資料之上,把火焰圖、取樣結果、分析報告翻譯成結論和行動建議——讓團隊裡的每個人都能獨立完成一次專業級的效能診斷。
Beta 早期訪問:AI 助手目前處於 Beta 階段,向所有使用者開放。這個階段您的每一條反饋都會直接影響功能的演進方向——我們希望和最早的一批深度使用者一起,把它打磨成真正趁手的工具。
它和"把報告貼進 ChatGPT"有甚麼區別?
通用聊天機器人只能看到您貼上給它的文字。而 OpenResty XRay AI 助手:
- 直接訪問分析資料。它讀取的是 OpenResty XRay 透過非侵入式動態追蹤採集的真實執行時資料——不是日誌摘要,不是您手動整理的描述,而是取樣級的原始事實。
- 自動感知上下文。您正在看哪臺目標機器、哪個應用、哪份報告,它都知道。不需要複製貼上,不需要向它解釋背景。
- 理解 OpenResty XRay 的分析器體系。它知道每個分析器測量的是甚麼、指標之間的因果關係,以及 OpenResty/Nginx 內部機制的含義。
換句話說:通用 AI 是一個沒到過現場的顧問,OpenResty XRay AI 助手是一個一直站在機房裡的同事。
三個典型場景
場景一:線上突發問題,邊看頁面邊問
凌晨兩點,某個應用 CPU 突然打滿。您開啟目標機器頁面,OpenResty XRay 已經自動完成了取樣分析。
點選頁面右下角的 AI 助手彈窗——它會自動帶上當前頁面的完整上下文,直接開問就行。下面是我們在一臺演示機器上覆現了一次典型 CPU 事故之後,和 AI 助手的真實對話。
第一問:「這臺機器過去一小時 CPU 使用率異常的主要來源是甚麼?」
AI 助手直接給出定位,每一條結論都來自取樣資料:
- 主要來源是
nginx: worker process(PID 15485),該程序在後段多次達到 98% CPU,是過去一小時最顯著的持續高佔用程序; - 系統級峰值同時表現為 system CPU 49%、iowait 20%——說明這個 worker 的負載伴隨較多核心態處理或 I/O 等待,而不只是純使用者態計算;
- 它還主動排除了干擾項:
or-saas觸發的短時輔助程序雖然也曾佔到 33%–67%,但持續性和峰值均低於 PID 15485,屬於次要因素。
接著追問最佳化建議。AI 助手沒有甩出一份泛泛的調優清單,而是先糾正了方向:該 worker 持續約 98% CPU,但主機仍有約 64% 空閒——問題集中在單個 worker 上,不建議直接擴容整機或盲目調引數,應該先定位這個 worker 的實際熱呼叫鏈。然後給出一條可執行的診斷路徑:
- 優先採集
lj-lua-on-cpu,確認是否為 Lua 業務程式碼熱點;若火焰圖頂部是 Lua 函式,再針對該函式減少重複計算、避免每請求重複解析/序列化,並快取可安全複用的結果; - 若 Lua 佔比不高,再採集
lj-c-on-cpu或c-on-cpu,定位 LuaJIT 或 Nginx/原生庫層面的 CPU 消耗。
而這臺機器的實際"病灶"正是如此:log 階段掛了一段把完整請求/響應上下文序列化成 JSON 的審計日誌程式碼,Lua-Land CPU 火焰圖上 cjson 的編碼呼叫清晰可見——AI 建議的第一步診斷動作正好直指根因。
整個過程不用離開當前頁面,不用複製任何資料,答案就在排障現場。彈窗中的對話會自動儲存,事後可以在 AI 助手頁面繼續追問或分享給同事。
場景二:覆盤例行報告,兩分鐘掌握全域性
OpenResty XRay 會持續為目標機器生成分析報告。逐條閱讀所有條目很花時間,尤其當您管理著幾十臺機器時。
在報告 Insights 頁面新增的「報告解讀」標籤頁裡,AI 會替您先讀一遍:
- 用一段話概括這臺機器的整體健康狀況;
- 從幾十條報告條目中挑出真正值得關注的兩三個問題;
- 指出問題之間的關聯——比如記憶體增長和某個 Lua 模組行為的關係。
您可以把它當成每天早上的"值班交接摘要":先看解讀掌握全域性,有疑點再下鑽到原始條目。
場景三:深挖單次分析任務
對於某一次具體的取樣分析(Job),在 History 頁面點開任意一個分析任務,再切到右上方的 AI 分析 標籤頁即可。它針對這一次任務的結果回答三個問題:
- 發現了甚麼——這次取樣捕捉到的核心事實;
- 意味著甚麼——火焰圖、呼叫路徑、取樣分佈反映的具體問題;
- 接下來做甚麼——可能的原因排序,以及建議的下一步分析動作(比如"建議對該程序再跑一次 off-CPU 分析確認鎖競爭")。
這對團隊裡的新人尤其有價值:過去需要老工程師帶著看的分析結果,現在自帶一份專家解說。
AI 助手頁面:您的效能診斷工作臺
除了嵌在各處的入口,AI 助手還有一個獨立頁面,從控制檯右上角的 AI 助手圖示進入。適合不依附於特定頁面的開放式諮詢和長對話。
頁面左側是會話歷史,右側是聊天區域。所有入口(包括彈窗)產生的對話都彙總在這裡,隨時可以接著聊。會話列表還支援檢視 Beta 配額用量、複製會話 ID(反饋問題時用它精確定位)、把整段排障過程一鍵分享給同事等操作。
換個方向:讓你自己的 AI Agent 用上 OpenResty XRay
前面講的都是"到 OpenResty XRay 控制檯裡用 AI 助手"。反過來也成立:AI Agent 現在可以透過 MCP 連線到 OpenResty XRay,並可安裝 AI 助手 skill 以獲得更智慧的診斷。
這意味著 Claude Code、Codex、Cursor 以及其他相容 MCP 的客戶端,都能直接驅動 OpenResty XRay 跑分析器、讀取診斷資料——效能診斷不必再切換到獨立的 OpenResty XRay 控制檯,而是融進你現有的開發和排障工作流裡。你在 IDE 或終端里正查一個線上問題,同一個 Agent 就能順手拉起一次動態追蹤、把火焰圖讀回來、給出結論,上下文不用來回搬。
入口在控制檯裡的「MCP 伺服器與 Agent Skill」彈窗,提供兩種配合使用的接入方式。
方式一:連線 MCP 伺服器
在「MCP 伺服器」標籤頁裡,你會看到本賬號專屬的 MCP server 地址、API-Token 請求頭的身份驗證說明,以及以 Claude Code 為例、可直接加進 ~/.claude.json 的配置示例。照著填好令牌,你的 Agent 就能連上 OpenResty XRay 伺服器,執行分析器並讀取診斷資訊。
方式二:安裝 AI 助手 Skill
連上 MCP 之後,再裝上 AI 助手 Skill,可以讓 Claude Code 等 Agent 獲得更智慧的診斷。「Agent Skill」標籤頁裡提供了 Skill 包的下載按鈕和安裝示例,跟著操作即可。
常見問題
AI 真的能讀懂火焰圖嗎?
能,而且這正是它最擅長的場景。火焰圖的每一個棧幀都是結構化的取樣資料,OpenResty XRay AI 助手理解每個分析器測量的指標含義與 OpenResty/Nginx 內部機制,因此它對火焰圖的解讀不是"看圖說話",而是基於原始取樣資料的分析——寬的橫條意味著甚麼、哪條呼叫路徑值得追、下一步該跑哪個分析器,它會直接告訴您。
AI 的解讀可靠嗎?
AI 助手的解讀均以 OpenResty XRay 實際採集的執行時資料為依據,並會在回答中標註引用的資料來源,方便您核對。不過它基於大語言模型構建,仍可能出現誤讀資料或推斷不當的情況——因果分析和最佳化建議應當作有依據的假設,而非最終結論。涉及重要的線上變更時,請回到原始火焰圖和報告條目做最終確認。Beta 階段解讀質量在持續迭代中,遇到不準確的回答,歡迎附上會話 ID 反饋給我們。
在哪些頁面可以使用它?
四個入口:任意頁面右下角的 AI 助手彈窗(自動攜帶當前頁面上下文)、報告 Insights 頁的「報告解讀」標籤頁、單次分析任務詳情頁的 AI 解讀,以及控制檯右上角進入的獨立 AI 助手頁面。所有入口產生的對話都彙總在獨立頁面中。
立即開始
如果您已經是 OpenResty XRay 使用者,最快的上手方式不超過兩分鐘:開啟 OpenResty XRay 控制檯,進入任意一臺目標機器的報告頁面,點選右下角的 AI 助手彈窗,問一句「這臺機器目前最值得關注的問題是甚麼?」——看看它的回答,和您自己的判斷對比一下。
如果您還沒有開始使用 OpenResty XRay,可以先申請試用,把它接到您自己的生產環境上,讓 AI 助手直接站在您真實的執行時資料之上給出診斷:
Beta 期間我們特別想聽到:哪類問題它答得好、哪類答得差、您希望它接入哪些還沒覆蓋的資料。反饋時附上會話 ID(會話列表頂部可複製),或直接聯絡您的技術支援對接人。
您今天的每一條反饋,都在定義這個工具明天的樣子。
關於 OpenResty XRay
OpenResty XRay 是一款動態追蹤產品,它可以自動分析執行中的應用,以解決效能問題、行為問題和安全漏洞,並提供可行的建議。在底層實現上,OpenResty XRay 由我們的 Y 語言驅動,可以在不同環境下支援多種不同的執行時,如 Stap+、eBPF+、GDB 和 ODB。
關於作者
章亦春是開源 OpenResty® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。
章亦春(Github ID: agentzh),生於中國江蘇,現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物,曾供職於多家國際知名的高科技企業,如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅,擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay(利用動態追蹤技術的非侵入式的故障剖析和排除工具)和 OpenResty Edge(最適合微服務和分散式流量的全能型閘道器軟體),廣受全球眾多上市及大型企業青睞。在 OpenResty 以外,章亦春為多個開源專案貢獻了累計超過百萬行程式碼,其中包括,Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等,並編寫過 60 多個開源軟體庫。
關注我們
如果您喜歡本文,歡迎關注我們 OpenResty Inc. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號:
翻譯
我們提供了英文版原文和中譯版(本文)。我們也歡迎讀者提供其他語言的翻譯版本,只要是全文翻譯不帶省略,我們都將會考慮採用,非常感謝!



























