コードの一部で完全な呼び出しチェーンを確認できない場合、完全な呼び出しチェーン全体を明確にクエリするのに役立つツールが必要ですか?今回はエディターが PHP の Deliverer について学習するため、コードのトラブルシューティングについて心配する必要はなくなります。
数日前、グループの友人が先祖代々のコードを乗っ取りました。長い間トラブルシューティングを続けましたが、解決されませんでした。彼は、コードを持って逃げる準備をしていました。バケットを作成し、最終的に彼がそれを解決するのを助けました。完全なプロセスは https://mengkang.net/1470.html で見つけることができます。ただし、最終的なコードの位置は私の個人的な経験に基づいています。実際に呼び出されるリンクは、私が呼び出したものとは異なります。予想されており、すべて推測に基づいています。完全な呼び出しチェーンが表示されなかったので、呼び出しチェーン全体の明示的なクエリを支援するツールが必要だと思いました。
そこで私は、主に日常環境で再現するのが難しい不慣れなプロジェクトやオンライン シナリオのためにこのツールを構築しました。
deliver 祖先コードのエスケープ救助者 https://github.com/zhoumengka...
プロジェクトがそれほど悪くなく、日々の環境が問題ない場合は、そうするのが最善ですプロジェクトに精通している メソッドは依然として xdebug です。このツールは主にオンラインの問題のトラブルシューティングに使用されます。
同様のツールには 360 の phptrace 実装原則が含まれますが、これは若干異なります
関数名、クラスに基づくことができますname、メソッド名とルートを使用して出力をフィルタリングします
指定されたフィルタリングされたコンテンツを n 回クエリした後に終了できます
再生できますリクエスト ID に基づいてリクエスト全体を返します。 完全なコール チェーン
#フィルターされたコンテンツが強調表示されます。
コール スタックが深い場合は、 -l を指定すると、深い呼び出しの表示を非表示にできます。
実際には、これは比較的単純です。 2 つのステップ。最初のステップはログを収集し、2 番目のステップはログを分析します。
PHP_MINIT ステージで、zend_set_user_opcode_handler を使用して、3 種類のオペコード (ZEND_DO_UCALL、ZEND_DO_FCALL_BY_NAME、および ZEND_DO_FCALL) の処理と分析をセットアップします。
これはいくつかの組み込み関数とメソッドの呼び出しをカバーしており、タイプによってフィルターできることに注意してください。
次に、PHP_RINIT ステージで新しいログ ファイルを作成し、要求された情報を書き込みます。
pid-ts sapi http_method http_url
要求プロセス中に、コール スタック情報をカスタム ハンドラーに出力します。
最後に閉じます。 PHP_RSHUTDOWN のログ ファイルの書き込み
bin/deliverer を使用して、収集されたログを分析および整理します。これは PHP スクリプトであるため、ここでは説明しません詳細に入ります。
$ phpize $ ./configure --with-php-config=/usr/local/php/bin/php-config $ make && sudo make install
[deliverer] extension=deliverer.so
sudo service php-fpm restart
$ chmod +x deliverer
$ ./bin/deliverer -t
を使用して実行すると、常に監視されます。すべての php プロセスの実行
$ ./bin/deliverer -tAction::initUser -n3 -l5
##パラメータ
-t | ||
---|---|---|
-n | 3 | |
-l | 5 | |
## $ ./bin/deliverer -v7979-1624369150991941 ログイン後にコピー | -v requestId を使用して完全な詳細を表示します。呼び出しスタック