APM の Transaction trace が収集される仕組みを理解しよう

New Relicの APM には Transaction trace と呼ばれる APM で記録した単一のトランザクションにおけるパフォーマンス情報の詳細なスナップショットの情報を表示します。関数の呼び出しやデータベースコール、外部のサービスへの呼び出しにかかった処理時間を計測してパフォーマンス問題におけるボトルネックの特定に役立てることができます。

今回はその Transaction trace がどのように収集されるのかについて紹介する記事となります。
ドキュメントを以下に添付しますので詳細な情報を見たい場合はドキュメントを参照ください。
https://docs.newrelic.com/docs/apm/transactions/transaction-traces/introduction-transaction-traces/

Transaction 収集のルール

まず Transaction trace の収集の前に Transaction の収集ルール(=サンプリング)について理解をしておく必要があります。

Transaction とは APM が記録する1処理における情報です。APM が計測する基本的な情報は Transaction に記録されていきます。

Transaction は harvest cycle と呼ばれる一定の周期に基づいて収集する Transaction の数を決定しています。これは APM Agent の設定によって決定しており Java の場合は max_samples_stored という設定によって決定しておりデフォルトで分間2000件の Transaction を収集するようになっています。

つまりデフォルトの設定で３台のEC2やコンテナで動くような Java アプリケーションがあった場合に、１分間で記録される最大の Transaction 数は6000件ということになります。

簡単な絵にするとこのような形になります。

この max_samples_stored については後述する Transaction trace の収集について関与するのでこの前提で次の章の説明をします。

Transaction trace の収集ルール

Transaction の収集について説明しましたが Transaction trace はどのように収集されるのでしょうか？
2つの項目にわけて説明します

apdex

Transaction trace の収集ルールとしてまず apdex というワードが重要になってきます。
apdex とはアプリケーションやサービスの応答時間に対するユーザーの満足度を測定するための業界標準の仕様である一定の値を元にユーザーが満足しているかどうかというものを計測するための指標となっています。
https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measure-user-satisfaction/

どのように収集するのか？

では本題の Transaction trace の収集ルールについてですがharvest cycleの中で収集対象となった Transaction の中で apdex で定めた数値(デフォルト0.5秒)の4倍の応答時間がかかった Transaction をプールします。

プールされた Transaction の中で最も遅かった Transaction が Transaction trace として収集の対象となり実際に UI 上で分析できる情報として New Relic に送られます。

説明が長くなりましたがステップとしては以下２つを抑えておけば問題ありません。

1. harvest cycle(1分間)の中で apdex の４倍(2秒)かかった Transaction がプールされる
2. harvest cycle終了時にその中で一番遅かった Transaction が Transaction trace としてデータが送られ　New Relic の UI に表示される

APM 内部ではこのような処理がおこなわれています。

ただし例外もあり以下のようなこともあります

• Java エージェントは、時折発生する低速ではないトランザクションを収集します
• あるトランザクションが頻繁にトレースされる場合、より多様なサンプリングを行うために、一部のエージェントは他のトランザクションを選択します

まとめ

Transaction trace の収集の仕組みとしては以上になります。

収集された多くの Transaction trace は低速な Transaction を記録するため、わざわざ遅くなっている処理などを探す必要がなくなるのでその瞬間に遅くなっているものや継続的な改善にも役に立てます。

ただし以下の注意点もあります

1. Transaction のサンプリングから漏れたもので低速だったものは対象にもならない
2. 他にも遅かったものはあるが１つしか取得されないので網羅的に把握はできていない

こういった点もあるので Transaction trace で遅いものが確実に捕捉されるという保証はないということを考慮しつつ利用してください。

New Relic株式会社のQiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

無料のアカウントで試してみよう！

New Relic フリープランで始めるオブザーバビリティ！