スムーズで整然としたプロセスになるように、BT 設定のベストプラクティスを適用できます。このページでは、AppDynamics、アプリケーション、およびインフラストラクチャを最大限に活用するために、アプリケーションの重要なビジネストランザクションを特定する方法に関するベストプラクティスについて説明します。

  • ビジネストランザクションの命名と BT 制限の使用
    デフォルトの BT 名は、URI の最初の 2 つのセグメントに基づいています。URI またはセグメントが増えると、BT がオーバーフローし、一部の有用な BT が All other traffic - <tier> に分類される可能性があります。

たとえば、次の /eCommerce/login の URI をモニタします。

    • /eCommerce/order
    • /eCommerce/checkout
    • /eCommerce/feedback

ただし、 /order には多数の URI パターンが含まれていて、3 つ以上のセグメントが使用される場合は 200 BT の制限に達する可能性があり、All Other traffic - <tier> オーバーフロー BT の下の /eCommerce/checkout のように、優先 BT になる可能性があります。さらに、/order は、モニタされる必要がある多くの URI になります（ユーザには必要ありません）。

    • /eCommerce/order/1/add
    • /eCommerce/order/list
    • /eCommerce/order/2/add

したがって、サーブレットの命名に完全な URI を有効にする代わりに、特定の完全な URI のパターンのカスタムサーブレットルールを使用して BT をグループ化し、BT の容量制限をより効率的に使用することを推奨します。コントローラレベルで BT 制限を増やすこともできますが、別の方法として、サービスエンドポイント機能を使用できます。

  • 不要な BT を除外する：エージェント スナップショットの収集は、ターゲット層のモニタされる BT リスト内の一意の BT の数に応じています。したがって、自動検出されたトランザクションの一部としてリストされている BT が不要かどうかを確認するために、[Business transactions] リストを確認することを推奨します。このような BT を一時的に除外するには、[Exclude Transactions] オプションを使用できます。スナップショットを収集せず、KPI メトリックのみが必要な場合は、サービスエンドポイントとして BT をモニタできます。

  • BT スプリットとサービスエンドポイントを使用する：BT 命名のバリアント結果が多すぎる場合は、エントリポイントにスプリットオプションを使用しないことを推奨します。スプリット機能を使用する必要がある場合は、スプリットオプションで結果値の除外を使用する必要があります。 

    スプリット除外は、サーブレットや POJO などの一部のエントリポイントでのみ使用できます。

    スプリットの出力が多数ある場合は、BT の代わりにサービスエンドポイントのスプリット機能を使用する必要があります。

  • BT 機能を使用してユーザトランザクションをモニタし、サービスエンドポイントを使用するタイミングを把握する：すべての BT には、定期的に行われるか、低速のしきい値に基づいたスナップショットまたはコールグラフの収集が関連付けられていて、追加のデータ収集（コールグラフ、リクエストの詳細、リモートサービスなど）が行われます。収集された基本的な KPI（1 分間のコール数、ART、1 分間のエラー数、遅延コールまたは過剰遅延コール）メトリックのデータに加えて、特定の API または URI トランザクションの要件が基本的な KPI メトリックのみを取得する（リクエストの詳細は取得しない）ことであり、コールグラフが BT スナップショット収集の一部である場合は、サービスエンドポイント機能Service Endpointsを使用して URI または API をモニタすることを推奨します。たとえば、ユーザが特定の API の応答時間を知りたい場合などです。
  • BT の制限によりサービスエンドポイントでネストされたトランザクションをモニタする：BT には、ユーザトランザクションの一部である単一エントリポイントの API または URI の一部としてすべてのサブコールが追跡される、スナップショット収集機能が含まれています。例：

          CheckoutServletClass => OrderTransaction_WS|SOAP_EndPointAPI => JDBC Exit calls

  • CheckoutServletClass と OrderTransaction_WS API を個別の BT としてモニタする必要がある場合、OrderTransaction_WS の BT は、エントリポイント CheckoutServletClass のマスキングされたトランザクションまたは子トランザクションとして扱われます。 
  • サービスエンドポイント（SEP）には BT のようなネストされたトランザクションの制限がないため、SEP 機能が最適です。すべてのサブコールを個別のエンドポイントとしてモニタし、BT と同様に基本的な KPI メトリックを取得することができます。
  • SEP ドリルダウンと BT スナップショットを使用する：SEP はスナップショットを明確には収集しませんが、API または URI の SEP ダッシュボードがターゲットスナップショットの一部である場合、BT の一部として収集されたスナップショットを表示できます。これにより、モニタ対象の SEP がモニタ対象の BT サブコールの一部である場合に、ユーザは SEP のスナップショットレベルのトラッキングを利用できます。
  • 自動検出を無効にしてエントリポイントを切り替える前に
    • 自動検出を無効にする必要がある特定のエントリタイプ（EJB または Spring）のトランザクション検出ルールの設定をいくつか行う必要があります。
    • ユーザアプリケーションが EJB または Spring ベースの場合、[Transaction Detection] タブの [java auto-discovery rule] UI で自動検出オプションを有効にする代わりに、カスタムの EJB または Spring ベースのルールを定義することを推奨します。
  • アプリコードフローの知識を使用して、モニタする API または URI を分析する：すべてのエントリポイントに対して、BT の自動検出のオプションの代わりに、サービスエンドポイントの自動検出を使用できます。これは、トランザクションが発生したときにアプリケーションで使用される API をキャプチャするために役立ちます。BT としてモニタするトランザクションと、SEP としてモニタするエンドポイントを決定します。