データベースおよびリモートサービス(実際には、ビジネストランザクション処理に関与するプロセスコンポーネントから検出されたもの)は、すべてバックエンドと見なされます。インストゥルメンテーションからバックエンドを検出します。ポイントとは、発信コールがインストゥルメント化されたノードから行われるコードにおける正確な位置です。AppDynamicsは幅広いバックエンドを自動検出します。検出可能なバックエンドは、そのタイプおよび関連するプロパティにより識別されます。指定されたバックエンドの識別に使用されるプロパティの完全なセットは、そのタイプによって異なります。タイプは、標準のバックエンドタイプに対応した組み込みバックエンド検出ルールで定義されます。バックエンドプロパティを使用してバックエンドの識別と命名を行います。つのダウンストリームティアだけで処理されるコールとなるようにしてください。十分な数のセグメント(およびホストとポート)を含める必要があります。セットを持つバックエンドと関連付けます。リストには、構成可能なバックエンド検出ルールが表示されます。自動検出ルールは、識別されるバックエンドのタイプにより異なりますが、通常はバックエンドタイプの自動検出の有効化、関連付けの有効化、およびバックエンドの識別および命名に使用されるプロパティに対する設定が含まれます。トランザクション相関を使用して、分散されたティア間のリクエスト処理を追跡します。特定のタイプのバックエンドは高容量イグジットポイントとして自動検出されます(ターボイグジットポイントと呼ばれることもあります)。高容量イグジットポイントの詳細については、「イグジットポイント検出ルール」を参照してください。イグジットポイントが初めて識別されると、その終了コールはバックエンド検出イベントを生成します。つのバックエンドに送信される各コールが、複数の異なるダウンストリームティアのいずれかに到達することがあります。このような状況は、たとえば、バックエンドの名前がバックエンドのホストとポートに基づいている場合に発生することがあります。サーバが識別されます。基づいて、リクエストを異なるダウンストリームティアに転送します。エージェントに自動的に指示します。これが発生すると、アップストリームティアと、ダウンストリームに表示される可能性があるすべてのターゲットティアの間のフローマップにサービスプロキシアイコンが表示されます。「サービスプロキシ」を参照してください。自動検出の変更アプリケーションフローマップに表示されるべき特定のバックエンドが表示されない場合は、バックエンドを検出するよう構成を変更できます。方法は以下のとおりです。デフォルトのバックエンド検出ルールを編集する。新しいカスタムバックエンド検出ルールを作成する。新しいカスタムイグジットポイントを作成し、自動的に検出されないバックエンド種類を可視化する。対象でないバックエンドの自動検出を無効にする。バックエンドの関連付けを無効にする。通常は、新しいルールを作成しなくても、デフォルトのルールを編集することで必要なカスタマイズを行うことができます。ボタンをクリックします。命名されたもの)の場合、検出されたバックエンドインスタンスの名前には、ポート番号が含まれます。バックエンドタイプ)で使用できない場合などに発生する可能性があります。不明なポート番号があっても、バックエンドは一意に識別されます。自動検出される多くのバックエンドタイプには、AppDynamicsで構成可能なプロパティを使用してバックエンドが特定され命名されます。JMSメッセージキューのプロパティは以下のようになります。MQ)次の情報ポップアップには、検出されたバックエンドを識別する場合の値の使用方法が表示されます。宛先キュー名に対応する値を示しています。バックエンドの集約または分割UIに表示されるバックエンドタイプのデフォルト設定を変更して、バックエンドを集約または分割することができます。JMSバックエンド検出のベンダープロパティを無効にして、すべてのJMSバックエンドを同じ宛先および宛先タイプで集約(結合)することができます。同じ宛先と宛先タイプを持つすべてのJMSバックエンドのメトリックが、1つのバックエンドとして集約されます。使用するプロパティについては、AppDynamicsでどのように使用するかを設定することもできます。URLプロパティを使用してバックエンドを識別し、URLにファイル名が含まれている場合、デフォルト設定ではすべてのファイルに対して別々のバックエンドが作成されます。URLプロパティを使用して識別されるバックエンドの数を減らすには、使用するURLの部分を構成します。URLで正規表現を実行して、識別に使用しないファイル名やURLの他の部分を破棄することができます。自動検出されたバックエンドタイプへの新規カスタム検出ルールの作成に柔軟に対応できます。リストでバックエンドタイプを選択します。アイコン)をクリックし、新しいルールを作成します。次に、以下を指定します。Name(カスタムルールの場合)。(ルールの有効化または無効化)。(ビジネストランザクション相関データをバックエンドに送信するかどうかを指定する場合).Priority(このカスタムルールをこのバックエンドタイプの他のカスタムルールと比較する場合)。数値が高いほど優先度が高くなる。0の値は、デフォルトルールを使用する必要があることを示す。Conditions(カスタム命名規則の影響を受けるバックエンドの識別に使用)。AppDynamicsでは、定義されたすべての条件を満たすバックエンドにデフォルトルールを適用。Configuration(一致条件に一致するバックエンドの命名に使用)。命名構成には、一致条件で使用するプロパティが必要です。具体例については、特定のイグジットポイントを参照してください。その他のすべてのトラフィックバックエンドAppDynamicsでは、登録および追跡が可能なバックエンドシステムの数が制限されています。(データベースとリモートサービスを組み合わせた数が)上限に達すると、追加のバックエンドは「<タイプ>のその他のトラフィック」カテゴリーに分類されます。サービスなどのバックエンドタイプです。キューは、デフォルトの構成ルールで上限に達する可能性のある最も一般的なタイプです。フローマップでは、カテゴリーは次のように表示されます。「その他のトラフィック」カテゴリーにグループ化されたバックエンドコールのメトリックが集計されます。個別に追跡するバックエンドインスタンスがグループにある場合は、「バックエンド検出の管理」に記載されている方法でバックエンド検出を管理できます。登録可能なバックエンドの上限数は以下のとおりです。コントローラ設定で制御されます。この制限を使用して、バックエンドをティアに転換するか、しないかを決定します。Traffic」カテゴリが自動的に作成されます。ログには、次のようなログエントリによって制限に達したことが示されます。Traffic」カテゴリと比較して重要なものであることを確認します。アプリケーションの環境条件が原因でバックエンド登録数の上限を超過していないかを確認します。この条件には以下のような場合が含まれます。宛先のセッションIDを使用するJMSキュー。これにより各セッションは別々のバックエンドとして識別されます。同じサーバー上にホストされているメッセージキューのコール。この場合、各キューを個別に表示するのではなく、同じホストおよびポートのすべてを同じバックエンドに集約することをお勧めします。EC2)でサービスをホストする場合などに行われるIPアドレスの動的生成。同じデータベースに接続する異なるJDBCドライバにより、多くのバックエンドが発生する場合があります。これは、AppDynamicsがデータベースを識別するために使用するドライバメタデータにわずかな違いがある場合に見られます。)と、実際には物理的に同じデータベースであるにもかかわらず複数のデータベース名を生成することがあります。バックエンド登録を管理するには、バックエンド検出ルールの構成を変更します。プロパティが過度の独自の識別を発生させる場合には、プロパティを削除するか、検出およびネーミング規約でそのプロパティを変更することをご検討ください。カスタムイグジットポイントを作成した場合には、それらの修正または削除をご検討ください。不要なバックエンドの削除もうトラフィックがないバックエンドも存在します。未使用のバックエンドは、リモートサービスリスト、リモートサービスダッシュボード、データベースリスト、およびデータベースダッシュボードのいずれかより削除できます。バックエンドに新しいトラフィックがあると、アプリケーションエージェントはそれを再検出してコントローラに登録します。無効なバックエンドを自動的に削除するようコントローラを構成することもできます。「無効なリモートサービスの削除」を参照してください。必要なバックエンドの検出を構成したら、UIに表示される方法を整理する必要があります。「フローマップでリモートサービスをグループ化」を参照してください。Confluence。