Versions Compared

    Key

    • This line was added.
    • This line was removed.
    • Formatting was changed.
    Comment: Published by Scroll Versions from this space and version 20.5
    Sv translation
    languageen
    Appd tocbox
    Width260px

    Related pages:

    After you learn the basics of AppDynamics through a hands-on trial, you're ready to learn how AppDynamics models application environments. The model serves as the framework around which AppDynamics organizes and presents performance information.  

    Application Model Overview

    A typical application environment consists of the different components that interact in a variety of ways to fulfill requests from the application's users:

    • Web applications served from an application server
    • Databases or other data stores
    • Remote services such as message queues and caches

    AppDynamics app agents automatically discover the most common application frameworks and services. Using built-in application detection and configuration settings, agents collect application data and metrics to build flow maps.

    A flow map visually represents the components of your application to help you understand how data flows among the application components. For example, the business transaction flow map for a simple e-commerce application below shows data flowing between web services, message queues, and databases: 

    The business transaction flow map for a simple e-commerce application below shows data flowing between web services, message queues, and databases.

    Automatic detection lets you start exploring AppDynamics features quickly. As your understanding of AppDynamics matures and you identify areas unique to your environment, you can refine your application model.

    Business Transactions

    In the AppDynamics model, a business transaction represents the data processing flow for a request, most often a user request. In real-world terms, many different components in your application may interact to provide services to fulfill the following types of requests: 

    • In an e-commerce application, a user logging in, searching for items or adding items to the cart
    • In a content portal, a user requests content such as sports, business or entertainment news
    • In a stock trading application, operations such as receiving a stock quote, buying or selling stocks

    AppDynamics app agents discover requests to your application as entry points to a business transaction. Similar requests, such as user login, are treated as multiple instances of the same business transaction. The agents tag the request data and trace the request path as it passes from web servers to databases and other infrastructure components. AppDynamics collects performance metrics for each tier that processes the business transaction.

    Because AppDynamics orients performance monitoring around business transactions, you can focus on the performance of your application components from the user perspective. You can quickly identify whether a component is readily available or if it is having performance issues. For instance, you can check whether users able to log in, check out or view their data. You can see response times for users, and the causes of problems when they occur. 

    Business Applications

    A business application is the top-level container in the AppDynamics model. A business application contains a set of related services and business transactions.

    In a small AppDynamics deployment, only a single business application may be needed to model the environment. In larger deployments, you may choose to divide the model of the environment into several business applications.

    The best way to organize business applications for you depends on your environment. A leading consideration for most cases, however, is to organize business applications in a way that reflects work teams in your organization, since role-based access controls in the Controller UI are oriented by business application.

    Nodes

    A node in the AppDynamics model corresponds to a monitored server or JVM in the application environment. A node is the smallest unit of the modeled environment. Depending on the agent type, a node may correspond to an individual application server, JVM, CLR, PHP application, Apache Web server. 

    Each node identifies itself in the AppDynamics model. When you configure the agent, you specify the name of the node, tier, and business application under which the agent reports data to the Controller. 

    Tiers

    A tier is a unit in the AppDynamics model composed of a grouping of one or more nodes. How you organize tiers depends on the conceptual model of your environment.

    Often a tier is used to a group of a set of identical, redundant servers. But that is not strictly required. You can group any set of nodes, identical or not, for which you want performance metrics to be treated as a unit into a single tier.

    The single restriction is that all nodes in a single tier must be the same type. That is, a tier cannot have mixed types of agents, such as both .NET and Java nodes. 

    The traffic in a business application flows between tiers, as indicated by lines on the flow map, which are annotated with performance metrics.

    In the AppDynamics model:

    • There is no interaction among nodes within a single tier
    • An application agent node cannot belong to more than one tier

    Entities

    An entity is any object that AppDynamics monitors, such as an application, tier, node, or even a business transaction. Entities typically have associated metricsevents, and a health status. 

    Backends

    A backend is a component that is not instrumented by an AppDynamics agent but that participates in the processing of a business transaction instance. A backend may be a web server, database, message queue, or another type of service.

    The agent recognizes calls to these services from instrumented code (called exit calls). If the service is not instrumented and cannot continue the transaction context of the call, the agent determines that the service is a backend component. The agent picks up the transaction context at the response at the backend and continues to follow the context of the transaction from there.

    Performance information is available for the backend call. For detailed transaction analysis in for the leg of a transaction processed by the backend, you need to instrument the database, web service or other application.

    Integration with other AppDynamics Modules

    This section describes how other AppDynamics APM Platform products work with Application Monitoring to provide complete, full visibility on application health and user experience.

    Application Monitoring and Infrastructure Visibility 

    Infrastructure Visibility provides end-to-end visibility into the hardware and networks on which your applications run. You can use Infrastructure Visibility to identify and troubleshoot problems that affect application performance such as server failures, JVM crashes, and hardware resource utilization. There are three classes of Infrastructure Visibility functionality:

    • You use the Standalone Machine Agent to collect basic hardware metrics. One Machine Agent license is included with each App Agent license that you purchase. You can deploy this Machine Agent only on the same machine where the App Agent is installed. The functionality provided by the Machine Agent includes:
      • Basic hardware metrics from the server OS. For example, %CPU and memory utilization, disk and network I/O
      • Custom metrics passed to the Controller by extensions
      • Run remediation scripts to automate your runbook procedures. You can optionally configure the remediation action to require human approval before the script is started.
      • Run JVM Crash Guard to monitor JVM crashes and optionally run remediation scripts
    • If you have a Server Visibility license, the Standalone Machine Agent provides the following additional functionality:
      • Extended hardware metrics such as machine availability, disk/CPU/virtual-memory utilization, and process page faults 
      • Monitor application nodes that run inside Docker containers and identify container issues that impact application performance
      • The Tier Metric Correlator, which enables you to identify load and performance anomalies across all nodes in a tier
      • Monitor internal or external HTTP and HTTPS services
      • Group servers together so that health rules can be applied to specific server groups
      • Define alerts that trigger when certain conditions are met or exceeded based on monitored server hardware metrics
    • Network Visibility monitors traffic flows, network packets, TCP connections, and TCP ports. Network Agents leverage the APM intelligence of App Server Agents to identify the TCP connections used by each application. Network Visibility includes the following functionality:

      • Detailed metrics about dropped/retransmitted packets, TCP window sizes (Limited / Zero), connection setup/teardown issues, high round trip times, and other performance-impacting issues  
      • Network Dashboard that highlights network KPIs (Key Performance Indicators) for tiers, nodes, and network links
      • Right-click dashboards for tiers, nodes, and network links that enable quick drill-downs from transaction outliers to network root causes
      • Automatic mapping of TCP connections with application flows
      • Automatic detection of intermediate load balancers that split TCP connections
      • Diagnostic mode for collecting advanced diagnostic information for individual connections

    Application Monitoring and Browser Real User Monitoring

    When you add End-User Monitoring to Application Performance Management, you can correlate business transaction performance to the user experience for those transactions. See Correlate Business Transactions for Browser RUM.

    If server app agents run on the applications that serve your browser applications, you can further configure the app server agents to inject JavaScript agent into the code that runs on the browser. Access the settings to configure injection in the Applications Configuration page. For more information, see Automatic Injection of the JavaScript Agent and Assisted Injection.  

    Application Monitoring and Database Visibility

    In Application Monitoring, a database called by an instrumented node is considered a remote service. You can get a significant amount of information on the interaction between the application node and database, but not from the database server perspective. When using Database Visibility with Application Monitoring, you can drill down to detailed database performance information directly from application flow maps. For more information see Access Database Visibility from Application Monitoring Views

    Application Monitoring and Analytics

    For those times when tracing application code does not provide enough clues to track down the cause of a problem, AppDynamics provides visibility into the transaction logs that can be correlated to specific business transaction requests. Log correlation visibility requires a license for both Transaction Analytics and Log Analytics. See Business Transaction and Log Correlation.


    Sv translation
    languageja
    Appd tocbox
    Width260px

    On this page:

    Table of Contents
    maxLevel2
    minLevel2

    Related pages:

    ハンズオントライアルを通じて AppDynamics の基本を学び終えたら、AppDynamics がアプリケーション環境をどのようにモデル化するかの学習に進むことができます。このモデルは、AppDynamics でパフォーマンス情報を整理して提示するためのフレームワークとして機能します。  

    アプリケーションモデルの概要

    典型的なアプリケーション環境は、アプリケーションのユーザーの要求に応えるためにさまざまな形で相互作用する各種のコンポーネントで構成されます。

    • アプリケーションサーバーで稼働するWebアプリケーション
    • データベースおよびその他データ保存
    • メッセージキューやキャッシュなどのリモートサービス

    AppDynamicsアプリエージェントは、最も一般的なアプリケーションフレームワークやサービスを自動検出します。アプリケーションの検出と構成のための組み込み設定を使用して、エージェントがアプリケーションのデータやメトリックを収集してフローマップを構築します。

    フローマップは、アプリケーション コンポーネント間のデータのフローを理解しやすくするために、アプリケーションのコンポーネントを視覚的に表現します。たとえば、次のような単純なeコマースアプリケーションのビジネストランザクションフローマップは、Webサービス、メッセージキュー、およびデータベース間のデータのフローを示します。

    自動検出を使用して、AppDynamicsの各種機能をすぐに試してみることができます。AppDynamicsの理解が深まり、ご使用の環境に固有の領域を識別したら、アプリケーションモデルを精緻化することができます。

    ビジネストランザクション

    AppDynamics のモデルでは、ビジネストランザクションはリクエスト(ユーザリクエストの場合が最も多い)に対するデータ処理フローを表します。実際には、以下のようなリクエストに応えるために、アプリケーション内のさまざまなコンポーネントが相互作用してサービスを提供します。

    • eコマースアプリケーションの場合、ユーザーのログイン、商品の検索、カートへの商品の追加
    • コンテンツポータルの場合、スポーツ、ビジネス、エンターテイメントニュースのコンテンツに対するユーザーリクエスト
    • 株取引アプリケーションの場合、株価の取得や株式の売買などのオペレーション

    AppDynamicsアプリエージェントは、ビジネストランザクションへのエントリポイントとしてアプリケーションへのリクエストを検出します。ユーザーログインなどの同様のリクエストは、同じビジネストランザクションの複数のインスタンスとして扱われます。エージェントはリクエストデータにタグを付け、リクエストがWebサーバーからデータベースやその他のインフラストラクチャコンポーネントに渡される過程でその経路を追跡します。AppDynamics は、ビジネストランザクションを処理する各ティアのパフォーマンスメトリックを収集します。

    ビジネストランザクションのパフォーマンスモニタリングの枠組みはAppDynamicsによって提供されるため、開発者はユーザーの視点でアプリケーションコンポーネントのパフォーマンスに集中することができます。コンポーネントがすぐに利用可能な状態か、それともパフォーマンスの問題を抱えているかをすばやく識別できます。たとえば、ログイン、チェックアウト、または自分のデータの表示をユーザーが実行できるかどうか確認できます。ユーザへの応答時間や、問題が起きた場合の原因を確認できます。 

    ビジネス アプリケーション

    ビジネスアプリケーションとは、AppDynamics モデルにおけるトップレベルのコンテナです。ビジネスアプリケーションには一連の関連するサービスおよびビジネストランザクションが含まれます。

    AppDynamicsの小規模なデプロイメントの場合、環境を構築するには1つのビジネスアプリケーションで問題ありません。より大きなデプロイメントを行う場合には、環境モデルを複数のビジネスアプリケーションに分割することができます。

    ビジネスアプリケーション管理の最良の方法は、ご使用の環境により異なります。しかし、コントローラUIでのロールベースのアクセス制御はビジネスアプリケーションによって決定されるため、ほとんどのケースでの最も重要な考慮事項は、組織の作業チームを反映するようにビジネスアプリケーションを構造化することです。

    ノード

    AppDynamics モデルにおけるノードは、アプリケーション環境でモニタリングの対象となるサーバまたは JVM に対応します。ノードはモデル化される環境の最小単位です。エージェントのタイプに応じて、ノードは個々のアプリケーションサーバ、JVM、CLR、PHP アプリケーション、Apache Web サーバに対応している場合があります。 

    各ノードはAppDynamicsモデル内で識別されます。エージェントを構成するときに、エージェントがコントローラにデータをレポートする際のノード、ティア、ビジネスアプリケーションの名前を指定します。 

    ティア

    ティアは AppDynamics モデルにおける 1 つの単位であり、1 つ以上のノードをグループ化したもので構成されます。ティアをどのように編成するかは、対象の環境の概念モデルによって異なります。

    ティアは多くの場合、同じ冗長サーバのセットをグループ化するために使用されます。ただし、これは厳密な要件ではありません。同じノードかどうかにかかわらず、パフォーマンスメトリックを 1 つの単位として扱いたい任意のノードのセットを 1 つのティアにグループ化することができます。

    唯一の制限として、1 つのティア内のすべてのノードが同じタイプである必要があります。.NET ノードと Java ノードのように、タイプの異なるエージェントを 1 つのティアに混在させることはできません。 

    ビジネスアプリケーションにおけるトラフィックは、フローマップではパフォーマンスメトリックの注釈が付いた線で示されるように、ティア間を流れます。

    AppDynamicsモデルでは:

    • 単一のティア内でノード間が作用しあうことはありません
    • アプリケーションエージェントのノードは2つ以上のティアに属することができません

    バックエンド

    バックエンドとは、AppDynamics エージェントによってインストゥルメント化されないが、ビジネス トランザクション インスタンスの処理には参加するコンポーネントのことです。バックエンドは Web サーバ、データベース、メッセージキュー、またはその他のサービスです。

    エージェントは、インストゥルメント化コード(終了コール)からサービスへの呼び出しを認識します。サービスがインストゥルメント化されず、コールのトランザクションコンテキストを継続できない場合、エージェントは当該サービスがバックエンドコンポーネントであると判断します。エージェントはトランザクションコンテキストをバックエンドの応答で認識し、トランザクションをその時点からフォローします。

    パフォーマンス情報はバックエンドコールに利用可能です。バックエンドによって処理されるトランザクションの一部について詳細なトランザクション分析を行うには、データベース、Webサービス、またはその他のアプリケーションをインストゥルメント化する必要があります。

    他のAppDynamicsモジュールとの統合

    このセクションでは、その他の AppDynamics APM プラットフォーム製品が Application Monitoring と連携して、アプリケーションの正常性とユーザエクスペリエンスを完全かつ全面的に可視化するしくみについて説明します。

    Application MonitoringとInfrastructure Visibility 

    Infrastructure Visibilityは、アプリケーションの実行基盤であるハードウェアとネットワークをエンドツーエンドで可視化します。Infrastructure Visibilityを使用して、サーバーの障害、JVMのクラッシュ、ハードウェアリソースの使用率など、アプリケーションのパフォーマンスに影響を及ぼす問題を識別し、トラブルシューティングを行うことができます。Infrastructure Visibilityの機能には3つのクラスがあります。

    • Standalone Machine Agent を使用して、基本的なハードウェアメトリックを収集します。アプリエージェントのライセンスを 1 つ購入するごとに、マシンエージェントのライセンスが 1 つ付属します。このマシンエージェントは、アプリエージェントがインストールされているマシンと同じマシンにしかデプロイできません。マシンエージェントで提供される機能は次のとおりです。
      • サーバーのOSからの基本的なハードウェアメトリック(例:CPU使用率、メモリ使用量、ディスクおよびネットワークI/O)
      • 拡張機能からコントローラに渡されるカスタムメトリック
      • ランブックの手順を自動化するための修復スクリプトを実行する。オプションで、スクリプトが開始される前に人間による承認を義務付けるように修復アクションを構成できます。
      • JVM Crash Guardを実行してJVMクラッシュをモニタリングし、オプションで修復スクリプトを実行する
    • サーバの可視性ライセンスを持っている場合はスタンドアロン マシン エージェントで次の追加機能が提供されます。
      • マシンの可用性、ディスク/CPU/仮想メモリ使用量、プロセスページフォールトなどの拡張ハードウェアメトリック
      • Dockerコンテナ内で動作するアプリケーションノードをモニタリングし、アプリケーションのパフォーマンスに影響を及ぼすコンテナの問題を識別する
      • Tier Metric Correlatorによってティアの全ノードの負荷とパフォーマンスの異常を識別する
      • 内部または外部のHTTPおよびHTTPSサービスをモニタリングする
      • 特定のサーバーグループに正常性ルールを適用できるようにサーバーをグループ化する
      • モニタリング対象のサーバーハードウェアメトリックに基づいて、特定の条件が満たされたか超過したときにトリガーするアラートを定義する
    • Network Visibility では、トラフィックフロー、ネットワークパケット、TCP 接続、および TCP ポートがモニタされます。ネットワークエージェントはアプリサーバーエージェントのAPMインテリジェンスを利用して、各アプリケーションが使用するTCP接続を識別します。Network Visibilityには以下の機能が含まれます。

      • ドロップ/再送信されたパケット、TCPウィンドウサイズ(有限/ゼロ)、接続セットアップ/ティアダウンの問題、長いラウンドトリップ時間、パフォーマンスに影響するその他の問題に関する詳細なメトリック
      • ティア、ノード、ネットワークリンクのKPI(重要パフォーマンス指標)をハイライトするネットワークダッシュボード
      • ティア、ノード、ネットワークリンクのダッシュボードを右クリックして、トランザクションの異常値からネットワークの根本原因にクイックドリルダウンが可能
      • TCP接続とアプリケーションフローの自動マッピング
      • TCP接続を分割する中間ロードバランサの自動検出
      • 個々の接続の高度な診断情報を収集するための診断モード

    Application MonitoringとBrowser Real User Monitoring

    End-User MonitoringをApplication Performance Managementに追加すると、ビジネストランザクションのパフォーマンスを、それらのトランザクションのユーザーエクスペリエンスと相関させることができます。詳細については、「Correlate Business Transactions for Browser RUM」を参照してください。

    ブラウザアプリケーションにサービスを提供するアプリケーション上でサーバーアプリエージェントを実行する場合、ブラウザ上で実行されるコードにJavaScriptエージェントをインジェクトするために、アプリサーバーエージェントをさらに構成することができます。インジェクションを構成するための設定にはApplications Configurationページからアクセスします。詳細については、「Automatic Injection of the JavaScript Agent」および「Assisted Injection」を参照してください。  

    Application MonitoringとDatabase Visibility

    Application Monitoringでは、インストゥルメント化されたノードによって呼び出されたデータベースはリモートサービスとみなされます。アプリケーションノードとデータベース間の相互作用に関しては多くの情報が得られますが、データベースサーバーの観点からの情報は得られません。Database VisibilityをApplication Monitoringと併用すると、アプリケーションフローマップから直接、詳細なデータベースパフォーマンス情報にドリルダウンできます。詳細については、「Access Database Visibility from Application Monitoring Views」を参照してください。 

    Application MonitoringとAnalytics

    アプリケーションコードをたどっても問題の原因を解明する十分な手がかりを得られない場合、AppDynamicsは特定のビジネストランザクションリクエストと相関する可能性があるトランザクションログを可視化します。ログの相関性の可視化には、Transaction AnalyticsとLog Analytics両方のライセンスが必要になります。「ビジネストランザクションとログの相関性」を参照してください。