アプリケーションサーバーエージェントのインストール

Related pages:

アプリケーションをインストゥルメント化すると、AppDynamics アプリケーションエージェント（アプリエージェント）がアプリケーションのランタイムプロセスに追加されます。このページでは、アプリケーション環境でのエージェントのインストール方法について、概要を説明します。

アプリケーションサーバエージェントのユースケースはすべて、他の導入オプションと同様に AWS Outpost でサポートされます。

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

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

ウィザードによって、ノード ID を含む完全に構成されたエージェントが生成されます。モニタするアプリケーションインスタンスごとに、または設定を手動でカスタマイズする方法を理解するまで、ウィザードを実行する必要があります。

エージェントをインストールする前に

次の点を確認します。

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

Getting Startedウィザードの使用

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

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

ウィザードにより、必要最低限の情報（コントローラホストとポート、SSL、アプリケーション名、階層名など）を使用して基本的なエージェントのインストールを簡単に実行できます。高度なオプションやより複雑なシナリオの場合は、エージェントの手動インストールを実行する必要があります。詳細については、以下のセクションでエージェント固有のリンクを参照してください。

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

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

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

アプリケーション、階層およびノードの命名ガイドライン

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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