分析缺失调试符号的 OpenResty/Nginx 应用(使用 OpenResty XRay)
本教程中,我们将展示如何自动分析没有调试符号的 OpenResty 和 Nginx 应用。即使在所有调试信息缺失的情况下,它也能通过机器学习算法自动对可执行文件进行分析,重建调试符号,并通过动态追踪进行深入和全面的分析。OpenResty XRay 拥有从被 strip 过的可执行文件中生成调试符号的超能力,因此即使缺失调试符号,也能获得 C 函数和 Lua 函数的源文件、源码行相关信息。
问题:应用缺失调试符号
我们将展示 OpenResty XRay 如何在 OpenResty 或 Nginx 应用中,自动分析没有调试符号的程序。它可以通过机器学习算法分析可执行文件,重建调试符号。
让我们运行 ps
命令来查看一个 OpenResty 或 Nginx 进程的更多细节。
可以看到该进程可执行文件的路径。这个 OpenResty 是用户自己用源代码编译的。
使用 file
命令检查该可执行文件。复制这个文件路径。
可以看到,文件已经被 strip 过,没有任何调试符号或符号表。也找不到该程序对应的调试符号安装包。
再用 file
命令检查 LuaJIT 动态链接库。
我们再次看到,LuaJIT 文件的调试符号也是缺失的。
自动分析与重建调试符号
多亏了 OpenResty XRay 拥有从这样的可执行文件中生成调试符号的超能力,我们才能通过动态追踪进行深入和全面的分析。
在浏览器中打开 OpenResty XRay 的 Web 控制台。
进入 “Guided Analysis” 页面。
这里可以看到系统能分析的不同类型的问题。
选择这四种类型的问题。
点击 “Next”。
选择之前的 OpenResty 应用。
选择 worker
进程。
OpenResty XRay 可以同时分析多种语言级别。这里保持 Lua 和 C/C++ 都选中的状态。
开始分析。
OpenResty XRay 会先检查是否有可执行文件缺少调试符号,然后尝试自动重建。符号重建任务正在运行。
符号重建成功后,它会像往常一样开始运行所有相关的分析器。
停止分析。
可以看到已经自动生成了一份分析报告。
报告的第一部分是 CPU 问题类型。
首先,查看 Lua 的性能热点。
点击查看更多。
这条热代码路径是从这个 C 语言级别的 CPU 火焰图自动推导出来的。
点击放大火焰图。
我们可以看到所有 C 函数名称,包括内联函数。
它甚至显示了 C 源文件的名称。
还有源代码行号!这很神奇,不是吗?
点击查看更多详情。
这是占用 CPU 时间最多的 Lua 代码路径。
close
函数被 generate
函数调用。
generate
是一个 Lua 函数,被定义在 Lua 源文件 lua/report.lua
中。
lua/invoice.lua
文件中定义的 generate_monthly_report
调用了前面那个 generate
函数。
将鼠标悬停在这个 generate
函数的绿框上。在提示框中可以看到其 Lua 源文件的完整路径。
Lua 源代码行号为 11。
复制它的源文件路径。
使用 Vim 编辑器打开它的源文件。查看里面的 Lua 代码。您可以使用任何您喜欢的编辑器。
按照 OpenResty XRay 的建议,跳转到第 11 行。您可以在报告中看到 close
函数。即使没有调试符号,我们仍然可以获得热点 Lua 函数和源代码行的详细信息。
generate
函数用于查询数据库和生成报告。
让我们看看报告中关于内存的分析部分。
在 Lua 语言级别的 GC 对象引用路径中,很大一部分的内存被 LuaJIT 垃圾收集器尚未释放的死亡 Lua 对象占用。
点击放大它。
放大这条 registry -> ._LOADED
的数据引用路径。
在这条数据引用路径下,table
是当前 Lua 应用已加载的所有 Lua 模块的数据结构。显然,这些加载的 Lua 模块也占了很多的内存。
全自动分析与报告
OpenResty XRay 也可以自动监控在线进程,并显示分析报告。
切换到 “Insights” 页面。您可以在 “Insights” 页面中找到以日和周为周期的报告。所以您不是非得用 “Guided Analysis” 功能。
当然,“Guided Analysis” 对于应用的开发和演示是很有用的。
如果您喜欢这个教程,请订阅这个博客网站和我们的 YouTube 频道 或 B 站频道。谢谢!
关于 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. 公司的博客网站 。也欢迎扫码关注我们的微信公众号:
翻译
我们提供了英文版原文和中译版(本文)。我们也欢迎读者提供其他语言的翻译版本,只要是全文翻译不带省略,我们都将会考虑采用,非常感谢!