Related pages:

サポートされている HTTP クライアントを使用して発信コールが行われる場合、AppDynamics は HTTP バックエンドを自動検出し、デフォルトではそのホストとポートに基づいて命名します。デフォルトの構成ではアプリケーションに意味のない名前となった場合（EC2ホスト名、ファイルパス、ファイルのポートなど）、ここで説明されているように、デフォルトの検出ルールを変更できます。

また、HTTP コールが複数のインストゥルメント化されたダウンストリームティアのいずれかにリクエストをルーティングする http ルータに向けて送信される場合、名前にターゲット URL の十分な数のセグメントが含まれるように、つまり各宛先ティアが別の名前が付けられたバックエンドに関連付けされるように、デフォルトの命名規則を変更する必要があります。

HTTPバックエンドの命名について

アプリケーションで検出される HTTP バックエンドが意味のある名前を持つように、またビジネストランザクション相関が正しく機能するようにするには、カスタム構成において環境内で使用する特定のフォーマットを考慮する必要があります。

フォーマットは1つの環境内でも異なる場合があります。たとえば、命名では意味を持たない可能性のある ec2storage というプレフィックスが付くホスト名を使用するバックエンドシステムもあれば、意味を持つ可能性のある salesforce.com のようなホスト名を使用するバックエンドシステムもあります。 

別のフォーマットが必要な場合は、自動検出ルールを変更するのではなくカスタムルールを作成する必要があります。これによって別のURLフォーマット用の異なるルールを適用できます。

以下の例のように、ケースごとに特殊なアプローチを適用できます。

  • 「ec2storage/servicename」の形式には、URLを使用
  • 「salesforce.com」の形式には、ホスト名を使用
  • その他のバックエンドには、クエリ文字列を使用
  • HTTP ルータを介して複数のダウンストリームティアのいずれかに届く可能性のあるコールの場合、リクエストを処理できる各ダウンストリームティアが別の名前が付いたバックエンドに関連付けられるように、名前にターゲット URL の十分な数のセグメントを使用する必要があります。

一部のケースでは、HTTPバックエンド検出の設定がデフォルトルールとカスタムルールの組み合わせで構成されている場合があります。次のセクションでは、特定の例を説明します。

検出ルールでのURLパスの使用

例えば、ティアまたはアプリケーションにおけるすべてのHTTPバックエンドが「ec2storage」のようなプレフィックスを持つなど、形式が類似している場合は、自動検出ルールを編集して監視するバックエンドの正しい名前を番号を生成できます。これにより、対象の KPI をモニタできます。

以下のHTTP URLを持つアプリケーションを検討します。

http://ec2-17:5400/service1
http://ec2-17:5450/service2
http://ec2-18:5400/service1
http://ec2-18:5450/service2

この場合、IP アドレスが一時的であり、IP アドレスがリサイクルされた後はすべてのパフォーマンス番号が無関係となるため、ホスト名に基づきパフォーマンスを測定することは意味がありません。代わりに、ホストとポートのプロパティを使用せず、次のようにURLプロパティのみを使用することでモニターできます。

  1. 使用するエージェントタイプの HTTP 用の Automatic Backend Discovery ルールを編集。この画面へのアクセス方法については、「バックエンド検出ルール」を参照。 
  2. まず Host および Port の使用を選択して無効化。
  3. 次に、バックエンドを独自に識別するために使用するプロパティを選択して有効化。この場合、[URL] を選択して、[Use URL in the Backend Name] をオンにします。
  4. [How will URL be used in the Backend name?] フィールドについては、[Use a segment of it] を選択。

  5. セグメントオプションのドロップダウンリストから、[Use the first N Segments] を選択。

    重要な URL セグメントは「作成」サービス用のため、構成は前のスクリーンショットと同じになります。

  6. [Split Delimeter] にスラッシュ「/」を入力。
    同様の手法で、以下のURLのユーザー名など、URLの一部を削除。

    [http://host:34/create/username1]
[http://host:34/create/username2]

  7. 構成を変更したら、すべてのHTTPバックエンドを削除。エージェントが新しい設定でバックエンドを再検出すると、フローマップにはサービスバックエンドのみが表示される。

カスタム HTTP バックエンド検出と命名構成


コントローラ UI を使用して Linux 用 .NET エージェントに対応した HTTP バックエンド検出と命名方法をカスタマイズできるようになりました。
HTTP バックエンド検出と命名方法のカスタマイズは、Linux 用 .NET エージェントのバージョン 4.5.13 の機能プレビューであり、実稼働前のシステムで使用することをお勧めします。この機能を有効にする場合は、「プレビュー機能の有効化」を参照してください。


デフォルトでは、AppDynamics はホスト名とポート番号を使用して、HTTP バックエンドを検出して名前を付けます。これは多くの場合に適していますが、マイクロサービス、コンテナ、または Serverlet が API ゲートウェイまたはポータルによって管理されている場合、クライアントと通信するバックエンドサービス、または相互に通信するバックエンドサービスは、自動検出を編集してクエリ文字列の一部を使用するか、HTTP カスタム検出ルールを使用して一意に命名しない限り、適切なティアにマッピングできません。この場合、AppDynamics では、カスタム HTTP バックエンド検出ルールの作成が推奨されています。 

次のスクリーンショットは、構成例を示しています。

ここでは、[Match Conditions] を選択して、API ゲートウェイホスト（この場合は api.appdynamics.com）を記述します。

このスクリーンショットは、分割と結合の区切り文字として「/」を使用し、最初の 3 つのセグメントの使用を選択します。

上記のように HTTP バックエンド検出ルールを構成すると、バックエンドメトリックが検出され、api.appdynamics.com で始まり、トランザクションの URL の最初の 3 つのセグメントを付加したビジネストランザクション名（api.appdynamics.com/api/catalog、api.appdynamics/api/payment など）の下に報告されます。構成された HTTP 検出ルールに一致するトランザクションは、同じホスト名とポート番号を共有している場合でも、個別にバックエンドとして認識されます。これらのトランザクションは個々のティアにマッピングできるので、API ゲートウェイの背後で発生するトランザクションのメトリックを分析できます。

現在のプレビューでは、HTTP バックエンド検出構成に既知の問題があります。URL セグメントを使用して HTTP バックエンドを定義する場合、セグメントの列挙子は番号 1 ではなく番号 2 で始まり、セグメント 1 は常に空を返します。
たとえば、URL の最初の 2 つのセグメントを使用して一意のバックエンドを定義するには、最初の 3 つのセグメントまたはセグメント 2 と 3 を使用するように HTTP バックエンド検出を構成する必要があります。