イベントサービスの管理

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

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

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

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

Linux の場合

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

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

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

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

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

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

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

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

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

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

次からイベントサービスクラスタのステータスを確認します。

  • Enterprise Console UI で、[Platforms > <name of the platform> > Events Service] の順に移動します。クラスタの正常性に問題がある場合、ステータスは重大として赤色で表示されます。緑色は正常なステータスを表します。アクティブでないノードを表示するには、各 [Host] の [Running State] 列を確認します。

  • Enterprise Console サーバーで、以下のコマンドを実行します。

    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 コマンドにより、ホスト名で指定する単一のノードからイベントサービスのソフトウェアおよびデータを削除できます。クラスター内に少なくとも 4 つのノードがある場合にのみこのコマンドを使用します。3 つのノードを持つクラスタからのイベントサービス削除には対応していません。--node コマンドラインパラメータを使用して、ノードを指定し削除します。

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

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

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

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

remove-events-service-node コマンドにより、ホスト名で指定する単一のノードからイベントサービスのソフトウェアおよびデータを削除できます。クラスター内に少なくとも 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>
  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>
  3. SSL が有効になっていることを確認します。 
     curl -k -v -X GET https://<events-service-domain>:9080/_ping
  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'
...

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

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

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

コマンドが完了すると、スクリプトを実行した場所に events-service.log.zip という名前の ZIP ファイルが作成されます。その後、アーカイブを抽出してトラブルシュートを行うか、トラブルシュートに役立つアーカイブを Splunk 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 は、イベントサービスが現行のコントローラバージョンに対して最新の状態であるかを確認し、そうでなければアップデートを実行します。

イベントサービスのパフォーマンスの微調整

Elasticsearch ノードのスクロールカーソルの数が多いほど、消費するリソースも多くなります。したがって、Elasticsearch ノードのスクロールカーソルの数を微調整する必要があります。スクロールカーソルを微調整するには、同時クエリ、ワークロード、およびサーバー構成を考慮する必要があります。デフォルトでは、スクロールカーソルの最大数は 500 に設定されています。カスタムスクロールカーソルの制限を定義できます。events-service-api-store.properties ファイルで、次のイベントプロパティを設定します。

ad.search.max_open_scroll_context = 500

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

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

  1. ダウンロードセンターから次のエージェントをダウンロードします。
    • 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）。

      Splunk AppDynamics におけるアプリケーションのモデル化に関する情報は、「アプリケーションモデルの概要No Content found for /db/organizations/splunk/repositories/portal-production/content/documents/AppDynamics/c_application_model_overview.dita」を参照してください。

  4. 「独立したマシンエージェントのインストールNo Content found for /db/organizations/splunk/repositories/portal-production/content/documents/AppDynamics/c_independent_machine_agent_installation.dita」で説明しているように、クラスター内の各ノードで、マシンエージェントが使用するノード名と階層名を定義します。
    注: 各マシンエージェントのノード名と階層名は、各ノードで指定した 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. カスタムマッチルールの下に、次の属性で新しいルールを作成します。
    • エントリポイント = サーブレット
    • リクエストデータを使用してトランザクションを分割 = トランザクション名の最初の 4 セグメントを使用

イベントサービスノードの Java 一時ディレクトリの更新

CLIのプラットフォーム管理を使用して、イベントサービスで一時 Java ディレクトリのオプションのオーバーライドを設定できます。イベントサービスの Java 一時ディレクトリを更新するには、次の手順を実行します。

警告: イベントサービス設定を更新した後、イベントサービスを再起動するには、プラットフォーム管理 CLI または Enterprise Console GUI が必要です。
  1. インストール後に次のコマンドを実行します。
    /root/install/pa/platform-admin/bin/platform-admin.sh submit-job --service events-service --job update_jvm_temp_dir --args jvmTempDir=/var/tmp
  2. 次のコマンドを実行して、設定が有効であることを確認します。
    /root/install/pa/platform-admin/bin/platform-admin.sh list-service-configurations --service events-service
  3. ジョブ update_jvm_temp_dir の設定を追加します。
    jvmTempDir (STRING): [/var/tmp]
  4. 元に戻すには、次のコマンドを使用します。
    /root/install/pa/platform-admin/bin/platform-admin.sh submit-job --service events-service --job update_jvm_temp_dir
  5. ジョブ update_jvm_temp_dir の設定を追加するには、次のコマンドを使用します。
    jvmTempDir (STRING): [null]