Download PDF
Download page Apacheエージェントのインストール.
Apacheエージェントのインストール
ご使用の Apache HTTP サーバー、IBM HTTP サーバー(IHS)、または Oracle HTTP サーバーでパフォーマンスをモニターするには、Apache、IHS、または OHS を実行するサーバーに Apache エージェントをインストールします。エージェントは Apache サーバーをインストゥルメント化し、Java プロキシにパフォーマンスデータを送信します。Java プロキシはコントローラにデータを送信します。
マシンエージェントで 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" コマンドで設定する必要があります。 - Linux の場合、モジュールに
libstdc++.so.6
との依存関係があるかどうかを確認します。libstdc++.so.5 モジュールを使用した Apache Web サーバにおける考慮事項を参照してください。これは IHS および OHS を使用している場合によく見られます。 - AIX の依存関係については、「AIX での Apache エージェントのインストールの前提条件」を参照してください。
- エージェントを実行するマシンのロケール環境が正しく設定されていることを確認します。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を超えないようにしてください。
- Getting Started ウィザードまたは https://accounts.appdynamics.com/downloads から Apache エージェントをダウンロードします。
/opt
にエージェントを解凍します。tar -xzvf appdynamics-sdk-native-nativeWebServer-<64bit | 32bit>-<alpine-linux | linux>-<version>.tgz -C /opt
CODEgzip -c appdynamics-sdk-native-nativeWebServer-64bit-aix-<version>.tgz | tar xvf - -C /opt
CODEエージェントは、
/opt/appdynamics-
sdk-nativ
e にインストールされます。これが、<agent_install_directory>
です。複数のエージェントをインストールする場合は、各エージェントに対して個別にインストールディレクトリを作成する必要があります。- Apache、IHS、または OHS の所有者に、ログディレクトリ(
<agent_install_directory>/logs
)への読み取りと書き込みの権限を付与します。 次のコマンドを実行して、インストール前に必要なすべてのライブラリをロードします。
.bashrc
ファイルにこのコマンドを追加することをお勧めします。これにより、LD_LIBRARY_PATH
を何度もエクスポートする必要がなくなります。export LD_LIBRARY_PATH=<agent_installation_folder>/sdk_lib/lib
CODEinstall.sh
を実行。このスクリプトはエージェントプロキシをインストールします。<agent_install_directory>/install.sh
CODEエージェントが Apache インスタンスをモニタするには、プロキシを起動する必要があります。複数の Apache インスタンスをモニターする場合、各プロキシを手動で起動し、すべての Apache インスタンスに対して
AppDynamicsLaunchProxy
をOFF
に設定します。次に、エージェント構成ファイルを作成してエージェントを構成する作業に移動。
cURL のインストールについては、「Download AppDynamics Software」を参照してください。
Apacheエージェントの構成
Apache、IHS、または OHS 構成ディレクトリに、
appdynamics_agent.conf
などの Apache Web サーバーエージェントの構成ファイルを作成します。低下要因になっています。touch /etc/<path_to_webserver_dir>/conf/appdynamics_agent.conf
appdynamics_agent.conf
ファイルには、次の設定を行います。複数のエージェントをインストールする場合は、各エージェントの appdynamics_agent.conf ファイルを編集し、エージェント ロード モジュールを配置するディレクトリを指定します。各 Apache インスタンスが専用のappdynamics_agent.conf
ファイルを参照し、各ファイルで個別にエージェント インストール ディレクトリが指定されていることを確認します。
同じ Apache エージェントを共有する複数の Apache Web サーバインスタンスの場合は、プロキシプロセスごとに AppdynamicsProxyCommDir
ディレクティブを使用して設定された Comm dir が異なっていることを確認します。また、各サーバ構成ファイル(appdynamics_agent.conf
)のノード名も異なっていることを確認します。
LoadFile
:Splunk AppDynamics エージェント SDK 共有ライブラリを読み込む。エージェントは/opt
にインストールされ、設定は/opt/appdynamics-
sdk-native/sdk_lib/lib/libappdynamics_native_sdk.so
であることが前提になります。Alpine Linux では、このパラメータを必ず設定してください。このパラメータは、AIX 環境には適用されません。
例:LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libzmq.so.5 LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libappdynamics_native_sdk.so
CODElibappdynamics_native_sdk.so には、libzmq および libuuid に対するランタイム依存関係があります。これらのライブラリは、ibappdynamics_native_sdk.so と同じディレクトリにあります。
LoadModule
:Splunk 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 モジュールを使用します。AIX で Apache エージェントを実行するには、最小バージョンとして Apache 2.4 が必要です。
Apache 2.4の例:
LoadModule appdynamics_module /opt/appdynamics-sdk-native/WebServerAgent/Apache/libmod_appdynamics.so
CODEApache 2.2の例:
LoadModule appdynamics_module /opt/appdynamics-sdk-native/WebServerAgent/Apache/libmod_appdynamics22.so
CODEAppDynamicsEnabled
:Web サーバーのモニタリングを有効にするには、これを追加して ON に設定する必要があります。それ以外では、デフォルトでモニタリングは無効になります。 {{2}}は特定の属性を識別し、 {{3}} はこの属性に割り当てる新規の値を指定します。AppDynamicsEnabled ON
CODEモニタリングを無効にするには、
OFF
に設定するか Apache 構成ファイルから Splunk AppDynamics モジュールのinclude
ステートメントを削除します(「AppDynamics で使用する Apache サーバーの構成」を参照)。
AppDynamicsControllerHost
:接続するコントローラのホスト名または IP アドレス。必須。
例AppDynamicsControllerHost mycontroller.saas.appdynamics.com
CODEAppDynamicsControllerPort
:コントローラ HTTP(S) ポート。SaaS の場合、HTTPS では 443、HTTP では 80 を使用します。オンプレミスの場合、HTTP のデフォルトは 8090、HTTPS のデフォルトは 8181 です。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。デフォルトを使用しない場合は自分で構成します。HTTPS を使用している場合、SSL 設定(AppDynamicsControllerSSL
)も設定する必要があります。
例:AppDynamicsControllerPort 80
CODEAppDynamicsControllerSSL
:設定すると、SSL を介してコントローラに接続。デフォルトはOFF
です。SSL 接続を有効にするにはON
に設定し、さらにAppDynamicsControllerPort
を HTTPS ポートに設定します。
例:AppDynamicsControllerSSL OFF
CODEAppDynamicsAccountName
:Splunk AppDynamics のアカウント名。オンプレミスのコントローラの場合、コントローラの> License でログイン情報を調べます。SaaS コントローラの場合、ログイン情報は Splunk AppDynamics の Welcome メールに記載されています。必須。
例:AppDynamicsAccountName MyCompany
CODEAppDynamicsAccessKey
:Splunk AppDynamics アカウントアクセスキー。オンプレミスのコントローラの場合、コントローラの> License でログイン情報を調べます。SaaS コントローラの場合、ログイン情報は Splunk AppDynamics の Welcome メールに記載されています。必須です。
例:AppDynamicsAccessKey zd8yjh5yuy5k
CODEAppDynamicsProxyHost
:プロキシ サーバのホスト名または IP アドレス。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。エージェントがHTTPプロキシサーバーを介してコントローラに接続する場合に使用。AppDynamicsProxyport
:プロキシサーバのポート。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。エージェントがHTTPプロキシサーバーを介してコントローラに接続する場合に使用。AppDynamicsApplication
:Splunk AppDynamics のアプリケーション名。詳細については、Overview of Application Monitoringを参照してください。必須です。
例:AppDynamicsApplication MyWS2App
CODEAppDynamicsTier
:Splunk AppDynamics の階層名。詳細については、Overview of Application Monitoringを参照してください。必須です。
例:AppDynamicsTier MyWS2
CODEAppDynamicsNode
:Splunk AppDynamics のノード名。詳細については、Overview of Application Monitoringを参照してください。ノード名は必須で、各ノード名は一意である必要があります。
例:AppDynamicsNode WS2_1
CODEAppDynamicsTlsProtocol
:エージェントがコントローラとの通信に使用する TLS バージョンです。デフォルト値は TLS 1.2 です。TLS 1.3 を指定できます。TLS 1.3 以外の入力は無視され、デフォルト値と見なされます。
例:AppDynamicsTlsProtocol TLSv1.3
CODEAppDynamicsCustomTags
:キーと値のペアのセットとしてのユーザー定義のカスタムタグ。コントローラにこれらのカスタムタグを使用できます。これらのタグは、ノードに適用されます。複数のキーと値のペアをカンマで区切って定義できます。例:AppDynamicsCustomTags CustomTagName=value1,CustomTagName2=value2
CODE
#Load the Cisco AppDynamics SDK.
LoadFile /opt/appdynamics-sdk-native/sdk_lib/lib/libzmq.so.5
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
#Cisco 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
プロキシの起動
プロキシを実行する前に、次のコマンドを実行して、インストール前に必要なすべてのライブラリをロードします。
.bashrc
ファイルにこのコマンドを追加することをお勧めします。これにより、LD_LIBRARY_PATH
を何度もエクスポートする必要がなくなります。export LD_LIBRARY_PATH=<agent_installation_folder>/sdk_lib/lib
CODE- プロキシを手動で起動するには、Apache ワーカースレッドのユーザ ID を使用して
runSDKProxy.sh
を実行します。
nohup <agent_install_directory>/runSDKProxy.sh --jre-dir=<jre-path> >>/dev/null 2><agent_install_dir>/logs/proxy.out &
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>
コマンドを使用して、正しいバージョンを参照していることを確認してください。
その他のディレクティブ
サポートからの指示がない限り、次のオプションのディレクティブを設定する必要があります。
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
CODEAppDynamicsTraceAsError-
ON
にすると、トレースポイントがエラーとして Apache ログ(デフォルトではerror_log
)に書き込まれます。デフォルトはOFF
です。オンプレミスの場合、HTTPのデフォルトは8090、HTTPSのデフォルトは8181です。
たとえば、AppDynamicsTraceAsError OFF
CODEAppDynamicsReportAllInstrumentedModules-
OFF
にすると、エージェントは Apache 要求処理のHANDLER
段階で実行されるモジュールのみを報告します。ON にすると、エージェントは Apache 要求処理のすべての段階のモジュールを報告します。デフォルトはOFF
です。次に例を示します。
AppDynamicsReportAllInstrumentedModules OFF
CODEAppDynamicsLaunchProxy-
ON
にすると、エージェントは起動時に自動でプロキシを開始します。OFF
の場合は、手動でプロキシを起動する必要があります。システムで任意のコマンドを使用して、ログローテーションなどの Apache のグレースフルリスタートを実行する場合、またはシステムで重い負荷が発生した場合は、このプロパティをOFF
に設定する必要があります。デフォルトはOFF
です。
たとえば、AppDynamicsLaunchProxy OFF
CODEアプリケーション エージェントがコントローラへの接続を妨げられるプロキシの問題を調べて解決する方法の詳細については、「Dynamic Language Agent Proxy」を参照してください。
デバッグのためにプロキシを手動で起動する場合があります。たとえば別のプロキシルートディレクトリまたはランタイムディレクトリを設定するため、または追加のデバッグ情報を出力するためなどです。
A
ppDynamicsProxyJreDir-
JRE パスを指定します。このパラメータは、AIX プラットフォームにのみ適用されます。
AppDynamicsLaunchProxy
が有効になっている場合、このパラメータは必須になります。ただし、AppDynamicsLaunchProxy
が無効になっている場合、JRE パスは破棄されます。この場合は、プロキシを手動で起動する必要があります。「プロキシの起動」を参照してください。AppDynamicsRequestCacheCleanupInterval
- 要求キャッシュが Java プロキシによってクリーンアップされるまでのタイムアウト(ミリ秒)。プロキシは、エージェントからのすべての要求を受け取り、処理するためにこれらの要求を保存するキューで構成されます。高負荷シナリオでは、このメッセージキューが 1 分以内に膨大なキャッシュを持つことがあります。したがって、予防策として、デフォルト値が 60 秒のクリーンアップタイマーを使用できます。長いトランザクションをモニタするには、クリーンアップ間隔を長くしますが、キャッシュまたはメモリの使用率が高いことに注意する必要があります。次に例を示します。
AppDynamicsRequestCacheCleanupInterval 120000
CODEプロキシを手動で実行する場合は、launch proxy コマンドの実行時に次のフラグを追加します。
--req-cache-cleanup-interval=120000
CODEAppDynamicsProxyCommDir-
エージェントが Splunk AppDynamics ノードを起動するために使用するドメイン制御ソケットを含むディレクトリへのパス。デフォルトは<agent_install_directory>/logs/appd-sdk
です。この設定を変更する場合は、ディレクトリパスが 107 文字を超えないようにしてください。これは、Linux でのソケットファイル名サイズの制限値です。ディレクトリパスが長すぎる場合、エージェントが起動しようとするとエラーメッセージが表示されます。AppDynamicsProxyCommDir <agent_install_directory>/proxy/altcommdir
CODE- 機密データおよび特権情報のフィルタリングについては、「機密データのフィルタ」を参照してください。
AppDynamicsで使用するApacheサーバーの構成
サーバー構成に Apache エージェント構成の include を追加します。Splunk AppDynamics モジュールが、インストゥルメント化するモジュールの後にロードされることを確認します。エージェントの後にロードされたモジュールは、インストゥルメンテーションおよびモニタリングから除外されます。たとえば、該当する構成ファイル(
httpd.conf
(CentOS)、apache2.conf
(Ubuntu および Debian)、httpd.conf_64
(AIX))の最終行として次の行を追加します。#Include Cisco AppDynamics Apache Agent Configuration Include conf/appdynamics_agent.conf
CODEWeb サーバの複数のインスタンスを実行している場合は、そのインスタンスの構成ファイル名と一致するように
.conf Include
パスを変更します。例:#Include Cisco AppDynamics Apache Agent Configuration. Include conf/appdynamics_agent1.conf
CODEWebサーバーを再起動します。CentOSのApacheの場合:
apachectl restart
CODE- Webサーバーに負荷を適用してインストゥルメンテーションをアクティブ化します。
Apache エージェントは、受信 HTTP コールをビジネストランザクションとして自動的に検出します。ロードされたモジュールは、バックエンドとして検出されます。コントローラにログインして、モニタリングを開始します。
Cisco AppDynamics 階層への仮想ホストのマッピング
仮想ホストを構成することで、Apach Webサーバーの管理者は、エンドユーザーの視点では別のWebサイトに見えるようなエントリポイントとして機能する単一のApache Webサーバーインスタンスを持つことができます。
Splunk 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 サーバーエージェントは、リクエスト内の仮想ホストサーバーとポートに基づき、受信リクエストを Splunk AppDynamics コンテキストに関連付けます。
Apache からマルチホストを行うために仮想ホストを使用する代わりに、管理者は、インスタンスごとに異なる httpd.conf
ファイルを使用して、Apache Web サーバの複数のインスタンスを実行できます(Ubuntu および Debian では、このファイルは apache2.conf
と呼ばれます)。この場合、各インスタンスのエージェント構成ファイルを作成して Apache Web サーバーをインストゥルメント化し、対応するインスタンスの httpd.conf
ファイルに各構成ファイルを追加します。「Apache エージェントの構成」を参照してください。
アプリケーション エージェントの一意のホスト ID の設定
アプリケーション エージェントに一意のホスト ID を設定するには、次のコマンドを runProxy
ファイルに追加します。
set -- "$@" -Dappdynamics.agent.uniqueHostId="<your-unique-host-id>"
たとえば、次のコマンドを <agent_install_directory>/proxy/runProxy
ファイルに追加できます。
set -- "$@" -Dappdynamics.agent.logs.dir=${logsDir}
set -- "$@" -Dcomm=${proxyCommunicationDir}
set -- "$@" -DagentType=${agentType}
set -- "$@" -Dappdynamics.agent.uniqueHostId="<your-unique-host-id>"
set -- "$@" -Dappdynamics.agent.runtime.dir=${proxyRuntimeDir}
set -- "$@" -Dlog4j.ignoreTCL=true
set -- "$@" -XX:MaxPermSize=${maxPermSize}
エージェントのアップグレード後に、一意のホスト ID を再度設定する必要があります。