このコンポーネントは、オンプレミス展開でのみ使用できます。SaaS 展開は AppDynamics によって管理されます。

このページでは、Enterprise Console を使用してイベントサービスを管理する方法について説明します。 次のタスクはすべてGUIまたはCLIで実行できます。

イベントサービスの起動および停止

イベントサービスは、データベースの可視性 モジュールが使用する内部データストレージエンジンです。データベースモニタリングを使用するには、イベントサービスを起動する必要があります。

イベントサービスは、インストール後自動的に起動します。

Linuxの場合

Linuxで、以下のコマンドを実行してイベントサービスを起動します。

bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service --job start
CODE

次のコマンドを実行してイベントサービスを停止します。

bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service --job stop
CODE
Windowsの場合

Windows で、次のコマンドを実行してイベントサービスを起動します。

bin/platform-admin.exe cli submit-job --platform-name <platform_name> --service events-service --job start
CODE

次のコマンドを実行してイベントサービスを停止します。

bin/platform-admin.exe cli submit-job --platform-name <platform_name> --service events-service --job stop
CODE

クラスタノードの正常性のモニタリング

新しいデプロイメントについては、イベントサービスクラスタの正常性を注意深くモニタリングすること、特にディスク消費をモニタリングすることが大切です。

次のコマンドを使用して、Enterprise Console GUI またはコントローラマシンのコントローラページから、クラスタのステータスを確認できます。

bin/platform-admin.sh show-events-service-health  

結果には、考えられる問題とその問題を解決するために必要な手順が示されます。たとえば、利用可能なディスクが少ない場合、解決するためにクラスタにノードを追加します。

以下は、考えられるエラーと修復手順です。 

エラー説明修復 
クラスタの容量が不足イベントサービスのJavaプロセスのヒープサイズが80%を上回っているイベントサービスノードを追加する
ディスクサイズが残り30％以下識別されたノードのディスクサイズが30%以下に落ちた イベントサービスノードを追加する
イベントサービスに到達不可能だがホストには到達可能識別されたノード上でイベントサービスのプロセスが適切に機能していない ノードを再起動する
マシンに到達不可能マシンが停止、切断状態またはエラーが起こっている可能性がある

マシンを再起動する。それでも改善しない場合は、クラスタからノードを削除しなければならない場合がある。

クラスタの再起動が必要クラスタの再起動が必要な状態として識別されるクラスタを再起動する
クラスタサイズが2イベントサービスクラスタが2つ以上のノードを要求するノードを追加する

クラスタの拡張

Enterprise Console の GUI または CLI を使用して、Linux 上のイベントサービスクラスタを水平方向にスケーリングできます。増加する作業負荷に対応できるよう既存のデプロイメントを拡張するには、ノードを追加するだけです。 

始める前に、新しいクラスタマシンを準備します。「イベントサービス要件」の説明に従って、システム要件を確認し、環境を整えます。 

クラスタの新しいマシンが、既存クラスタメンバーと同じ SSH 対応ユーザーアカウントを持つようにしてください。 

システムの準備ができたら、ノードを追加するためのコマンドを実行します。

bin/platform-admin.sh add-events-service-nodes --hosts host1  host2  host3

あるいは、新しいノードのホスト名をファイルとして渡します。  

bin/platform-admin.sh add-events-service-nodes --host-file=/home/appduser/hosts.txt

コマンド（たとえば hosts.txt）に渡すファイルには、内部 DNS のホスト名または追加するノードの IP アドレスが含まれている必要があります。クラスタの既存のノードをリストする必要はありません。 これらのホストはプラットフォームに所属する必要があります。ホストをプラットフォームに追加する方法の詳細については、「Enterprise Consoleの管理」を参照してください。

ロードバランサルールを変更し、ルーティングルールに新しいクラスタメンバーを含むようにしてください。詳細については、「ロードバランスイベントサービストラフィック」を参照してください。 

ノードを再起動する

Enterprise Console GUIまたはCLIを使用して、ノードを再起動できます。

システムの準備ができたら、ノードを再起動するためのコマンドを実行します。

bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service --job restart-node --args nodeActionHost=<node_name>

ここで <node_name> は次のコマンドからのノードのホスト名。

bin/platform-admin.sh list-nodes --platform-name <platform_name> --service events-service

クラスタを再起動する

Enterprise Console GUIまたはCLIを使用して、クラスタを再起動できます。

システムの準備ができたら、クラスタノードを再起動するためのコマンドを実行します。

bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service -job restart-cluster

ノードの削除または置換

uninstall-events-service コマンドはすべてのクラスタノードからイベントサービスのソフトウェアとデータを削除します。コントローラおよびイベントサービスはデータベースを共有しているため、イベントサービスをインストールするために Enterprise Console を実行したコントローラインスタンスをアンインストールする場合は、コントローラをアンインストールする前にこのコマンドを使用してイベントサービスをアンインストールする必要があります。   

remove-events-service-node コマンドは、ホスト名で指定した 1 つのノードから、イベント サービス ソフトウェアとデータを削除します。クラスタ内に少なくとも 4 つのノードがある場合にのみこのコマンドを使用します。3 つのノードを持つクラスタからのイベントサービス削除には対応していません。--node コマンドラインパラメータを使用して、削除するノードを特定します。 

ノードを削除したら、ロードバランサのルールを調整して古いクラスタメンバーを削除してください。詳細については、「ロードバランスイベントサービストラフィック」を参照してください。 

クラスタ展開でロードバランサを使用していない場合は、インストール時にコントローラにレポートする最初のプライマリノードの接続設定は、コントローラに対してイベントサービスを特定するコントローラ設定に書き込まれることに注意してください。その状況でプライマリノードを削除する場合は、削除したプライマリノードがコントローラ接続設定（例：appdynamics.on.premise.event.service.url）でイベントサービスの宛先 URL として指定されているノードであるかどうかを確認し、該当する場合はその設定を調整します。詳細については、「イベントサービスへの接続」を参照してください。

次のガイドラインに注意してください。

  • 結果として生じるクラスタサイズが2となるノードは削除できない。 
  • 3 つ以上のノードで構成されるクラスタは、単一ノードのイベントサービスにサイズを減少することはできません。 

remove-events-service-node コマンドは、ホスト名で指定した 1 つのノードから、イベント サービス ソフトウェアとデータを削除します。クラスタ内に少なくとも 4 つのノードがある場合にのみこのコマンドを使用します。3 つのノードを持つクラスタからのイベントサービス削除には対応していません。--node コマンドラインパラメータを使用して、削除するノードを特定します。 

このコマンドで、引数で指定されたノードを削除します。

bin/platform-admin.sh remove-events-service-node  --node 10.0.100.51

上記のコマンドを使用してプライマリノードを削除しようとすると、Enterprise Console が、プライマリノードを削除しようとしていることを通知し、操作をキャンセルします。出力で示されるとおり、-f force フラグを使用してコマンドを再度実行することで、プライマリノードの削除を進めることができます。プライマリノードを削除すると、クラスタは既存のデータノードから新しいプライマリノードを選択します。選択プロセスには数秒かかることがあり、その間新しいイベントを処理することはできません。サービスが短時間中断しても影響が少ない時に、このオペレーションを実行してください。 

到達不能なノードがあって削除したいが、上記の制限により削除できない場合、代わりに置換することができます。

このコマンドで、引数で指定された古いノードを新しいノードに置換します。

bin/platform-admin.sh submit-job --service events-service --job replace-node --args originalNode=<old_host_address> newNode=<new_host_address>
  • クラスタからイベントサービスノードを削除した後、EUM プロパティファイル analytics.accountAccessKey ではなく、コントローラ admin.jsp とイベントサービスのプロパティファイルで値 appdynamics.es.eum.key が変更されていることを確認できます。 
  • コントローラとイベントサービスでキー値が変更されたかどうかを確認し、キー値を EUM プロパティファイル analytics.accountAccessKey に置き換えます。

イベントサービスで SSL を使用できるようにする

Enterprise Console CLI を使用して、イベントサービスで SSL を使用できるようにすることができます。JKS 形式のキーストアファイル、パスワード、およびキーストアのエイリアスが必要です。キーストアを作成するための詳細な手順については、「証明書の作成と CSR の生成」を参照してください。 

  1. Enterprise Console にログインします。

    bin/platform-admin.sh login --user-name <admin_username> --password <admin_password>
    TEXT

  2. 正常にログインしたら、イベントサービスの enable-ssl ジョブを送信し、キーストアファイルへのパス、キーストアのパスワード、およびキーストアのエイリアスを提供します。

    bin/platform-admin.sh submit-job --platform-name <platform_name> --service events-service --job enable-ssl --args keystorePath=<path-to-keystore-jks-file> keystorePassword=<keystore_password>  keystoreAlias=<keystore_alias>
    TEXT

  3. SSL が有効になっていることを確認します。

     curl -k -v -X GET https://<events-service-domain>:9080/_ping
    TEXT

  4. cURL コマンドの出力には、TLS ハンドシェイクと HTTP ステータス 200 が表示されます。

    ...

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):
...
< HTTP/1.1 200 OK
< Date: Fri, 10 May 2019 00:13:49 GMT
< X-Content-Security-Policy: default-src 'self'
...
    TEXT

イベントサービスログの収集

Enterprise Consoleは、クラスタのノードからログを収集できます。次のコマンドはノードログを取得して、Enterprise Consoleのログとともにバンドルします。

bin/platform-admin.sh retrieve-events-service-logs

コマンドが完了すると、スクリプトを実行した場所に events-service.log.zip という名前の ZIP ファイルが作成されます。その後、アーカイブを抽出してトラブルシューティングを行うか、トラブルシューティングに役立つアーカイブを AppDynamics 担当者に送信することができます。何らかの理由で Enterprise Console がログを取得するのにクラスタノードの 1 つと接続できなかった場合、アーカイブに含まれるログファイルに接続エラーが書き込まれます。  

SSHキーファイルの変更

初期インストール後、Enterprise Console がノードマシンにアクセスできるよう PEM ファイルをアップデートしなければならない場合があります。 

そのためには、「イベントサービスホストの準備」におけるパスワード不要の SSH ログインの構成に関する議論にあるように、PEM ファイルを作成し、次のコマンドを使用して新しい PEM ファイルをインストールします。  

bin/platform-admin.sh set-user-credentials --ssh-key-file newkeyfile.pem

変更はすぐに有効になります。 

イベントサービスのアップグレード

Enterprise Consoleを使用して、イベントサービスソフトウェアを導入されているノード上でローリングアップグレードできます。詳細については、「Enterprise Consoleを使用したイベントサービスのアップグレード」を参照してください。

イベントサービスデプロイメントをアップグレードするための一般的な手順は、以下の通りです。 

  1. コントローラをアップグレードします。（Enterprise Consoleを使用するコントローラのアップグレード を参照してください）。

  2. 次のコマンドを使用して、イベントサービスノードにアップグレードを適用する。 

     bin/platform-admin.sh upgrade-events-service

Enterprise Console は、イベントサービスが現行のコントローラバージョンに対して最新の状態であるかを確認し、そうでなければアップデートを実行します。 

AppDynamicsによるイベントサービスノードのモニタリング

AppDynamicsエージェントを使用してイベントサービスノードまたはクラスタをモニタリングし、トラブルシューティング用の診断情報を生成できます。次のステップはワークフローの概要です。

  1. AppDynamics ダウンロードセンターから次のエージェントをダウンロードします。
    • Javaエージェント
    • スタンドアロンマシンエージェント
  2. クラスタ内の各ノードに、両方のエージェントをインストールします。まずJavaエージェント、次にスタンドアロンマシンエージェントをインストールします。
  3. クラスタの各ノードで、 JavaエージェントのVMオプションを更新します。
    1. 次のファイルをテキストエディタで開きます。
      <controller_home>/platform_admin/events-service/conf/events-service.vmoptions

    2. 以下の行をファイルの末尾に追加します。

      -javaagent:/opt/appdynamics/events-service/java_agent/ver4.5.0.0/javaagent.jar
-Dappdynamics.agent.accountName=<account_name>
-Dappdynamics.agent.applicationName=<events_service_app_name>
-Dappdynamics.controller.hostName=<controller_host>
-Dappdynamics.controller.port=443
-Dappdynamics.controller.ssl.enabled=true
-Dappdynamics.agent.nodeName=<events_service_node_name>
-Dappdynamics.agent.tierName=<events_service_tier_name>

      Java エージェント JAR、アカウント名、その他の値を適宜調整します。 

      イベントサービスクラスタ内のすべてのノードについて、ビジネスアプリケーション名（events_service_app_name）とティア名（events_service_tier_name）は通常同じですが、各ノードは一意の名前でなければなりません（events_service_node_name）。 


      AppDynamics におけるアプリケーションのモデル化に関する情報は、「アプリケーションモデリング」を参照してください。 

  4. 「独立したマシンエージェントのインストール」で説明しているように、クラスタ内の各ノードで、スタンドアロン マシン エージェントが使用するノード名とティア名を定義します。 

    各スタンドアロン マシン エージェントのノード名とティア名は、各ノードで指定した events_service_node_name および events_service_tier_name と同じでなければなりません。

  5. クラスタ内のすべてのノードでイベントサービスを再起動します。コントローラホストで <controller_home>/platform_admin/events-service/  に移動し、/bin/platform-admin.sh restart-events-service コマンドを入力します。
  6. コントローラの UI で、[Applications] テーブルに移動して events_service_app_name アプリケーションのダッシュボードを開きます（ノードのイベントサービスが再起動してコントローラへのデータ送信を開始するまで、このアプリケーションが表示されるのに数分かかる場合があります）。 
  7. アプリケーション ダッシュボードで、[Configure] > [Instrumentation] を選択します。 
  8. events_service_tier_name ティアを選択し、[Use Custom Configuration for this Tier] を選択します。
  9. カスタムマッチルールの下に、次の属性で新しいルールを作成します：
    • エントリポイント = Servlet
    • リクエストデータを使用してトランザクションを分割 = トランザクション名の最初の 4 セグメントを使用