Related pages:

AppDynamics では、データベースおよびリモートサービス（実際には、ビジネストランザクション処理に関与するプロセスコンポーネントから検出されたもの）は、すべてバックエンドと見なされます。

AppDynamics は、アプリケーションコード内のイグジット ポイント インストゥルメンテーションからバックエンドを検出します。イグジット ポイントとは、発信コールがインストゥルメント化されたノードから行われるコードにおける正確な位置です。AppDynamicsは幅広いバックエンドを自動検出します。

デフォルトのバックエンド自動検出

検出可能なバックエンドは、そのタイプおよび関連するプロパティにより識別されます。指定されたバックエンドの識別に使用されるプロパティの完全なセットは、そのタイプによって異なります。タイプは、標準のバックエンドタイプに対応した組み込みバックエンド検出ルールで定義されます。APM エージェントでインストゥルメント化されていないバックエンドへの終了コールの場合、AppDynamics はバックエンドプロパティを使用してバックエンドの識別と命名を行います。バックエンドコールが AppDynamics で同様にインストゥルメント化されたダウンストリームティアによって処理される場合、識別される指定のバックエンドが常に 1 つのダウンストリームティアだけで処理されるコールとなるようにしてください。

つまり、たとえばティア A が HTTP コールを localhost:4040 の HTTP ルータ（このコールを URL に従ってティア B またはティア C に転送）に行う場合、カスタムバックエンド命名ルールにはリクエスト URL の十分な数のセグメント（およびホストとポート）を含める必要があります。これには、ティア B 宛のリクエストをティア C と関連付けられたものとは異なるバックエンド プロパティ セットを持つバックエンドと関連付けます。

[Configuration > Instrumentation >] [Backend Detection] タブの [Automatic Backend Discovery] リストには、構成可能なバックエンド検出ルールが表示されます。

自動検出ルールは、識別されるバックエンドのタイプにより異なりますが、通常はバックエンドタイプの自動検出の有効化、関連付けの有効化、およびバックエンドの識別および命名に使用されるプロパティに対する設定が含まれます。AppDynamics はトランザクション相関を使用して、分散されたティア間のリクエスト処理を追跡します。特定のタイプのバックエンドは高容量イグジットポイントとして自動検出されます（ターボイグジットポイントと呼ばれることもあります）。これらのバックエンドタイプには、キャッシュサーバ、EhCache、Danga Memcache、Memcached、および Oracle Coherence があります。高容量イグジットポイントの詳細については、「イグジットポイント検出ルール」を参照してください。

イグジットポイントが初めて識別されると、その終了コールはバックエンド検出イベントを生成します。 

サービスプロキシ

バックエンドの宛先を正しく識別できないと、（構成に基づいて）1 つのバックエンドに送信される各コールが、複数の異なるダウンストリームティアのいずれかに到達することがあります。

このような状況は、たとえば、バックエンドの名前がバックエンドのホストとポートに基づいている場合に発生することがあります。ここでは、特定のバックエンドのホストとポートの組み合わせによって Apache サーバが識別されます。Apache サーバは、サービスプロキシとして機能する URL に基づいて、リクエストを異なるダウンストリームティアに転送します。AppDynamics コントローラがこの状況を検出すると、バックエンドをサービスプロキシとして識別するようにアップストリーム エージェントに自動的に指示します。これが発生すると、アップストリームティアと、ダウンストリームに表示される可能性があるすべてのターゲットティアの間のフローマップにサービスプロキシアイコンが表示されます。「サービスプロキシ」を参照してください。

アクセス権

バックエンド検出を変更するには、Configure Backend Detection  権限が必要です。

自動検出の変更

アプリケーションフローマップに表示されるべき特定のバックエンドが表示されない場合は、バックエンドを検出するよう構成を変更できます。方法は以下のとおりです。

  • デフォルトのバックエンド検出ルールを編集する。
  • 新しいカスタムバックエンド検出ルールを作成する。
  • 新しいカスタムイグジットポイントを作成し、自動的に検出されないバックエンド種類を可視化する。
  • 対象でないバックエンドの自動検出を無効にする。
  • バックエンドの関連付けを無効にする。

通常は、新しいルールを作成しなくても、デフォルトのルールを編集することで必要なカスタマイズを行うことができます。

ルールを編集するには、[Backend Detection] タブでアプリケーションを選択し、[Edit Automatic Discovery] をクリックします。 

Backend Naming Configuration

特定のバックエンドタイプ（特に URL で命名されたもの）の場合、検出されたバックエンドインスタンスの名前には、ポート番号が含まれます。アプリケーション エージェントが何らかの理由でポート番号を検出できない場合、ポート番号は UI に「-1」と表示されます、これは、ポートがパブリックポートではない場合や、ポートを検出するための API がアプリケーション環境（多くの場合、RMI バックエンドタイプ）で使用できない場合などに発生する可能性があります。不明なポート番号があっても、バックエンドは一意に識別されます。

構成可能なプロパティおよび命名

自動検出される多くのバックエンドタイプには、AppDynamicsで構成可能なプロパティを使用してバックエンドが特定され命名されます。たとえば、JMSメッセージキューのプロパティは以下のようになります。

  • 宛先タイプ（例: QUEUE）
  • 宛先（例: OrderQueue）
  • ベンダー（例: Active MQ）

次の情報ポップアップには、検出されたバックエンドを識別する場合の値の使用方法が表示されます。次の例は、コールアウト 1 は宛先のタイプに、コールアウト 2 はベンダー名に、コールアウト 3 は宛先キュー名に対応する値を示しています。

Discovered Backend Type

バックエンドの集約または分割

UIに表示されるバックエンドタイプのデフォルト設定を変更して、バックエンドを集約または分割することができます。たとえば、JMSバックエンド検出のベンダープロパティを無効にして、すべてのJMSバックエンドを同じ宛先および宛先タイプで集約（結合）することができます。同じ宛先と宛先タイプを持つすべてのJMSバックエンドのメトリックが、1つのバックエンドとして集約されます。

使用するプロパティについては、AppDynamicsでどのように使用するかを設定することもできます。たとえば、URLプロパティを使用してバックエンドを識別し、URLにファイル名が含まれている場合、デフォルト設定ではすべてのファイルに対して別々のバックエンドが作成されます。

URLプロパティを使用して識別されるバックエンドの数を減らすには、使用するURLの部分を構成します。たとえば、URLで正規表現を実行して、識別に使用しないファイル名やURLの他の部分を破棄することができます。

カスタムバックエンド検出ルールの追加

AppDynamics では、自動検出されたバックエンドタイプへの新規カスタム検出ルールの作成に柔軟に対応できます。 

自動検出されたバックエンドタイプにカスタム検出ルールを作成するには、[Automatic Backend Discovery] リストでバックエンドタイプを選択します。[Add]（[+] アイコン）をクリックし、新しいルールを作成します。次に、以下を指定します。

  • Name（カスタムルールの場合）。
  • Enabled （ルールの有効化または無効化）。
  • Correlation Enabled （ビジネストランザクション相関データをバックエンドに送信するかどうかを指定する場合）.
  • Priority（このカスタムルールをこのバックエンドタイプの他のカスタムルールと比較する場合）。数値が高いほど優先度が高くなる。0の値は、デフォルトルールを使用する必要があることを示す。
  • Match Conditions（カスタム命名規則の影響を受けるバックエンドの識別に使用）。AppDynamicsでは、定義されたすべての条件を満たすバックエンドにデフォルトルールを適用。
  • Backend Naming Configuration（一致条件に一致するバックエンドの命名に使用）。命名構成には、一致条件で使用するプロパティが必要です。

具体例については、特定のイグジットポイントを参照してください。

その他のすべてのトラフィックバックエンド

AppDynamicsでは、登録および追跡が可能なバックエンドシステムの数が制限されています。（データベースとリモートサービスを組み合わせた数が）上限に達すると、追加のバックエンドは「<タイプ>のその他のトラフィック」カテゴリーに分類されます。

「type」は、HTTP や Web サービスなどのバックエンドタイプです。HTTP コールおよび JMS キューは、デフォルトの構成ルールで上限に達する可能性のある最も一般的なタイプです。 

フローマップでは、カテゴリーは次のように表示されます。

Flow Map Category

「その他のトラフィック」カテゴリーにグループ化されたバックエンドコールのメトリックが集計されます。個別に追跡するバックエンドインスタンスがグループにある場合は、「バックエンド検出の管理」に記載されている方法でバックエンド検出を管理できます。   

バックエンド登録の制限

登録可能なバックエンドの上限数は以下のとおりです。

  • コントローラは、バックエンドの各タイプのビジネスアプリケーションにおいて、バックエンドの登録上限を 1000 まで（HTTP バックエンドや JMS バックエンドなどでそれぞれ 1000 まで）としています。この設定は、backend.registration.limit コントローラ設定で制御されます。この制限を使用して、バックエンドをティアに転換するか、しないかを決定します。 
  • エージェントは、各アプリケーションにおける未転換のバックエンド数を 300 までに制限しています。 

バックエンド数がこの制限を超えると、「All Other Traffic」カテゴリが自動的に作成されます。ログには、次のようなログエントリによって制限に達したことが示されます。

[pool-1-thread-2] 21 Mar 2013 11:28:01,702 DEBUG AFastBackendResolver - Not discovering backend call [Exit Point Type [WEB_SERVICE] Properties [{SERVICE_NAME=ZipCodeService002.wsdl}] Display Name [ZipCodeService002.wsdl]] because maximum limit of discovered backends [300] reached.
CODE

バックエンド検出の管理

バックエンドの登録上限に達したら、ファーストクラス登録バックエンドとして追跡されているシステムが、「All Other Traffic」カテゴリと比較して重要なものであることを確認します。

また、アプリケーションの環境条件が原因でバックエンド登録数の上限を超過していないかを確認します。この条件には以下のような場合が含まれます。

  • 宛先のセッションIDを使用するJMSキュー。これにより各セッションは別々のバックエンドとして識別されます。
  • 同じサーバー上にホストされているメッセージキューのコール。この場合、各キューを個別に表示するのではなく、同じホストおよびポートのすべてを同じバックエンドに集約することをお勧めします。
  • Amazon Elastic Compute Cloud（Amazon EC2）でサービスをホストする場合などに行われるIPアドレスの動的生成。
  • 同じデータベースに接続する異なるJDBCドライバにより、多くのバックエンドが発生する場合があります。これは、AppDynamicsがデータベースを識別するために使用するドライバメタデータにわずかな違いがある場合に見られます。たとえば、2 つの異なる JDBC ドライバを使用して同じデータベースにアクセスする場合、データベース名のスペルや形式が異なる（ORACLE、oracle、または ORACL など）と、実際には物理的に同じデータベースであるにもかかわらず複数のデータベース名を生成することがあります。

バックエンド登録を管理するには、バックエンド検出ルールの構成を変更します。たとえば、プロパティが過度の独自の識別を発生させる場合には、プロパティを削除するか、検出およびネーミング規約でそのプロパティを変更することをご検討ください。カスタムイグジットポイントを作成した場合には、それらの修正または削除をご検討ください。 

不要なバックエンドの削除

もうトラフィックがないバックエンドも存在します。未使用のバックエンドは、リモートサービスリスト、リモートサービスダッシュボード、データベースリスト、およびデータベースダッシュボードのいずれかより削除できます。バックエンドに新しいトラフィックがあると、アプリケーションエージェントはそれを再検出してコントローラに登録します。

無効なバックエンドを自動的に削除するようコントローラを構成することもできます。「無効なリモートサービスの削除」を参照してください。

フローマップにおけるバックエンドの整理

必要なバックエンドの検出を構成したら、UIに表示される方法を整理する必要があります。詳細については、「フローマップでリモートサービスをグループ化」を参照してください。