瞭解 OpenResty XRay 是如何做到幫助企業定位應用程式存在的問題以及最佳化其效率的。

瞭解更多 LIVE DEMO

在排查線上 Lua 應用（包括由 OpenResty 或 Nginx 執行的應用）時，檢查某些永續性 Lua 資料結構是一個常見需求。對於 Nginx 而言，它仍然使用 OpenResty 的核心元件，即 Lua Nginx 模組。這些 Lua 資料結構可能深深嵌入到一些已載入的 Lua 模組中，或透過 upvalues 被某些 Lua 函式引用等。傳統檢查此類 Lua 資料的方法是暴露特殊的 API，用於序列化和匯出相應的 Lua 資料。但是，透過 動態追蹤 技術在執行中的程序內部檢查 Lua 資料會更加靈活和高效。

OpenResty XRay 提供了一種與 Lua 相容的語言，稱為 YLua，支援編寫此類工具，以 100% 非侵入式的方式檢查執行中程序內的任何 Lua 資料。本教程演示了一個簡單的用例，即在執行中的 OpenResty 和 LuaJIT 應用中匯出所有已載入 Lua 模組的名稱。我們將在未來的教程中展示更多使用 YLua 的複雜用例。

透過 OpenResty XRay 快速檢視並解決您的問題

系統環境

在此我們以 Red Hat Enterprise Linux 8 系統為例。任何 OpenResty XRay 支援的 Linux 發行版都應同樣適用，如 Ubuntu、Debian、Fedora、Rocky、Alpine 等。

我們使用未經修改的開源 OpenResty 二進位制構建作為目標應用。您可以使用任何 OpenResty 或 Nginx 二進位制檔案，包括自行編譯的版本。您現有的伺服器安裝或程序無需特殊的構建選項、外掛或庫。這正是 動態追蹤 技術的優勢所在。它是真正非侵入式的。

我們還在同一系統上執行 OpenResty XRay 的 Agent 守護程序，並已 安裝和配置 了 openresty-xray-cli 包中的命令列工具。

已載入 Lua 模組的名稱

使用標準工具

在目標程序中轉儲已載入 Lua 模組的最簡單方法是使用標準 OpenResty XRay 工具 lj-loaded-modules。

使用 ps 命令找到我們要分析的 nginx 工作程序。在這裡是 1046。

$ ps aux | grep nginx
1 S root     1059    1  0  80   0 - 73941 -      15:03 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
5 S nobody   1046 1059  0  80   0 - 82123 -      15:03 ?        00:00:00 nginx: worker process

現在讓我們使用 openresty-xray-cli 包中的 orxray 命令列工具執行標準分析器 lj-dump-loaded-mods。-p 選項用於指定要分析的目標程序 ID（或 PID）。

# 4096 is the target process's PID
$ orxray analyzer run lj-loaded-modules -p 4096
Start tracing...
jit: table
math: table
coroutine: table
debug: table
...
Go to https://x5vrki.xray.openresty.com/targets/68/history/751715 for charts.

使用自定義 YLua 工具

標準工具在底層是用 YLua 語言實現的。讓我們看看如何使用 YLua 自己重新建立這個工具。我們知道，已載入的 Lua 模組總是快取在 LuaJIT 虛擬機器（和標準 Lua 5.1 直譯器的虛擬機器）的 package.loaded 中。鍵是模組名稱，而值是模組資料。現在我們可以建立一個新的 YLua 原始檔，命名為 my-dump-loaded-mods.ylua：

probe process.begin
    for k, v in pairs(package.loaded) do
        print(k, ": ", type(v))
    end
    exit()
end

這裡，probe 關鍵字為探測點 process.begin 定義了一個新的探測處理程式，該探測點在工具附加到目標程序時觸發1。然後，我們透過在 YLua 中迭代 package.loaded Lua 表來轉儲 Lua 模組，這與 Lua 的語法完全相同。在列印出模組名稱及其資料型別後，我們呼叫 exit() 來結束整個跟蹤過程。我們可以使用 openresty-xray-cli 包中的 run-ylua 命令列工具來執行這個 YLua 原始檔。

檢查 OpenResty 或 Nginx Lua 應用

使用 ps 命令找到我們想要分析的 nginx 工作程序。在這裡，它是 1046。

$ ps aux | grep nginx
1 S root     1059    1  0  80   0 - 73941 -      15:03 ?        00:00:00 nginx: master process /usr/local/openresty/nginx/sbin/nginx
5 S nobody   1046 1059  0  80   0 - 82123 -      15:03 ?        00:00:00 nginx: worker process

現在讓我們使用 openresty-xray-cli 包中的 run-ylua 命令列工具來執行之前的 YLua 原始檔。-p 選項用於指定要分析的目標程序 ID（或 PID）。

$ run-ylua -p 1046 my-dump-loaded-mods.ylua
Start tracing...
resty.core.uri: table
resty.core.exit: table
resty.core.base64: table
resty.core.request: table
resty.core.response: table
string: table
pgmoon: table
openresty_org.controller: table
ndk: table
table: table
resty.core.utils: table
resty.lrucache: table
table.new: function
debug: table
table.clear: function
...
package: table
math: table
resty.core.base: table
jit.opt: table
ngx: table
_G: table
resty.core.var: table
resty.core.worker: table
resty.core.regex: table
resty.core.shdict: table
resty.core.time: table
resty.core.hash: table

為了簡潔起見，我們省略了大部分輸出。我們可以透過將輸出管道傳遞給 wc -l 命令來檢視總數：

$ run-ylua -p 1046 my-dump-loaded-mods.ylua | wc -l
Start tracing...
38

大多數模組都是 table 型別。畢竟，Lua 模組通常是由 Lua 表來表示的。有幾個模組比較特殊，它們是 function 型別。例如，table.new 是一個由 LuaJIT 專門實現的函式型別模組。

  • io、os、string、table、math、debug 是 Lua 5.1 語言定義的標準 Lua 模組。
  • jit、bit、ffi、jit.opt、table.new、table.clear 是標準 LuaJIT 模組。
  • resty.*、coroutine、ndk、ngx 是 OpenResty 引入的模組。
立即嘗試 OpenResty XRay 分析您的執行中應用

檢查獨立的 LuaJIT 應用

我們還可以檢查不涉及 Nginx 或 OpenResty 的獨立 luajit 程序。

首先，像往常一樣找到 luajit 程序的 PID：

$ ps aux | grep luajit
root     3371845  0.0  0.0   4428  2524 pts/3    S    22:17   0:00 luajit t.lua

然後，我們使用這個 PID，3371845，來執行 run-ylua 命令：

$ orxray analyzer run lj-loaded-modules -p 3371845
Start tracing...
jit: table
math: table
coroutine: table
debug: table
os: table
_G: table
package: table
string: table
jit.opt: table
bit: table
io: table
table: table

正如我們所見，獨立的 luajit 程式通常預設載入的 Lua 模組要少得多。

我們可以透過將輸出管道傳遞給 wc -l 命令來檢視總數：

$ orxray analyzer run lj-loaded-modules -p 3371845 | wc -l
Start tracing...
12

直接在 Web 控制檯中執行

使用者可以選擇在 OpenResty XRay 的 Web 控制檯中直接執行本教程中涵蓋的任何工具。這些工具甚至可以在高 CPU 使用率等有趣事件發生時自動觸發。 來自 openresty-xray-cli 的命令列實用程式便於演示目的。它們也易於由 DevOps 和 SRE 人員自動化並整合到其他系統中。

追蹤容器內的應用

OpenResty XRay 工具支援透明地追蹤容器化應用。Docker 和 Kubernetes (K8s) 容器都可以透明地工作。與普通應用程序一樣，目標容器不需要任何應用或額外許可權。OpenResty XRay Agent 守護程序應該在目標容器外部執行（如直接在主機作業系統中或在其自己的特權容器中）。

讓我們看一個例子。我們首先使用 docker ps 命令檢查容器名稱或容器 ID。

$ docker ps
CONTAINER ID   IMAGE                                       COMMAND                  CREATED         STATUS         PORTS     NAMES
4465297209d9   openresty/openresty:1.19.3.1-2-alpine-fat   "/usr/local/openrest…"   18 months ago   Up 3 minutes             angry_mclaren

這裡容器名稱是 angry_mclaren。然後我們可以找出此容器中目標程序的 PID。

$ docker top angry_mclaren
UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                3373047             3373026             0                   22:23               ?                   00:00:00            nginx: master process /usr/local/openresty/bin/openresty -g daemon off;
nobody              3373101             3373047             0                   22:23               ?                   00:00:00            nginx: worker process

openresty 工作程序的 PID 是 3373101。然後我們像往常一樣針對這個 PID 執行 OpenResty XRay 分析器。

$ orxray analyzer run lj-loaded-modules -p 3373101
Start tracing...
table: table
ngx: table
resty.core.var: table
table.new: function
resty.core.regex: table
resty.core.shdict: table
resty.core.time: table
...
table.clear: function
resty.core.worker: table
resty.lrucache: table
io: table

OpenResty XRay 還能夠自動檢測長時間執行的程序，並將其識別為特定型別的"應用"（如 “OpenResty”、“Python” 等）。

工具的實現方式

所有工具都是使用 Y 語言 實現的。OpenResty XRay 透過 Stap+2 或 eBPF3 後端執行這些工具，這兩種後端都使用了 100% 非侵入式的動態追蹤技術，基於 Linux 核心的 uprobes 和 kprobes 功能。YLua 指令碼首先被編譯成 Y 語言，然後進一步編譯成可執行的動態追蹤工具。

我們不需要目標應用和程序的任何配合。我們不使用也不需要任何日誌資料或指標資料。我們直接以嚴格的只讀方式分析執行中程序的程序空間。而且，我們絕不會向目標程序注入任何位元組碼或其他可執行程式碼。這是 100% 乾淨和安全的。

工具的開銷

本教程中演示的動態追蹤工具非常高效，適合線上執行。

當工具未執行且未主動取樣時，對系統和目標程序的開銷嚴格為零。我們從不向目標應用和程序注入任何額外的程式碼或外掛；因此，不存在固有的開銷。

在取樣期間，對於本教程中涉及的工具，平均請求延遲和吞吐量的開銷通常是不可測量的。這裡的工具只進行一次性檢查。

立即免費試用 OpenResty XRay

關於作者

章亦春是開源 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. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號：

我們的微信公眾號

翻譯

我們提供了英文版原文和中譯版（本文）。我們也歡迎讀者提供其他語言的翻譯版本，只要是全文翻譯不帶省略，我們都將會考慮採用，非常感謝！

  1. 請注意，這與透過 ptrace() 系統呼叫進行附加（如在 GDB 中）有很大不同。這裡是 動態跟蹤 附加，它更安全、更快速。 ↩︎

  2. Stap+ 是 OpenResty Inc 對 SystemTap 的大幅增強版本。 ↩︎

  3. 這實際上是 OpenResty Inc 大幅增強的 eBPF 實現，稱為 ORBPF。 ↩︎