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 の応答のみをカウントしています。また、呼び出し関係の再生とエラー ログ アラートの重複排除統計も提供しています。これらの機能により、ライン上の要所での性能障害やシステム異常を迅速に発見できます。現在はスタンドアロン バージョンのみですが、将来的には必要に応じて、よりシンプルな分散モードにさらに拡張することができます。

上記のサービスは現在、オンラインで提供されているだけではありません。たとえば、QA テストの環境は、Traceid を介してすべての呼び出しプロセスに接続されています。 、戻り条件、およびこのリクエストのパフォーマンス。これは、簡単に分析できるように視覚的に表示できます。これは、オンラインにする前の単体テストでも実行できます。少し前に、私が Fiery を宣伝するために Weibo に投稿したとき、誰かが、Fiery がハッカーの侵入プロセスと特定の詳細を表示するためのハニーポットとして使用される可能性があると言及しました。このシステムは、PHP エコシステムのギャップを埋めるように設計されています。

以上がPHP での分散トレースの簡単な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。