New Relic APM(PHP)でDistributed Tracingを利用する
昨日に引き続きNew Relic APMに関する内容です。
今年の7月末、New Relic APMでDistributed Tracingが利用できるようになりました。
複数のサービスが連携して動くアプリケーションの動作を、詳しく分析できる機能です。
複数サービスの追跡をできる機能としてはもともとCross Application Tracesというものがありました。
しかしこの機能は、各サービスの関係性を図式化できるだけで、各サービスのパフォーマンスについてはそれぞれのAPM Navigatorでしか見ることができません。
対してDistributed Tracingは、1つのWebトランザクションに対して各サービスがどのような処理を行なっているか、1つの画面で詳しく見ることができます。
Distributed Tracingの利用準備
利用条件
- New Relic APM Professionalの契約をしている
- Distributed Tracingに対応したバージョンのAgentを利用している
この条件を満たしている場合のみ利用できます。
agentの設定
New Relic Agentの設定ファイルで、transaction_tracer.enabled
とdistributed_tracing_enabled
を有効にします。
例として、PHPの場合は /etc/php.d/newrelic.ini に下記を追記します。
newrelic.transaction_tracer.enabled = true
newrelic.distributed_tracing_enabled = true
※transaction_tracer.enabledはデフォルト値がtrueなので、falseを指定していなければ明示的に書かなくても動きます。
Distributed Tracingの見方


ここから先がDistributed Tracingの画面です。
Distributed Tracingでは、同一のリクエスト内で行われた処理のまとまりをトレース、処理の中で実行された通信をスパンと呼びます。
グラフはトレースのレスポンスタイムの分布を表したもので、縦軸がレスポンスタイム、横軸が時間の流れです。エラーが発生したトレースは赤い点でプロットされます。
グラフの下には、プロットされているトレースの情報が一覧で表示されます。SERVICES列にはそのトレースで呼び出されたサービスの数、TOTAL SPANSには発生した通信の数が表示されます。
グラフ上の点や一覧の行をクリックすると、そのトレースの詳細画面へ移動します。

2つのサービスが呼び出されたトレースの詳細画面です。最初に呼び出されたサービスが青、次に呼び出されたサービスが紫の線で表示されています。
このトレースはレスポンスに3.17秒を要し、青で示されるサービスでは190回の通信、紫で示されるサービスでは62回の通信が発生していることがわかります。
Collapse allやスパン数をクリックすると、スパンの一覧が表示されます。

スパンの一覧では、各スパンの概要(通信先がMySQLであればどのテーブルに対するクエリなのか)や要した時間が表示されます。
スパンをクリックするとそのスパンの詳細な情報が表示されます。

MySQLのスパンの詳細を開くと、そのスパンでクエリされたSQLが表示されます。
このように、1つのトレース内で実行された処理の詳細を、複数のサービスに渡って確認することができます。
まとめ
例で示したトランザクションで動くサービスは最大で2つですが、それだけでもDistributed Tracingはアプリケーションの問題点を探すのにとても便利です。
より多くのマイクロサービスで構築されたシステムでは、さらに強力なツールとなるでしょう。