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

    Related pages:

    Instrumenting an application adds the AppDynamics application agent (app agent) into the runtime process of the application. This page gives you an overview of installing agents in the application environment. 

    Agent Installation Quick Start

    The Getting Started Wizard in the AppDynamics Controller walks you through the steps to download and configure an agent for your application. This section gives you an overview of how to use the wizard. 

    The wizard produces a fully configured agent, including a node identity. Accordingly, it is intended to be run for each application instance you want to monitor until you have the hang customizing the configuration manually. 

    Before Starting

    Before installing an agent, make sure that:

    • The agent supports your application environment. See App Server Supported Environments.
    • You can access the application host with a user account that has sufficient privileges to install the agent and—for certain installation types—restart the application.
    • The application host has network connectivity to the Controller. Proxies or firewalls on the network between the agent and Controller may require additional configuration.

    Use the Getting Started Wizard

    After verifying the requirements, follow the workflow as guided by the wizard:  

    1. Open the wizard from the home page in the controller UI by clicking Getting Started.
    2. Enter the configuration values for the application instance as described in the wizard. You name the node and indicate the tier and business application to which it will belong. If you are not sure of the best values to use, you can use temporary names and change them later.
    3. When finished, download the agent. How you download the agent varies by agent type. In most cases, the agent comes as a ZIP file that you extract and install in the startup routine of your server. For other types of agents, you may need to modify the instrumented source code, for example, by including the agent library. The wizard walks you through it for each agent type.
    4. Install the agent on your app server.  
    5. Apply load to your application. If you are instrumenting a production application, this will happen with customer interaction. Otherwise, create some test load on your application. The agent instruments the application code and reports metrics back to the Controller.
    6. View your application in the Application Dashboard. For example: 
       

    The wizard makes it easy to perform a basic installation of the agent with minimally required settings, such as the Controller host and port, SSL, application name, and tier name. For advanced options or more complicated scenarios, you need to perform a manual installation of the agent. For more information, see the agent-specific link in the following section.    

    Agent Installation by Type

    For detailed installation information by agent type, see the following topics: 

    For automated deployment guidelines, see Controller Deployment

    Anchor
    tier-node-naming
    tier-node-naming
    Tier and Node Naming Guidelines

    The maximum length of a tier name is 100 characters and the maximum length of a node name is 225 characters for Linux and 500 characters for all other operating systems. In your tier, node and application names, you should avoid certain special characters. The characters you can use are listed on the Tiers and Nodes page.

    Generally, node names should be unique. However, nodes that reside on different tiers and different machines (hosts) can have duplicate node names.

    Within a business application, node names should always be unique in the following use cases:

    • If the nodes reside on the same tier, but on different machines
    • If the nodes reside on the same machine, but on different tiers
    • Node names and machine names must unique. When a node is registered to a controller, it is associated with the machine it is on, and cannot be moved to another machine without changing the node name. 

    If the nodes names are the same in the aforementioned use cases, the nodes will not register or report successfully.

    Info

    Nodes on proxy-based agents can have duplicate names on the same tier and same machine.


    To rename an application, see Business Applications.

    For node naming conventions by agent type, see the installation page for that agent, such as Node.js Agent or PHP Agent.

    Anchor
    appagentbandwidth
    appagentbandwidth
    App Agent Network Bandwidth Usage

    The following guidelines can help you estimate how much bandwidth overhead will be added to your environment by deploying AppDynamics agents.

    Keep in mind that the exact bandwidth required for a deployment varies greatly depending on the nature of your application, the agent configuration, and the AppDynamics features you use. The best way to determine the bandwidth overhead is to test the AppDynamics deployment in a staging environment that mirrors as closely as possible the live operating environment. 

    1. The approximate bandwidth used by a single Java Agent with the default configuration is five to eight kilobytes per second. 
    2. Scaling of additional agents is linear. That is, if the average bandwidth usage for an app agent in a given deployment is 5 kilobytes, adding 10 means that bandwidth usage will be 5 × 10, or 50 kilobytes.   
    3. While the average bandwidth used is five to eight kbytes per second, agents send data to the Controller in bursts rather than as a steady stream of data. When testing bandwidth usage, to determine the actual kbytes per second used by an agent, you need to observe and average out traffic over the course of at least several minutes. 
    4. When testing bandwidth usage in the environment, keep in mind that different types of tiers will generate a different amount of load. For instance, a database tier tends to generate more traffic between the agent and Controller than an application server tier. For the best possible estimate, the test should take this into account.

    Agent License Considerations

    For agent-based license units—including APM, database monitoring, and server monitoring—licenses are allocated to the first agents that register with the Controller up to the licensed limit. For example, with five agent licenses, the first five agents that connect to the Controller are licensed.  

    Agent licenses are not bound to a particular machine or application. Therefore, a transfer of an agent-based license can be done simply by shutting down the application that runs the licensed agent—uninstalling the agent if the application will need to be restarted—and starting up the new application with the newly installed agent. Once the agent disconnects, a license unit is freed for the second agent.

    For application monitoring agents (Java, .NET, Node.JS, and so on), a license validation cycle runs every five minutes. It causes the agents to connect and validate that available license units are not exceeded. Historical usage data is captured during this cycle and stored as five-minute usage data. Every hour, the five-minute usage data is rolled up in hour usage data, which includes data on license unit usage. The five-minute data is purged after a few hours.


    Sv translation
    languageja
    Appd tocbox

    On this page:

    Table of Contents
    maxLevel2
    minLevel2

    Related pages:

     

    Appd noprint

    Search App Agent Installation topics:

    Page Tree Search

    アプリケーションをインストゥルメント化すると、AppDynamics アプリケーション エージェント(アプリエージェント)がアプリケーションのランタイムプロセスに追加されます。このページでは、アプリケーション環境でのエージェントのインストールの概要を示します。 

    エージェントのインストールのクイックスタート

    AppDynamicsコントローラのGetting Startedウィザードは、アプリケーション用のエージェントをダウンロードして構成する手順を案内します。このセクションでは、ウィザードの使用方法の概要を示します。 

    ウィザードによって、ノードIDを含め完全に構成されたエージェントが生成されます。したがって、手動での構成カスタマイズに慣れるまでの間は、モニタリングするアプリケーション インスタンスごとにウィザードを実行することが想定されています。 

    はじめに

    エージェントをインストールする前に、以下のことを確認してください。

    • ご使用のアプリケーション環境にエージェントが対応していること。「アプリサーバの対応環境」を参照してください。
    • エージェントのインストール(および、インストールのタイプによってはアプリケーションの再起動)を実行する権限があるユーザーアカウントを使用してアプリケーションホストにアクセスできること。
    • アプリケーションホストがコントローラにネットワーク接続できること。エージェントとコントローラ間のネットワークのプロキシまたはファイアウォールに対して、追加の構成が必要になる場合があります。

    Getting Startedウィザードの使用

    要件を確認したら、ウィザードの指示に従ってワークフローを進めます。

    1. コントローラUIのホームページでGetting Startedをクリックしてウィザードを開きます。
    2. ウィザードの説明に従って、アプリケーション インスタンスの構成値を入力します。ノードに名前を付けて、ノードが属するティアとビジネスアプリケーションを指定します。使用する最適値がわからない場合は、一時的に名前を付けて後で変更することができます。
    3. 終了したら、エージェントをダウンロードします。エージェントのダウンロード方法はエージェントのタイプによって異なります。ほとんどの場合、エージェントはZIPファイルであり、これをサーバーのスタートアップルーチンで解凍およびインストールします。その他のタイプのエージェントでは、エージェントライブラリをインクルードするなどして、インストゥルメント化済みのソースコードに変更を加えることが必要な場合があります。エージェントのタイプによってウィザードでの手順が異なります。
    4. アプリサーバにエージェントをインストールします。  
    5. アプリケーションに負荷を適用します。実稼動アプリケーションのインストゥルメント化の場合、顧客とやり取りしながら行います。そうでない場合は、アプリケーションへのテスト負荷を作成します。エージェントはアプリケーションコードをインストゥルメント化し、メトリックのレポートをコントローラに返します。
    6. アプリケーション ダッシュボードでアプリケーションを表示します。例:

    ウィザードでは、エージェントが AppDynamics コントローラと通信するために必要な最低限の情報(コントローラホストとポート、SSL、アプリケーション名およびティア名)が提供されます。高度なオプションやより複雑なシナリオの場合は、エージェントの手動インストールを実行する必要があります。詳細については、以下のセクションでエージェント固有のリンクを参照してください。    

    タイプ別のエージェントのインストール

    エージェントタイプ別の詳細なインストール情報については、以下のトピックを参照してください。

    自動デプロイのガイドラインについては、「Controller Deployment」を参照してください。 

    Anchor
    tier-node-naming
    tier-node-naming
    ティアとノードの命名ガイドライン

    ティア名は最大 100 文字、ノード名は最大 225 文字(Linux の場合)または 500 文字(その他のオペレーティングシステムの場合)です。一部の特殊文字はティア名、ノード名、アプリケーション名に使用できません。使用できる文字の一覧は「Tiers and Nodes」ページで確認できます。

    一般に、ノード名は一意である必要があります。ただし、異なるティアの異なるマシン(ホスト)に存在するノードはノード名が重複してもかまいません。

    以下のユースケースでは、ビジネスアプリケーション内でノード名は常に一意である必要があります

    • ノードが同じティアの異なるマシンに存在する場合
    • ノードが同じマシンの異なるティアに存在する場合
    • ノード名とマシン名は一意である必要があります。ノードがコントローラに登録されると、ノードは現在のマシンに関連付けられ、ノード名を変更しない限り別のマシンに移動できません。 

    前述のユースケースでノード名が同じである場合、ノードは正しく登録またはレポートされません。

    Info

    プロキシベースのエージェント上のノードは、同じティアと同じマシン上で名前が重複してもかまいません。


    アプリケーションの名前を変更するには、「Business Applications」を参照してください。

    エージェントタイプ別のノード命名規則については、Node.js AgentPHP エージェントなど、各エージェントのインストールページを参照してください。

    Anchor
    appagentbandwidth
    appagentbandwidth
    アプリエージェントのネットワーク帯域幅使用

    AppDynamicsエージェントをデプロイすることで環境の帯域幅オーバーヘッドがどれくらい増加するかは、以下のガイドラインに従って予測できます。

    デプロイに必要な正確な帯域幅は、アプリケーションの性質、エージェントの構成、使用する AppDynamics の機能によって大きく異なることに留意してください。帯域幅オーバーヘッドを確認する最良の方法は、AppDynamics のデプロイを実稼働環境に限りなく近いステージング環境でテストすることです。 

    1. デフォルトで構成された Java エージェント 1 つが使用する帯域幅は、毎秒約 5 〜 8 キロバイトです。 
    2. 追加エージェントのスケーリングは線形です。つまり、特定のデプロイでアプリエージェントの平均帯域幅使用量が 5 キロバイトの場合、10 個のエージェントを追加すると、帯域幅の使用量は 5 × 10 = 50 キロバイトになります。   
    3. 使用される平均帯域幅は毎秒 5 〜 8 キロバイトですが、エージェントは安定したデータストリームではなく、バーストでコントローラにデータ送信します。エージェントが使用する実際のキロバイト/秒を判断するために帯域幅使用量をテストする場合、少なくとも数分間はトラフィックを監視し、平均化する必要があります。 
    4. ご使用の環境で帯域幅の使用量をテストする場合、ティアのタイプによって負荷生成量が異なることに留意してください。例えば、データベースティアでは、アプリケーションサーバーティアよりもエージェントとコントローラ間のトラフィックが多く生成される傾向があります。予測精度をできるだけ高めるために、テストではこのことを考慮してください。

    エージェントのライセンスに関する考慮事項

    エージェントベースのライセンスユニット(APM、データベースモニタリング、サーバー監視を含む)では、コントローラに登録された最初のエージェントから上限までにライセンスが付与されます。例えば、エージェントライセンスを5つお持ちの場合、コントローラに接続しているエージェント5つまでにライセンスが付与されます。  

    エージェントライセンスは特定のマシンやアプリケーションに縛られるものではありません。そのため、エージェントベースのライセンスの譲渡は、ライセンスされたエージェントを実行するアプリケーションをシャットダウンし(アプリケーションを再起動する必要がある場合、エージェントをアンインストールします)、新しくインストールされたエージェントで新しいアプリケーションを起動するだけです。エージェントが切断されると、ライセンスユニットは2番目のエージェントに対して解放されます。

    アプリケーション モニタリング エージェント(Java、.NET、Node.JS など)では、ライセンス検証サイクルが 5 分ごとに実行されます。このサイクルでは、エージェントは接続を行い、利用可能なライセンスユニットを超過していないことを検証します。このサイクル中に使用状況の履歴データがキャプチャされ、5 分間の使用状況データとして保存されます。この 5 分間の使用状況データは毎時、時間単位の使用状況データにロールアップされ、このデータにはライセンスユニットの使用状況に関するデータが含まれます。5 分間データは数時間後にパージされます。