Apacheエージェントのインストール

ご使用の Apache HTTP サーバ、IBM HTTP サーバ（IHS）、または Oracle HTTP サーバでパフォーマンスをモニタするには、Apache、IHS、または OHS を実行するサーバ に AppDynamics Apache エージェントをインストールします。エージェントは Apache サーバをインストゥルメント化し、Java プロキシにパフォーマンスデータを送信します。Java プロキシは AppDynamics コントローラにデータを送信します。

マシンエージェントで Apache モニタリング拡張を使用している場合は、引き続き使用できます。Apache エージェントをインストールした後、マシンエージェントを再起動する必要がある場合があります。

はじめに

Web サーバのバージョンとオペレーティングシステムがサポートされていることを確認してください。詳細については、対応するApache Webサーバーを参照してください。 

また、エージェントをインストールするマシンに関する次の要件も確認してください。 

• ワーカープロセスおよびスレッドを生成する際に Apache が使用しているのと同じユーザおよびグループで、インストールを実行します。
• エージェントが実行されているマシンで random または urandom が適切に設定されていることを確認します。これは、Apache エージェントの特定の機能が乱数生成に依存しているためです。
  適切でない場合、ログファイルやディレクトリが作成されない、エージェントからコントローラに何も報告されないなどの動作が急に発生する可能性があります。
• オープンファイル記述子の ulimit 設定が設定されていることを確認し、Apache ワーカープロセスまたはプロキシタスクがこの制限を超えないようにして、リソースの競合を回避します。 **
• プロキシまたは Apache ワーカープロセスに必要な userid のオープンファイル記述子の制限を確認します。
  MPM_Worker モードの場合、次の計算を使用してファイル記述子の数を設定する必要があります。1024 + ServerLimit + (2 * ServerLimit * ThreadsPerChild)。
  他のすべてのモードでは、次の計算を使用してファイル記述子の数を設定する必要があります。(Total number of concurrently active Apache workers * 2) + 1024.
  オープンファイル記述子の設定は /etc/security/limits.conf にありますが、設定を有効にするにはホストを再起動するか、現在のユーザ ID のセッションに対してのみ "ulimit -n" コマンドで設定する必要があります。
• モジュールに libstdc++.so.5 との依存関係があるかどうかを確認します。libstdc++.so.5 モジュールを使用した Apache Web サーバにおける考慮事項を参照してください。これは IHS および OHS を使用している場合によく見られます。
• エージェントを実行するマシンのロケール環境が正しく設定されていることを確認します。Apache エージェントの一部の機能はロケールに依存しているため、ロケール環境が正しくないとクラッシュが発生する可能性があります。
  エージェントの要件に基づいて、次のいずれかを選択し、環境変数を次のように設定することができます。

export LANG=en_US.UTF-8
export LANGUAGE=$LANG
export LC_ALL=$LANG

または

export LANG=en_US.UTF-8

または

export LC_ALL=C

Apacheエージェントのダウンロードとインストール

パフォーマンスと安定性を保証するため、各Apacheインスタンスに対して1つのエージェントをインストールしてください。エージェント当たりのApacheインスタンス数が2を超えないようにしてください。

1. Getting Started ウィザードまたは https://accounts.appdynamics.com/downloads から Apache エージェントをダウンロードします。 

2. /opt にエージェントを解凍します。

   tar -xzvf ./appdynamics-sdk-native.<version>.tar.gz -C /opt

   CODE

   エージェントは、/opt/appdynamics-sdk-native にインストールされます。これが、<agent_install_directory> です。複数のエージェントをインストールする場合は、各エージェントに対して個別にインストールディレクトリを作成する必要があります。

3. Apache、IHS、または OHS の所有者に、ログディレクトリ（<agent_install_directory>/logs）への読み取りと書き込みの権限を付与します。

4. install.sh を実行。このスクリプトはエージェントプロキシをインストールします。 

   <agent_install_directory>/install.sh 

   CODE

5. エージェントが Apache インスタンスをモニタするには、プロキシを起動する必要があります。複数の Apache インスタンスをモニタする場合、各プロキシを手動で起動し、すべての Apache インスタンスに対して AppDynamicsLaunchProxy を NO に設定します。 

   次に、エージェント構成ファイルを作成してエージェントを構成する作業に移動。

cURL のインストールについては、「AppDynamicsソフトウェアのダウンロード」を参照してください。

Apacheエージェントの構成

1. Apache、IHS、または OHS 構成ディレクトリに、appdynamics_agent.conf などの AppDynamics Apache Web サーバエージェントの構成ファイルを作成します。低下要因になっています。
   

   touch /etc/<path_to_webserver_dir>/conf/appdynamics_agent.conf

2. appdynamics_agent.conf ファイルには、次の設定を行います。複数のエージェントをインストールする場合は、各エージェントの appdynamics_agent.conf ファイルを編集し、エージェント ロード モジュールを配置するディレクトリを指定します。各 Apache インスタンスが専用の appdynamics_agent.conf ファイルを参照し、各ファイルで個別にエージェント インストール ディレクトリが指定されていることを確認します。

同じ Apache エージェントを共有する複数の Apache Web サーバインスタンスの場合は、プロキシプロセスごとに AppdynamicsProxyCommDir ディレクティブを使用して設定された Comm dir が異なっていることを確認します。また、各サーバ構成ファイル（appdynamics_agent.conf）のノード名も異なっていることを確認します。

• • LoadFile：AppDynamics エージェント SDK 共有ライブラリを読み込む。エージェントは /opt にインストールされ、設定は
    /opt/appdynamics-sdk-native/sdk_lib/lib/libappdynamics_native_sdk.so であることが前提になります。必須です。
    例：

    LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libzmq.so.3
    LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libuuid.so.1
    LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libappdynamics_native_sdk.so

    CODE

    libappdynamics_native_sdk.so には、libzmq および libuuid に対するランタイム依存関係があります。これらのライブラリは、ibappdynamics_native_sdk.so と同じディレクトリにあります。

  • LoadModule：AppDynamics Apache エージェント共有ライブラリを読み込む。該当するモジュールは、Apache 2.4 の場合は libmod_appdynamics.so、Apache 2.2 の場合は libmod_appdynamics22.so です。必須。 

    

    OHS および IHS 7.x ～ 8.x の場合は Apache 2.2 モジュールが必要です。IHS 9.x では Apache 2.4 モジュールを使用します。

    Apache 2.4の例：

    LoadModule appdynamics_module /opt/appdynamics-sdk-native/WebServerAgent/Apache/libmod_appdynamics.so

    CODE

    Apache 2.2の例：

    LoadModule appdynamics_module /opt/appdynamics-sdk-native/WebServerAgent/Apache/libmod_appdynamics22.so

    CODE

  • AppDynamicsEnabled：必須で、Web サーバのモニタリングを有効にする場合は ON に設定する。それ以外では、デフォルトでモニタリングは無効になります。 {{2}}は特定の属性を識別し、 {{3}} はこの属性に割り当てる新規の値を指定します。

    AppDynamicsEnabled ON

    CODE

    モニタリングを無効にするには、OFF に設定するか、Apache 構成ファイルから AppDynamics モジュールの include ステートメントを削除します（「AppDynamics で使用する Apache サーバの構成」を参照）。 
     

  • AppDynamicsControllerHost：接続する AppDynamics コントローラのホスト名または IP アドレス。必須。
    例

    AppDynamicsControllerHost mycontroller.saas.appdynamics.com

    CODE

  • AppDynamicsControllerPort：コントローラ HTTP(S) ポート。SaaS の場合、HTTPS では 443、HTTP では 80 を使用します。オンプレミスの場合、HTTP のデフォルトは 8090、HTTPS のデフォルトは 8181 です。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。デフォルトを使用しない場合は自分で構成します。HTTPS を使用している場合、SSL 設定（AppDynamicsControllerSSL）も設定する必要があります。
    例：

    AppDynamicsControllerPort 80

    CODE

  • AppDynamicsControllerSSL：設定すると、SSL を介してコントローラに接続。デフォルトは OFF です。SSL 接続を有効にするには ON に設定し、AppDynamicsControllerPort も HTTPS ポートに設定します。
    例:

    AppDynamicsControllerSSL OFF

    CODE

  • AppDynamicsAccountName：AppDynamicsのアカウント名。オンプレミスのコントローラの場合、コントローラの [ > License] でログイン情報を調べます。SaaS コントローラの場合、ログイン情報は AppDynamics の Welcome メールに記載されています。必須。
    例:

    AppDynamicsAccountName MyCompany

    CODE

  • AppDynamicsAccessKey：AppDynamicsアカウントアクセスキー。オンプレミスのコントローラの場合、コントローラの [ > License] でログイン情報を調べます。SaaS コントローラの場合、ログイン情報は AppDynamics の Welcome メールに記載されています。必須です。
    例:

    AppDynamicsAccessKey zd8yjh5yuy5k

    CODE

  • AppDynamicsProxyHost：プロキシ サーバのホスト名または IP アドレス。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。エージェントがHTTPプロキシサーバーを介してコントローラに接続する場合に使用。

  • AppDynamicsProxyport：プロキシサーバのポート。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。エージェントがHTTPプロキシサーバーを介してコントローラに接続する場合に使用。

  • AppDynamicsApplication：AppDynamics のアプリケーション名。詳細については、アプリケーションモニタリングの概要を参照してください。必須です。
    例：

    AppDynamicsApplication MyWS2App

    CODE

  • AppDynamicsTier：AppDynamics のティア名。詳細については、アプリケーションモニタリングの概要を参照してください。必須です。
    例：

    AppDynamicsTier MyWS2

    CODE

  • AppDynamicsNode：AppDynamics のノード名。詳細については、アプリケーションモニタリングの概要を参照してください。ノード名は必須で、各ノード名は一意である必要があります。
    例：

    AppDynamicsNode WS2_1

    CODE

#Load the AppDynamics SDK.
LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libzmq.so.3
LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libuuid.so.1
LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libappdynamics_native_sdk.so
 
#Load the Apache Agent. In this example for Apache 2.4
LoadModule appdynamics_module /opt/appdynamics-sdk-native/WebServerAgent/Apache/libmod_appdynamics.so

AppDynamicsEnabled On

#AppDynamics Controller connection.
AppDynamicsControllerHost mycontroller.saas.appdynamics.com
AppDynamicsControllerPort 80
AppDynamicsControllerSSL OFF

#Account credentials
AppDynamicsAccountName MyCompany
AppDynamicsAccessKey zd8yjh5yuy5k

#Configure Controller connection through an HTTP proxy server.
#AppDynamicsProxyHost <proxy host>
#AppDynamicsProxyPort <proxy port>

#Business application, tier, node
AppDynamicsApplication MyApache2App
AppDynamicsTier Apache2
AppDynamicsNode Apache2_1

プロキシの起動

プロキシを手動で起動するには、Apache ワーカースレッドのユーザ ID を使用して runSDKProxy.sh を実行します。

nohup <agent_install_directory>/runSDKProxy.sh >>/dev/null 2><agent_install_dir>/logs/proxy.out &

システムの起動時に自動的にプロキシを起動するUnix システムサービスを作成することを推奨します。

プロキシでは、適切な（64 ビットか 32 ビット）場所に libstdc+6 ライブラリがあることが前提となっています。32 ビット Apache HTTP サーバの実行をサポートする 64 ビット OS に Apache エージェントをインストールする場合は、ダウンロードした Apache エージェントが 32 ビットであり、libstdc+6 ライブラリも 32 ビットであることを確認してください。64 ビットと 32 ビット両方のバージョンのライブラリがある場合は、runSDKProxy を実行する前に export LD_PRELOAD=<path to 32bit library> コマンドを使用して、正しいバージョンを参照していることを確認してください。

その他のディレクティブ

AppDynamics サポートからの指示がない限り、次のオプションのディレクティブを設定する必要があります。

• AppDynamicsBackendNameSegments- バックエンドの命名で表示される URL セグメントの数。これは、Apache がリバースプロキシサーバ（別名ゲートウェイサーバ）として動作している場合に、mod_proxy を介してルーティングされる要求にのみ適用できます。appdynamics_agent.conf ファイル内のバックエンドの命名のルール構成を指定します。デフォルト値は 0 で、リクエスト URL の IP アドレスのみが表示されます。値を 2 に設定すると、最初の 2 つのセグメントと IP アドレスが表示されます。そのため、http://1.1.1.1/services/admin/abc にプロキシする要求の場合、バックエンドは http://1.1.1.1/services/admin という名前になります。

  次に例を示します。

AppDynamicsBackendNameSegments 2

• AppDynamicsResolveBackends- Apache モジュールバックエンドがコントローラ UI に表示される方法を制御します。ONの場合、Apacheモジュールのメトリックはダウンストリームティアまたはバックエンドの一部として表示します。モジュールバックエンドはフローマップには表示されません。
  OFF の場合、Apache モジュールバックエンドは、そのメトリックを含むフローマップに表示されます。「Apache モジュール」を参照してください。
  デフォルトは ON です。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。
  たとえば、
  

  AppDynamicsResolveBackends OFF

  CODE

• AppDynamicsTraceAsError- ON にすると、トレースポイントがエラーとして Apache ログ（デフォルトでは error_log）に書き込まれます。デフォルトは OFF です。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。
  たとえば、

  AppDynamicsTraceAsError OFF

  CODE
• AppDynamicsReportAllInstrumentedModules- OFF にすると、エージェントは Apache 要求処理の HANDLER 段階で実行されるモジュールのみを報告します。ON にすると、エージェントは Apache 要求処理のすべての段階のモジュールを報告します。デフォルトは OFF です。

  次に例を示します。

  AppDynamicsReportAllInstrumentedModules OFF

  CODE

• AppDynamicsLaunchProxy- ON にすると、エージェントは起動時に自動でプロキシを開始します。OFF の場合は、手動でプロキシを起動する必要があります。システムで任意のコマンドを使用して、ログローテーションなどの Apache のグレースフルリスタートを実行する場合、またはシステムで重い負荷が発生した場合は、このプロパティを OFF に設定する必要があります。デフォルトは OFF です。
  たとえば、
  

  AppDynamicsLaunchProxy OFF

  CODE

  アプリケーション エージェントがコントローラへの接続を妨げられるプロキシの問題を調べて解決する方法の詳細については、「動的言語エージェントプロキシ」を参照してください。

  デバッグのためにプロキシを手動で起動する場合があります。たとえば別のプロキシルートディレクトリまたはランタイムディレクトリを設定するため、または追加のデバッグ情報を出力するためなどです。
  

  
  

• AppDynamicsRequestCacheCleanupInterval- 要求キャッシュが Java プロキシによってクリーンアップされるまでのタイムアウト（ミリ秒）。プロキシは、エージェントからのすべての要求を受け取り、処理するためにこれらの要求を保存するキューで構成されます。高負荷シナリオでは、このメッセージキューが 1 分以内に膨大なキャッシュを持つことがあります。したがって、予防策として、デフォルト値が 60 秒のクリーンアップタイマーを使用できます。長いトランザクションをモニタするには、クリーンアップ間隔を長くしますが、キャッシュまたはメモリの使用率が高いことに注意する必要があります。

  次に例を示します。

  
  

  AppDynamicsRequestCacheCleanupInterval 120000

  CODE
  

  プロキシを手動で実行する場合は、launch proxy コマンドの実行時に次のフラグを追加します。

  --req-cache-cleanup-interval=120000

  CODE

  


• AppDynamicsProxyCommDir- エージェントが AppDynamics ノードを起動するために使用するドメイン制御ソケットを含むディレクトリへのパス。デフォルトは <agent_install_directory>/logs/appd-sdk です。この設定を変更する場合は、ディレクトリパスが 107 文字を超えないようにしてください。これは、Linux でのソケットファイル名サイズの制限値です。ディレクトリパスが長すぎる場合、エージェントが起動しようとするとエラーメッセージが表示されます。
  

  AppDynamicsProxyCommDir <agent_install_directory>/proxy/altcommdir

  CODE
• 機密データおよび特権情報のフィルタリングについては、「機密データのフィルタ」を参照してください。

AppDynamicsで使用するApacheサーバーの構成

1. サーバ構成に AppDynamics Apache エージェント構成の include を追加します。AppDynamics モジュールが、インストゥルメント化するモジュールの後にロードされることを確認します。AppDynamics エージェントの後にロードされたモジュールは、インストゥルメンテーションおよびモニタリングから除外されます。たとえば、httpd.conf ファイルの最後の行として次のものを追加します。このファイルは Ubuntu および Debian では、apache2.conf と呼ばれます。

   #Include AppDynamics Apache Agent Configuration
   Include conf/appdynamics_agent.conf

   CODE

   Web サーバの複数のインスタンスを実行している場合は、そのインスタンスの構成ファイル名と一致するように .conf Include パスを変更します。例：

   #Include AppDynamics Apache Agent Configuration.
   Include conf/appdynamics_agent1.conf

   CODE
   

   4.x 以下のバージョンでは、Apache スレッドの制限値（ServerLimit、ThreadsPerChild、ThreadLimit など）を設定している場合、並行スレッド制限が 4095 を超えないようにする必要があります。バージョン 20.x 以降では、この制限は適用されません。ユーザは、使用可能なリソースに応じて、システムで許可されている数のスレッドを作成できます。

2. Webサーバーを再起動します。CentOSのApacheの場合：

   apachectl restart

   CODE
3. Webサーバーに負荷を適用してインストゥルメンテーションをアクティブ化します。
   
   

AppDynamics Apache エージェントは、受信 HTTP コールをビジネストランザクションとして自動的に検出します。ロードされたモジュールは、バックエンドとして検出されます。AppDynamics コントローラにログインして、モニタリングを開始します。

AppDynamicsティアに仮想ホストをマッピング

仮想ホストを構成することで、Apach Webサーバーの管理者は、エンドユーザーの視点では別のWebサイトに見えるようなエントリポイントとして機能する単一のApache Webサーバーインスタンスを持つことができます。

AppDynamicsアプリケーションモデルでは、通常Apache Webサーバーで構成された各仮想ホストをそれぞれのティアとして表すことが理論的です。これは、環境における論理的モデルをよりよく表すと同時に、大規模なアプリケーション環境をプロキシサーバーに送るApache Webサーバーのビジネストランザクションに対する制限を急速に超えてしまうリスクを軽減します。

さまざまな仮想ホストを異なるティアに関連付けるには、AppDynamicsApplicationContext ディレクティブを仮想ホスト構成に追加し、アプリケーション、ティア、およびノードの名前を引数として次のように指定します。

AppDynamicsApplicationContext <application> <tier> <node>  

例：

Listen 80
<VirtualHost *:80>
    DocumentRoot "/www/example1"
    ServerName site1.example.com
    ...
    AppDynamicsApplicationContext MyApp site1.example.com:80 node01
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/www/example2"
    ServerName site2.example.org
    ...
    AppDynamicsApplicationContext MyApp site2.example.org:80 node01
</VirtualHost>

上の例では、ティア名は仮想マシンの ServerName とポート番号の組合せです。ティア名にServerNameとポート番号を含めることは必須ではありませんが、どの仮想マシンがビジネストランザクションを作成しているのかを識別するのに便利です。ティア名は仮想マシンの目的を最もよく表すものにすることをお勧めします。

Apache Webサーバーエージェントは、リクエスト内の仮想ホストサーバーとポートに基づき、受信リクエストをAppDynamicsコンテキストに関連付けます。

Apache からマルチホストを行うために仮想ホストを使用する代わりに、管理者は、インスタンスごとに異なる httpd.conf ファイルを使用して、Apache Web サーバの複数のインスタンスを実行できます（Ubuntu および Debian では、このファイルは apache2.conf と呼ばれます）。この場合、各インスタンスの AppDynamics エージェント構成ファイルを作成して Apache Web サーバをインストゥルメント化し、対応するインスタンスの httpd.conf ファイルに各構成ファイルを追加します。「Apache エージェントの構成」を参照してください。