Deployment Support

関連ページ：


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

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

はじめに

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

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

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

または

export LANG=en_US.UTF-8
CODE

または

export LC_ALL=C
CODE

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

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

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

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

    tar -xzvf appdynamics-sdk-native-nativeWebServer-<64bit | 32bit>-<alpine-linux | linux>-<version>.tgz -C /opt
    CODE 
    gzip -c appdynamics-sdk-native-nativeWebServer-64bit-aix-<version>.tgz | tar xvf - -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 を OFF に設定することを推奨します。 

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

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

Apacheエージェントの構成

  1. Apache、IHS、または OHS 構成ディレクトリに、appdynamics_agent.conf などの Splunk 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 になります。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
    CODE

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

  • LoadModule：AppDynamics Apache エージェント共有ライブラリを読み込みます。正しいモジュールは、libmod_appdynamics.so（Apache 2.4 の場合）および libmod_appdynamics22.so（Apache 2.2 の場合）です。必須。 

    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
    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 ステートメントを削除します（「Cisco AppDynamics で使用する Apache サーバーの構成」を参照）。 
     

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

    AppDynamicsControllerHost mycontroller.saas.appdynamics.com
    CODE

  • AppDynamicsControllerPort：コントローラの HTTP（S）ポート。オンプレミスの場合、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] でログイン情報を確認します。必須。
    例:

    AppDynamicsAccountName MyCompany
    CODE

  • AppDynamicsAccessKey：AppDynamics アカウントのアクセスキー。オンプレミスのコントローラの場合、コントローラの > [License] でログイン情報を確認します。必須。
    例:

    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

  • AppDynamicsTlsProtocol：エージェントがコントローラとの通信に使用する TLS バージョン。デフォルト値は TLS 1.2 です。TLS 1.3 を指定できます。TLS 1.3 以外の入力は無視され、デフォルト値と見なされます。
    例：

    AppDynamicsTlsProtocol TLSv1.3
    CODE
  • AppDynamicsCustomTags：キーと値のペアのセットとしてのユーザー定義のカスタムタグ。コントローラにこれらのカスタムタグを使用できます。これらのタグは、ノードに適用されます。複数のキーと値のペアをカンマで区切って定義できます。例：
    AppDynamicsCustomTags CustomTagName=value1,CustomTagName2=value2
    CODE
    これらのタグは、コントローラへのエージェント登録リクエストに含まれます。新しいタグまたは変更されたタグをコントローラに送信するには、エージェントを再起動する必要があります。詳細については、「カスタムタグ」を参照してください。

#Load the 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 #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
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> コマンドを使用して、正しいバージョンを参照していることを確認してください。

その他のディレクティブ

Splunk 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
CODE

  • 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

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

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

     

  • AppDynamicsProxyJreDir：JRE パスを指定します。 

    このパラメータは、AIX プラットフォームにのみ適用されます。AppDynamicsLaunchProxy が有効になっている場合、このパラメータは必須になります。ただし、AppDynamicsLaunchProxy が無効になっている場合、JRE パスは破棄されます。この場合は、プロキシを手動で起動する必要があります。「プロキシの起動」を参照してください。

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

    次に例を示します。


    AppDynamicsRequestCacheCleanupInterval 120000
    CODE

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

    --req-cache-cleanup-interval=120000
    CODE

     

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

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

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

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

    #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

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

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

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

Splunk 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 と呼ばれます）。この場合、各インスタンスの Splunk AppDynamics エージェント構成ファイルを作成して 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}
CODE

エージェントのアップグレード後に、一意のホスト ID を再度設定する必要があります。