PHP 分散トレースのエクスペリエンス共有

この記事では、主に PHP 分散トレーシングの経験をいくつか共有し、皆様のお役に立てれば幸いです。

マイクロサービスを実装して以来、私たちは多くの問題に遭遇しました。最大の問題は、障害をトラブルシューティングする方法です。通常、サービス指向のインターフェイスは複数のサービスに依存しており、依存するインターフェイスの速度がインターフェイスのサービス品質に直接影響します。

この種の依存関係によって引き起こされる速度の低下は、オンラインでは非常に一般的ですが、トラブルシューティングが簡単ではありません。その理由は、多数のログ開発者がログを通じてオンラインで追跡されており、開発者や一部の企業にとってはあまり直感的ではないためです。開発者 オンラインで特定の実行ステータスを確認することは不可能です。一般に、オンラインで発生する可能性の低い障害は、システム内の隠れた危険を表します。トラフィックが増加すると、これらの隠れた危険が増幅され、同様の事態を回避するために、多くのことを行う必要があります。最も直感的なのは、統計分析に分散トレース システムを使用することです。

オンラインのパフォーマンスを最適化する方法やパフォーマンスを向上させる方法について専門家が話し合っているのをよく見かけますが、実際には、可能性の低い障害をどのように発見するかについて言及されていません。分散型追跡システムは大規模なインターネット企業では非常に一般的ですが、中小企業にはこのシステムを実装するための技術力がありません。私たちの観点からすると、たとえトラフィックが非常に少ないとしても、システムは依然として会社にとって非常に重要であり、問​​題を見つけることができて初めてそれを解決することができるのです。これが私が常々抱いている目的です。実装されました。

分散追跡システムの具体的な実装には、パフォーマンスのキャプチャ、ログの書き込み、ログの収集と並べ替え、ログの送信、ログの保存、ログのインデックス作成、リアルタイムのログ分析、そして最終的にマージを実現する必要があります。システムは大流量システムの影響に対処できる必要があります。たとえば、各リクエストがインターフェイスごとに 1,000 個のログを生成する場合、QPS 2000 サーバーは、リクエストが 5 つのインターフェイスに依存する場合、オンライン ビジネスがより複雑でトラフィックが大きい場合、1 秒あたり 1,000 万個のログを生成します。時間が経過すると、この値は増加します。

大規模なインターネット企業は、数十億のトラフィックに耐えることができる多くの分散型追跡システムを備えていますが、小規模な企業にとって、このアーキテクチャは非常に負担が大きく、その多くは分散型メッセージング システム、分散型ストレージ、および分散に依存しているとのことです。式で計算すると、これだけでも少なくとも 6 台以上のサーバーを使用することになり、一般的な中小企業にとっては費用対効果が高くありません。

今回は 2 種類のオープンソース分散トラッキングを用意しています。1 つは中小規模のインターネット企業向けのスタンドアロン版で、PV をサポートできます。 2000wの業務システム（決済システムなど）。数十億の分散 PV をサポートする分散追跡システムもあります。現在、Fiery のスタンドアロン バージョンが公開されました (https://github.com/weiboad/fiery)。このバージョンは、プロジェクト全体が中小企業向けに設計されています。 Java8 ランタイムがある限り、そのまま使用できます。もちろん、システムは単に埋め込みジョブを実行する必要があります。 C++ 分散バージョンは多くのものに依存しており、運用および保守担当者に特定の能力が必要です。スタンドアロン バージョンは、状況に応じて後でリリースされます。これらのコア取引システムは完全にオープンソースであり、内部に機密データが含まれており、完全に利用可能です。

現在、市場には複数の分散追跡の方法があり、その中には企業内で使用されているものもあれば、小規模な無料サービスや大規模な有料サービスもあります。一般的な分散トレースは、統計的手法を通じて各ブロックのパフォーマンスを記録します。私たちが現在提供している方法は、市場に出ているものとまったく同じではありません。私たちは、継続的な実験を通じて多くの簡素化を行い、本当に実用的であると思われる機能だけを残し、重要なシステムを分散監視するためのシステムを設計しました。決済システムやトランザクションシステムなど。

各リクエストの特定の状況、戻り値、特定のパフォーマンス、その他の情報を記録し、テーブル分析を通じて、オンラインに依存するインターフェイスのパフォーマンス (サードパーティまたは埋め込まれていないインターフェイスのパフォーマンス統計) を迅速に発見し、埋もれているものを実行できます。インターフェイスもパフォーマンス ランキングのために独自に分析されました。分析テーブルを表示すると、再生をリクエストする最も遅いインターフェイスをすぐに見つけて、オンライン パフォーマンスが遅い原因を分析できます。実践を通じて、多くの場合、PHP が依存するデータ リソースの遅さが PHP インターフェイスのパフォーマンスの低下につながることがわかりました。したがって、リソースに依存することに焦点が当てられます。ユーザーは必要に応じて他の情報を追加できるため、大量の無駄なログを削減し、より節約できます。

このオープンソース Fiery は主に、PHP 侵入ポイント ライブラリ、合理化されたログ監視プッシュ モジュール、サーバーの 3 つの部分で構成されています。この 3 つで PV が 2000w 未満の Web サイトの分散トラッキングを実現します。

埋め込まれたポイント ライブラリは、入口で Traceid (UUID) を生成します。この Traceid は、入口サーバーの IP アドレスと、後続のすべてのログにこの UUID でマークされます。ログ収集後、関連するすべてのログがこの UUID に従って保存されます。埋め込みポイント ライブラリは、他のリクエストによって送信された Traceid を受信し、実行時に RPCID を送信および維持する役割を果たします。RPCID は、呼び出し関係の順序と階層を直接復元し、開発者に表示できる階層型カウンターです。 。さらに、PHP の操作中に例外が発生した場合、サーバーが重複排除統計を実行するために、埋め込みポイント ライブラリによって例外がキャプチャおよび記録されます。最後に、これらのログはサーバーのローカル ディスクに記録されます。いくつかの理由により、複数の PHP プロセスが同時にファイルを書き込む場合、プロセス ID に基づいてログが記録されることがあります。プロジェクト名をファイル名として使用します。

Fiery ログのキャプチャと送信の簡易バージョンを実装しました。これは、運用および保守担当者の作業を簡素化するためです。現在、同様の機能を提供するオープンソースが数多くありますが、それらは他のものに依存する必要があります。運用と保守にとって非常に重要な環境です。一定の負担がかかります。実験的な PHP ログのキャプチャおよび送信サービスもありますが、これはまだ実験的な機能であり、ユーザーがデバッグや改善に参加できることが予想されます。

私たちは、Fiery のサーバー側と組み込みの Lucene と Rocksdb で、リクエストのインデックス作成と保存をそれぞれ行うために多くの作業を行いました。メモリ統計についてもいくつかの作業を行っていますが、現時点では、ローカル インターフェイス、依存インターフェイス、Mysql、および Curl の応答のみをカウントしています。また、呼び出し関係の再生とエラー ログ アラートの重複排除統計も提供しています。これらの機能により、ライン上の要所での性能障害やシステム異常を迅速に発見できます。現在はスタンドアロン バージョンのみですが、将来的には必要に応じて、よりシンプルな分散モードにさらに拡張することができます。

上記のサービスは、オンライン サービスだけでなく、社内でも多くの興味深い試みを行っています。たとえば、テストが完了すると、Traceid が生成されます。開発の場合、開発者は Traceid を使用して、このリクエストのすべての呼び出しプロセス、パラメーター、戻り条件、パフォーマンスを見つけることができ、簡単に分析できるように、単体テストを開始する前に同じことを行うことができます。オンライン。少し前に、私が Fiery を宣伝するために Weibo に投稿したとき、誰かが、Fiery がハッカーの侵入プロセスと特定の詳細を表示するためのハニーポットとして使用される可能性があると言及しました。このシステムは、PHP エコシステムのギャップを埋めるように設計されています。

関連する推奨事項:

PHP分散システムでRedisを使用したセッションを実装する方法

PHP分散および大規模データ処理に関連する問題

PHP分散内部メモリ共有(Memcache)

以上がPHP 分散トレースのエクスペリエンス共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。