OpenResty XRay の試用をすぐに申請する

Nginx や OpenResty のバイナリが strip されると、GDB の backtrace では No symbol table info available が表示され、フレームグラフは役に立たない Unknown フレームで埋まります。一般的な対処法——nginx-dbg デバッグシンボルパッケージのインストールや -g フラグでの再コンパイル——は常に可能とは限りません。OpenResty XRay は、strip されたバイナリから機械学習で欠落したデバッグシンボルを自動的に再構築し、C 関数と Lua 関数の名前・ソースファイル・ソースコード行番号を復元します。これはクラッシュ発生後に特に重要です。strip された worker プロセスが core dump を書き出した後では、遡ってシンボルを追加することはできません。しかし再構築されたシンボルがあれば、OpenResty XRay はその core dump ファイルを自動的に分析し、C と Lua の完全なバックトレースを解決できます。

以下では、デバッグシンボルを一切インストールせずに、strip された OpenResty プロセスを CPU フレームグラフと Lua メモリ使用量まで含めてエンドツーエンドで分析する手順を解説します。また、core dump だけでは説明できない難解なクラッシュに対しては、再構築したシンボルは記録とリプレイで Nginx worker のクラッシュを「第一の現場」で捉えるといった、より深いフォレンジックにも活用されます。

Nginx が strip され、デバッグシンボルが欠落していることの確認

ps コマンドを実行して対象プロセスを確認し、実行可能ファイルのパスを把握します（本例の OpenResty はユーザーがソースコードからコンパイルしたものです）。

ps でプロセスと実行ファイルのパスを確認

メインの実行可能ファイルに対して file コマンドを実行します。ファイルが strip されており、デバッグシンボルやシンボルテーブルが一切ないことがわかります。また、このプログラムに対応するデバッグシンボルのインストールパッケージも見つかりません。

メイン実行ファイルの file 出力（strip 済み）

プロセスが読み込んでいる LuaJIT の動的リンクライブラリに対しても同様に file を実行します。ここでも、LuaJIT ファイルのデバッグシンボルが欠落していることがわかります。

LuaJIT ライブラリの file 出力

欠落した Nginx デバッグシンボルを自動再構築——再コンパイル不要

ブラウザで OpenResty XRay の Web コンソールを開き、Guided Analysis に進み、ウィザードに従って分析する問題の種類、対象アプリケーション、worker プロセスを選びます。言語レベルでは Lua と C/C++ の両方を選択したまま分析を開始してください。以下は Guided Analysis の画面です（オプションの組み合わせの詳細は冒頭の動画を参照してください）。

Guided Analysis ウィザード

分析が始まると、OpenResty XRay は実行可能ファイルにデバッグシンボルが欠落しているかどうかを確認し、シンボルの自動再構築を試みます。再構築が成功すると、通常どおり関連するすべてのアナライザーを並列に実行します。

シンボル再構築タスクの実行中

分析を停止すると、コンソールに統合された分析レポートが生成されます。以下では、CPU とメモリの読み方に絞って説明します。

分析後のレポート画面

再構築したシンボルによる CPU フレームグラフ：Lua ホットパスと C ソース行

レポートの CPU 部分では、まず Lua のパフォーマンスホットスポットを確認し、関連する C 言語レベルの CPU フレームグラフから関数名を追います。シンボルが再構築されていれば、フレームグラフは C ソースファイル名と行番号まで表示できます。このホットコードパスは、C 言語レベルの CPU フレームグラフから自動的に導き出されたものです。

Lua のパフォーマンスホットスポット

フレームグラフ上の C ソースファイル名と行番号

これは CPU 時間を最も多く占める Lua コードパスです。close 関数が generate 関数から呼び出されています。generate は Lua 関数で、Lua ソースファイル lua/report.lua で定義されています。lua/invoice.lua ファイルで定義された generate_monthly_report が、先ほどの generate 関数を呼び出しています。

Lua のホットコードパスとソースの対応

この generate 関数の緑色のボックスにマウスを合わせます。ツールチップに Lua ソースファイルの完全なパスが表示されます。Lua ソースコードの行番号は 11 です。

ツールチップに表示される Lua ソースのフルパス

OpenResty XRay の提案に従って 11 行目にジャンプします。レポートで見た close 関数をソース上でも確認できます。デバッグシンボルがなくても、ホットスポットとなっている Lua 関数とソースコード行の詳細情報を取得できています。

レポートの行番号に対応するソース

generate 関数はデータベースのクエリとレポートの生成に使用されています。

generate の Lua ソース

メモリ：Lua GC オブジェクト参照パス

Lua 言語レベルの GC オブジェクト参照パスでは、メモリの大部分が LuaJIT ガベージコレクタによってまだ解放されていない死亡 Lua オブジェクトに占有されています。

Lua の GC オブジェクト参照パス

registry -> ._LOADED などのパスを拡大すると、このデータ参照パスの下で、table は現在の Lua アプリケーションで読み込まれているすべての Lua モジュールのデータ構造です。明らかに、これらの読み込まれた Lua モジュールも多くのメモリを占有しています。

拡大した GC 参照パス

参照パス上の読み込み済み Lua モジュール

OpenResty XRay でアプリケーションの性能を向上させる

継続的な分析：日次・週次の Insights レポート

単発の Guided Analysis に加え、OpenResty XRay はオンラインプロセスに対して継続的なインサイトも生成できます。Insights に切り替えると、日次および週次の自動レポートを確認でき、長期の観測に向いています。インタラクティブなウィザードは開発やデモ用途に適しています。

Insights の周期レポート

よくある質問

Nginx の「No debugging symbols found」とはどういう意味ですか？

Nginx や OpenResty のバイナリが strip されているか、-g フラグなしでビルドされ、シンボルテーブルが失われていることを意味します。この状態で GDB の backtrace を実行すると No symbol table info available と表示され、プロファイラは関数を Unknown と表示します。シンボルがないと、機械語アドレスを C や Lua の関数名・ソースファイル・ソースコード行番号へ対応付けられません。

デバッグシンボルを得るには nginx-dbg のインストールや Nginx の再コンパイルが必須ですか？

一般的には、対応する nginx-dbg デバッグシンボルパッケージをインストールするか、-g フラグで再コンパイルします。しかし、ビルドに対応する dbg パッケージが存在しない場合や、稼働中のバイナリを再コンパイルできない場合、これらの方法は使えません。OpenResty XRay はどちらも不要です。strip されたバイナリから欠落したデバッグシンボルを自動的に再構築します。

デバッグシンボルなしで strip された Nginx / OpenResty バイナリを分析できますか？

はい。OpenResty XRay はまず欠落したシンボルを再構築してから各アナライザーを実行するため、strip されたバイナリでも CPU フレームグラフやメモリレポートを生成し、実際の C・Lua 関数名やソースファイル・ソース行まで解決できます。まるで最初からシンボルがあったかのようにです。

OpenResty XRay はどのようにして欠落したデバッグシンボルを再構築しますか？

分析を開始すると、OpenResty XRay はシンボルが欠落している実行可能ファイルを検出し、機械学習を用いて strip されたバイナリからシンボルを再構築するタスクを自動的に開始します。再構築が完了すると、関連するすべてのアナライザーを並列に実行し、C と Lua の関数をそれぞれのソースファイルと行に対応付けます。

OpenResty XRay について

「Insights」ページに切り替えてください。「Insights」ページでは、日次および週次のレポートを確認することができます。

OpenResty XRay の試用をすぐに申請する

著者について

章亦春（Zhang Yichun）は、オープンソースの OpenResty® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省生まれで、現在は米国ベイエリアに在住しています。中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」「動的トレーシング」「機械プログラミング」の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っています。世界中で 4000 万以上のドメイン名に採用されているオープンソースプロジェクト OpenResty® のプロジェクトリーダーとして広く知られています。

2017 年に章亦春が創業した OpenResty Inc. は、世界有数の規模を持つ企業を顧客に抱えるエンタープライズソフトウェアのスタートアップです。同社のフラッグシップ製品である OpenResty XRay は、動的トレーシング技術を強化して活用する、非侵襲的なプロファイリングおよびトラブルシューティングツールです。また OpenResty Edge は、強力な分散トラフィック管理およびプライベート CDN 向けのソフトウェア製品です。

熱心なオープンソース貢献者として、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、多数のオープンソースプロジェクトに累計 100 万行超のコードを寄与し、60 を超えるオープンソースソフトウェアライブラリを執筆しています。

フォローする

本記事が参考になった場合は、OpenResty Inc. のブログをフォローしてください。WeChat の公式アカウントもご利用いただけます。

章亦春（GitHub ID: agentzh）は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」 の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay（動的トレーシング技術を利用した非侵襲的な障害分析および排除ツール）と OpenResty Edge（マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア）は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

英語版の原文と日本語訳版（本文）をご用意しております。読者の皆様による他の言語への翻訳版も歓迎いたします。全文翻訳で省略がなければ、採用を検討させていただきます。心より感謝申し上げます！