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の見方
![Screen Shot 0030-12-23 at 22.22.48.png](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F13038%2F0a761445-aaab-9f0c-dd6d-5a81a93278cd.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=7124dcf21e3257faba1570da1902c88d)
![Screen Shot 0030-12-23 at 22.23.48.png](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F13038%2F2f873b2c-59d5-fad8-8895-fe6f087f7e42.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=1d2ae9508d0fe6c042a87a7347a147a1)
ここから先がDistributed Tracingの画面です。
Distributed Tracingでは、同一のリクエスト内で行われた処理のまとまりをトレース、処理の中で実行された通信をスパンと呼びます。
グラフはトレースのレスポンスタイムの分布を表したもので、縦軸がレスポンスタイム、横軸が時間の流れです。エラーが発生したトレースは赤い点でプロットされます。
グラフの下には、プロットされているトレースの情報が一覧で表示されます。SERVICES列にはそのトレースで呼び出されたサービスの数、TOTAL SPANSには発生した通信の数が表示されます。
グラフ上の点や一覧の行をクリックすると、そのトレースの詳細画面へ移動します。
![Screen Shot 0030-12-23 at 22.25.22.png](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F13038%2F8b325b22-b551-a64d-549c-509b25d2bb9e.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=b535fc5e2c1e6d74b0ae4149268ceed3)
2つのサービスが呼び出されたトレースの詳細画面です。最初に呼び出されたサービスが青、次に呼び出されたサービスが紫の線で表示されています。
このトレースはレスポンスに3.17秒を要し、青で示されるサービスでは190回の通信、紫で示されるサービスでは62回の通信が発生していることがわかります。
Collapse allやスパン数をクリックすると、スパンの一覧が表示されます。
![Screen Shot 0030-12-23 at 22.26.19.png](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F13038%2F5375bfa9-8acd-2f29-9c5f-a14bc61cec42.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=fe0897830d1cdafb0b0942574cdf6d66)
スパンの一覧では、各スパンの概要(通信先がMySQLであればどのテーブルに対するクエリなのか)や要した時間が表示されます。
スパンをクリックするとそのスパンの詳細な情報が表示されます。
![Screen Shot 0030-12-23 at 22.27.23.png](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F13038%2Ffc97e5ce-939b-e59d-d2f1-97ca7fd1bed9.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=feb8d7ee56d17b4865954c3ab6330023)
MySQLのスパンの詳細を開くと、そのスパンでクエリされたSQLが表示されます。
このように、1つのトレース内で実行された処理の詳細を、複数のサービスに渡って確認することができます。
まとめ
例で示したトランザクションで動くサービスは最大で2つですが、それだけでもDistributed Tracingはアプリケーションの問題点を探すのにとても便利です。
より多くのマイクロサービスで構築されたシステムでは、さらに強力なツールとなるでしょう。